[dns-operations] Limiting DNSSEC-based amplification attacks (Was: Weird TXT record
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