[dns-operations] First experiments with DNS dampening to fight amplification attacks

paul vixie paul at redbarn.org
Mon Sep 24 15:10:45 UTC 2012


lutz, in looking at your patch, it appears that your "dns dampening" has
two bad side effects and one misfeature.

first, since it does not take the query or response into account, all
queries from a given source will share fate. this means your authority
server will go completely silent on some recursive name server if it
sends too many of any kind of query no matter how diverse those queries are.

second, you go completely silent when in dampening mode. there are no
slip responses by which an actual recursive name server might be able to
get real answers by retrying with UDP or escalating to TCP during times
that its IP address is being spoofed by an attacker.

third, you're giving each end-host address its own fate, so that a
spoofed-source attacker could cause you to flood a distant network
simply by iterating through that network's address space.

your solution seems to be optimized for overly busy recursive servers
who you want to deny excess service to, and does not deal at all with
the case of spoofed-IP reflected amplified attacks.

i also note that you have misunderstood (and therefore mischaracterized)
DNS RRL, according to this text from your web site:

> They can rate limit <http://ss.vix.com/%7Evixie/isc-tn-2012-1.txt> the
> queries per client. Unfortunly this generates only a constant data
> stream of attack packets. DDoS works well with limited data rates per
> server, if you misuse enough servers. On the other hand the
> implementation required a lot of ressources.

this text contains two factual errors: (1) that DNS RRL generates a
constant stream of attack packets: we attenuate the attacks in two ways,
first by dropping most (or at worse half) of the responses, second by
responding with TC=1 packets that are no larger than the requests; and
(2) that DNS RRL uses a lot of resources: we use about a megabyte of
storage to keep unique state for 50000 queries per second for five
seconds, which is trivial.

i urge a closer reading and deeper testing of DNS RRL
(http://www.redbarn.org/dns/ratelimits/).

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


More information about the dns-operations mailing list