[dns-operations] Effectivity of filter lists against DNS amplification attacks

[Paul Vixie]

On 8/17/2012 8:03 AM, Klaus Darilion wrote:
> Lately, there was much discussion and examples on how to block the DNS
> requests of DNS Amplification Attacks. Such filters prevent the name
> server seeing the request, thus of course massively reducing the
> outgoing traffic. But such filters can not reduce the incoming traffic
> - the attacker will still send the DNS requests.

noting: there is no way to confidently know that an incoming request is
junk unless your decision-making process is inside of the name server
itself. no load balancer or firewall or similar technology operating
upstream of the name server can achieve the same low level of
false-positive or false-negative as can be had when the "drop or not?"
logic has direct access to a dns cache.

one such inside-the-server solution, available without fee, crafted for
use with BIND9, is DNS RRL.

see <http://www.redbarn.org/dns/ratelimits> for details on that.

> Thus, I would be interested in the results of such filters. Do you
> see, maybe not in short-term but in long-term, that the incoming
> attack traffic also decreases?

as to the question of filtering attacks when your infrastructure is the
target not the midspan reflecting amplifier, the fundamental problem is
the attacker's ability to forge your IP addresses on queries sent to
distant reflectors. this makes it nearly impossible to find the
injection point, and the midspan reflectors in this case are usually
just authoritative name servers "doing their job". the most effective
way to get an attack like this to stop is to visit or contact the
operators of the reflecting amplifying authority name servers and tell
them how they can "rate limit" their responses to queries they think
came from your network, as in DNS RRL above or anything similar you can
find. or, in the rare case where the amplifier is a recursive not an
authority server, you can ask its operator to add an "ACL" so that they
only serve client-IP addresses within their own network (see RFC 5358.)

that's problematic, but filtering it on your end is even more
problematic. assuming you can establish filters far enough away from
your network that your internet connection isn't already crushed by the
point at which you can drop packets, and that you can drop packets at
line rate with complex filtering rules at that faraway location, you
will find that the best you can do is drop by source IP address rather
than by some kind of DPI. you can renumber your own name servers so that
the attacker will be spoofing a source-IP that you're no longer using,
but that's whack-a-mole (the attacker can rotate weapons frequencies
faster than you can rotate shield frequencies, to throw in a ST:TNG
"Borg" reference.)

this is an embarrassing botch in the internet infrastructure. the
necessary invariants for "wide area UDP" were violated starting in 1994
with commercialization and privatization of the internet, and we've been
running bare ass naked through the woods, covered in honey, ever since then.

paul