Tightened DNS security question re: DNS amplification attacks.

Wed Jan 28 15:18:29 UTC 2009

Well the RBLs, in using dns queries, is another form of legal DDoS attacks, mainly when the suddenly cease to respond or re-configure to black-list the entire wold.   One should just imagine the bandwidth consumption during a given time-frame, RBLs consume as oppose to volume of spam messages.

----- Original Message ----- 
From: "Frank Bulk" <frnkblk at iname.com>
To: "'Paul Vixie'" <vixie at isc.org>; <nanog at merit.edu>
Sent: Wednesday, January 28, 2009 18:02
Subject: RE: Tightened DNS security question re: DNS amplification attacks.

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