[dns-operations] DNS deluge for x.p.ctrc.cc

Paul Vixie paul at vix.com
Thu Mar 2 21:44:53 UTC 2006

# > we don't get to decide, none of us, whether others will deploy BCP38.
# Actually to some degree we do. It's like ping dampening, if the ISP or
# business doesn't do it on their side the backbones can do it on theirs. IP
# addresses don't move around like DNS servers can.

this seems to be a nonsequitur.  only a direct neighbor (sharing a link) can
know whether BCP38 has been deployed (or rather, whether spoofing is done.)

# I mean I can tell you right now what's going to happen if we eliminate open
# recursive dns, people are going to run a dns server on their own machine
# (it's not like a small dns caching only server takes up much room) and then
# all the desktop systems are going to start talking directly to the hints
# file servers. The advantages of caching dns for thousands of desktops will
# dissapear and the loads will shift upstream. It'll happen this way because
# it's the easiest fix for machines that wander from zone to zone in a
# wireless world.

the folks who care about caching will use TSIG-protected forwarders.  there's
already so much useless swill coming into the root and TLD servers that any
additional load caused by the addition of a few hundred thousand non-broken
clients wouldn't even be noticed.  (97.9% of f-root traffic was estimated by
duane wessels to be unnecessary swill, for example.)  i consider the clients
who are endlessly repeating queries and ignoring NXDOMAIN to be the only real
reason why root and TLD servers need so much bandwidth today, and i further
consider that those broken clients currently acting as stub resolvers will be
likely to behave better, not worse, if they are forced to become full
resolvers.  (but the real solution is still TSIG-protected forwarders.)

More information about the dns-operations mailing list