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

[Vernon Schryver]

> From: paul vixie <paul at redbarn.org>

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

I would emphasize a different aspect of that issue.  DNS Damping, like
the firewall based schemes, allows a bad guy to silence a DNS server
as far as a block of IP addresses is concerned.  Silencing DNS has
long been an important part of various security attacks.


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

I think that is a feature of DNS Damping intended to answer the complaint
about DNS RRL sending a "constant data stream of attack packets."
In my biased view that is a misfeature based on failing to apply
the same DDoS scenario to DNS Damping.  (See below.)


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

There are references to dealing with blocks instead of individual
addresses.  Perhaps that is intended for a future version.


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

How so?


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

http://lutz.donnerhacke.de/eng/Blog/DNS-Dampening

> > They can rate limit <http://ss.vix.com/%7Evixie/isc-tn-2012-1.txt> the
> > queries per client. 

DNS Damping *is* rate limiting.  It differs from DNS RRL only in
details about counting and limiting rates.  (One detail that I think
is important but that Lutz Donnerhacke evidently does not is that
RRL does not count *queries*; RRL counts *responses*.)


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

I think the complaint is that DNS RRL with "slip 0" and the recommended
"responses-per-second 10" could send 10 DNS response/second to the
victim.  If the responses were DNSSEC ANY or NXDOMAIN results, they
could be more than 1500 Bytes or 1.2 Kbits each.  If you stop there,
it sounds bad, because a bad guy could use 833 DNS servers using
RRL to reflect 120 Mbit/sec to the victim.

But don't stop there.  Ask what happens if those 833 DNS servers
use Damping instead of RRL.  I think the same 120 Mbit/sec would
be sent to the victim because no rate limiting including Damping
should trigger on a busy server at much less than 10 requests/second.


> (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 also wonder about that claim that DNS RRL requires "a lot of resources."
>From my superfical reading, appears to me that DNS Damping uses more
resources than DNS RRL.  What kind of resources are we talking about,
memory or CPU cycles?  How was resource utilization measured in the
two implementations and what are the numbers?


Vernon Schryver    vjs at rhyolite.com