[dns-operations] Limiting DNSSEC-based amplification attacks (Was: Weird TXT record

David Miller dmiller at tiggee.com
Fri Jun 24 18:42:27 UTC 2011

On 6/24/2011 1:43 PM, David Conrad wrote:
> On Jun 24, 2011, at 7:37 AM, Rick Jones wrote:
>> OK, perhaps my (ab)using "de jure" was setting myself up for that... The question was do the RFCs covering DNS require caching of responses?
> Others more familiar with the letter of the RFCs can probably answer better than I, but I'd have to ask: does it matter?  We're talking operations here...
> Operationally, do you think an authoritative server should respond to (say) 100 qps of the same query from the same source (assuming a reasonable TTL on the response)?

Operationally?  I would say that it would be reasonable to not respond 
to X qps of the same query from the same source.  Pick your own 
waterlevel of what value of X is "abusive" to you.

Functionally?  I would welcome any mechanism that could reasonably 
detect / respond to this (other than active human intervention).  A 
state table will be overrun, using any current tech that I have seen, if 
you try to track state of queries from each source (e.g. any query for 
anything == +1 for queries from $source).  Now we are talking about 
tracking particular queries from each source.  This greatly expands the 
state table that couldn't be maintained in the smaller case.

With DNS you must keep in mind that queries are UDP which is trivially 
easy to spoof.  Granted, for amplification attacks, the same source is 
used for all queries (otherwise they can't direct the traffic at the 
target).  However, for rate based attacks against DNS itself, with IPv4 
you could see up to ~3 billion possible "valid" (but not really) source 
addresses... with IPv6... forgetaboutit...  The same mechanisms must 
protect DNS servers against both simultaneously.


More information about the dns-operations mailing list