Tightened DNS security question re: DNS amplification attacks.

Wed Jan 28 23:11:30 UTC 2009

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.