Tightened DNS security question re: DNS amplification attacks.

Mailman List Mirror (Read Only)
1

Sorry to follow up to myself; a few more moments reviewing before
sending were warranted.

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

Before I get grilled on this point: it's not strictly true, since
obviously things like looking up the IPs of secondary servers to send
NOTIFY requests to may use recursive DNS.

  Only if you have configured a forwarder. Nameserver make non-
  recursive queries by default.

Okay, unless you're running
a nameserver which secondaries from the gTLD/ccTLD/root servers, you
have no reason to see RD packets from those servers. Hopefully that's
accurate enough to appease people who'll otherwise concentrate on that
point and lose sight of what I was trying to show -- that *most* people
could easily make use of such an RBL, if the nameservers supported using
an external file for ignoring RD queries without dropping all traffic.

As people upgrade Bind naturally, the number of reflectors that could
participate in an attack would go down. Get the OS vendors to use
default configs which set a Bind option to maintain the file
automatically and you're getting most of the way there, by sheer number
of DNS servers.

-Phil

  The most common reason for recursive queries to a authoritative
  server is someone using dig, nslookup or similar and forgeting
  to disable recursion on the request.

  Mark

2

* Mark Andrews:

  The most common reason for recursive queries to a authoritative
  server is someone using dig, nslookup or similar and forgeting
  to disable recursion on the request.

dnscache in "forward only" mode also sets the RD bit, and apparently
does not restrict itself to the configured forwarders list. (This is
based on a public report, not on first-hand knowledge.)

3

* Mark Andrews:
> The most common reason for recursive queries to a authoritative
> server is someone using dig, nslookup or similar and forgeting
> to disable recursion on the request.

Useful to know, thanks.

So someone performing diagnostics on one of the root/gTLD/ccTLD servers
would need to remember to dig +norec when checking visibility? Are
manual diagnostics going out from the source IP of such auth
nameservers considered common? In any case, it's a small enough, and
hopefully clued enough, sample of admins that it shouldn't be a problem.

Any organisation seeking to add their auth nameservers to a public RBL
of such IPs will have to accept the same constraint on needing clued
staff. No tears shed at that.

dnscache in "forward only" mode also sets the RD bit, and apparently
does not restrict itself to the configured forwarders list. (This is
based on a public report, not on first-hand knowledge.)

Unless any of the root/gTLD/ccTLD nameservers are also running dnscache,
it should be safe to drop UDP RD packets from those source IP addresses,
as previously described.

-Phil