[dns-operations] Defending against DNS reflection amplification attacks

[Vernon Schryver]

> From: =?ISO-8859-1?Q?Jaroslav_Benkovsk=FD?= <jaroslav.benkovsky at nic.cz>

> 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.

How do you do that without too many false positives?  How do you not
drop responses when there is no attack because a lot of responses get
the same bucket?  And how do you not drop all of the legitimate responses
to non-forged requests from a victim under attack?

Notice that at the limit of that idea, you have one bucket per
client IP address, and so have converted RRL to client IP rate limiting.

You must assume that the bad guys will know how you group your
buckets, and so can force you to use a single bucket per client IP
address if they want.  They can do that even if you use a secret
or even varying grouping algorithm by randomingly varying qnames
and qtypes while monitoring your reactions.

The big advantage of RRL compared to rate limiting by client IP
address is that DNS is not turned off for the victim.  Between SLIP
and rate limiting (qname,qtype,IP), the victim generally still gets
name resolution.  The purpose of a flood of forged DNS requests might
not be to clog the victim's pipes, but to deny name resolution.  Many
attacks in past decades have had "Disable name resolution" as a first
step, and with new uses of DNSSEC (e.g. DANE) that first step seems
likely to be more common.


On the other hand, if you prefer client IP address rate limiting, then
the current BIND9 RRL patch includes an all-per-second parameter.  You
might set responses-per-second to 5 or 10 and all-per-second to 30 or
50.  For more information, follow the link on
http://www.redbarn.org/dns/ratelimits to the
"Draft text for BIND9 Administrators Reference Manual (ARM)"


Vernon Schryver    vjs at rhyolite.com