Pretty soon we need an RBL for DNS-oriented DDoS attacks. =) -----Original Message----- From: Paul Vixie [mailto:vi...@isc.org] Sent: Tuesday, January 27, 2009 9:21 PM To: na...@merit.edu Subject: Re: Tightened DNS security question re: DNS amplification attacks.
"Douglas C. Stephens" <steph...@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
