Tightened DNS security question re: DNS amplification attacks.

Wed Jan 28 15:02:55 UTC 2009

Pretty soon we need an RBL for DNS-oriented DDoS attacks. =)

-----Original Message-----
From: Paul Vixie [mailto:vixie at isc.org] 
Sent: Tuesday, January 27, 2009 9:21 PM
To: nanog at merit.edu
Subject: Re: Tightened DNS security question re: DNS amplification attacks.

"Douglas C. Stephens" <stephens at ameslab.gov> writes:

> ...
> I choose the latter, and that is why went to the effort of blocking this
> abusive traffic before it reaches my authoritative-only DNS servers.

this is an odd implementation choice.  the 1PPS query stream is still using
your line even with this defense in place.  the 1PPS response stream and the
CPU cycles it takes to generate that stream isn't a burden on you (compared
to the 1PPS query stream that you can't stop anyway).  so the only reason to
block these appears to be so that you don't participate in the attack, or in
other words to cut down the burden on the victim.  with me so far?

the burden on the victim isn't going to drop materially by what you did
since
hundreds of thousands of other servers are not going to block it.  but if
the
victim is a recursive nameserver, then your blocking them will mean that
they
cannot access the zones you're authoritative for.  so, no positive, but some
negative, for the only person in the whole equation who can be affected by
the blocking you're doing.

i don't get it.  with a cost:benefit matrix like that one, why is anybody
blocking this traffic?  (i note with some alarm that ten years after i shot
it down, i still get queries to rbl.maps.vix.com, so the possibility that
the
blocks some folks might put in place to ...manage?... this attack will have
a
long term bad effect on our heirs and assigns.  i know your perl script will
expire things 60 seconds after they stop spewing, but i fear that others are
blocking these in hardcode.

(looking for ". IN NS" as the q-tuple pattern is not a solution, since the
bad guys can pretty trivially change the question they ask into one you're
willing to answer.)

(REFUSED is nice because it's small, but the bad guys aren't lacking for
bots
to transmit spoofed packets from, they Do Not Need amplification, and all
forms of error rate limiting are also new attack vectors.)

(is there a name-and-shame registry for networks that do/don't implement
BCP38? if not i guess i'll start one and hope that various auditors will use
google and notice me.)
--
Paul Vixie