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@iname.com> To: "'Paul Vixie'" <vixie@isc.org>; <nanog@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@isc.org] | Sent: Tuesday, January 27, 2009 9:21 PM | To: nanog@merit.edu | Subject: Re: Tightened DNS security question re: DNS amplification attacks. | | "Douglas C. Stephens" <stephens@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 | | | |