[dns-operations] Defending against DNS reflection amplification attacks

[Paul Vixie]

...

Jaroslav Benkovský wrote:
> On 02/20/2013 08:48 AM, Jan-Piet Mens wrote:
>> FYI, a paper (Feb 2013) titled "Defending against DNS reflection
>> amplification attacks" at [1].
>
> Interesting. Since the problem with RRL at low NXDomain ratio is the
> number of buckets, i.e. names queried, perhaps it would be possible to
> limit the number of buckets by grouping names together for the purpose
> of assigning the bucket?
>
> E.g. a name server could adaptively assign names to a limited number of
> groups so that each group gets roughly the same amount of qps (or total
> sum of RRL score of the constituent domains) and then use the group id
> instead of a name as a bucket key.
>
> Or if this added complexity is too high, perhaps just (semi) random
> assignment of group id to a name on zone reload would be sufficient.

since this whole line of reasoning (which belongs on the ratelimits@
mailing list, not this one, by the way) is based on the idea that RRL
can be gamed, and since the above proposal and all variants of it can
also be gamed, i think we're in the weeds.

the perfect unstoppable reflecting amplifying ddos would first enumerate
all authority servers on the internet, and reflect 3 QPS off of each,
using a single fixed qname per server. nothing we do inside a server nor
in its data path to the internet core (as in, using front end load
limiters) will fix that.

we could develop a clearinghouse and maintain state centrally, at the
peril of "end to end system design", but this would not be fruitful
unless almost all authority servers (then and in the future) subscribed
to it.

at which point it's easier to fix source address validation and make
THAT universal. which we already know can't be done.

let's remain realistic.

paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20130222/1620089f/attachment.html>