On 2009-01-28 at 19:30 +0000, Paul Vixie wrote: > DNS-oriented attacks are of a completely different kind. today's attacks were > precisely described in > <http://www.icann.org/en/committees/security/sac004.txt> > (which wasn't news in october 2002 but somebody had to write it down so i > did). > the important statement out of that 4-page document is: "Source addresses that > appear at Border or Interior connections are nonrepudiable by nature..." and > that statement bears on the question of RBL for DNS-oriented DDoS attacks > since > the address we'd have to assign a reputation to is the victim, so all we can > do is make an attack worse (by denying service to the victim's real traffic.)
I'd be willing to drop DNS queries, without even sending back a REFUSED response, if they come in with RD set from an IP in a list X, where X might be an RBL. I'd be perfectly happy to have X list every root server, gTLD server and ccTLD server, as a starting point, on the basis that none of those should ever be sending out RD queries, so refusing to reply to those addresses should have no impact. Perhaps if operators start to do this, anyone still running critical infrastructure authoritative DNS servers which perform recursive queries would finally split roles. Smaller outfits might get away with an auth server which does recursion too, for a finite set of IPs (eg, "localhost"), if they have issues obtaining IP addresses. Anyone providing nameservers for gTLD or ccTLD zones should not have this problem. (My personal nameserver is in the smaller outfit category here). Now, implementing the RBL against only recursive queries is a separate issue; without nameserver support, you're obviously down to packet filtering. bind supports complete blackholes, but not RD blackholes, AFAIK, but you'd be in a better position than me to say what's coming in bind. iptables can apparently perform payload inspection, but pf definitely can't (at this time). By this, I mean filtering on udp[10] & 0xf9 = 1 [1] Regards, -Phil [1] That's from the tcpdump rule I'm using to glance at this traffic; intf=ifname0 # wire ethernet device ipv4=192.0.2.1 # local IP tcpdump -vvvnpi $intf -Xs 1500 "( (dst host $ipv4 and dst port 53 and (udp[10] & 0xf9 = 1)) or (src host $ipv4 and src port 53 and (udp[10:2] & 0xfc80 = 0x8000)) )" Queries: QR=0, Opcode=0, RD=1 Responses: QR=1, Opcode=0, AA=0 And all assuming that we're only worried about UDP queries, since a TCP query implies the three-way handshake and if that's susceptible to spoofing then there are routing issues too.