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

[Paul Vixie]

# New to the list.  But very interested.

it's a new list, so we're all new.  i am also very interested.

# > But many ISPs (and universities too) historically had common dns server
# > (for both resolving and serving local domains) and had dns server ip 
# > statically configured at customer sites (not everyone likes DHCP) and
# > on routers and unix/other systems. Changing this will take some time.
# 
# This is certainly true - and still is, of course.
# 
# The problems with running auth and recursion on the same servers are well
# known, of course, and primarily seem to revolve around "what happens when
# ${hosted-domain} moves."  That's a great reason to split those functions,
# but many-to-most sites don't seem to have done this (yet).

it turns out there's an ambiguity in the DNS spec regarding this, one i've
asked PVM (author of rfc 1035) to re-ruminate on.  see the thread containing:

    http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00121.html

for background.  basically, there is no correct answer to some questions, in
my interpretation of the scriptures, if a server is both recursive and
authoritative.  the implemention (e.g., BIND) has to guess what to do.  so
even over and above cache-preseedability and/or code bugs permitting outright
cache poisoning, there are "good" reasons not to try to answer recursive and
authoritative queries using a single nameserver-ip listener.

# Paul, I am guessing that you have access to at least some data in this 
# regard.  Since a large percentage of auth nameservers have known IP
# addresses (or, at least, they used to be glue in .com/.net zone files,
# etc), it would be interesting to know how many of those also appear to
# be performing recursive queries.

if you mean <http://www.isc.org/ops/ds/reports/2006-01/dist-servsoft.php>,
yes, we produce that using roy arends' excellent "fpdns" tool, and so in the
raw data we would have information as to how many of these servers indicated
"RA".  we don't actively test to see if they actually _will_ recurse if asked,
and as mentioned here, there are nameserver implementations who lie about
"RA".  so i don't feel as though we've got a good quotient of recursiveness.

# My understanding is that the current attack vector is for non-BCP38 nodes
# to inject requests for things like x.p.ctrc.cc (with a big TXT blob) and
# a return address of the victim site.

yup.

# If that's the case, wouldn't it be a better idea to find a way to deal
# with operators who didn't implement BCP38?  I mean, really...  this is
# 2006.  Even if you can't do it on that upstream OC192 because your
# hardware won't hack it, surely you can do it at the customer border...
# which would cut off a huge portion of the infected PC's out there.

it's not about capex, it's about opex.  the act of turning on BCP38-like
features, training staff in how to manage and operate this feature set,
finding out what customers are doing 3TCP or satellite-asymmetry and who
therefore actually need to "spoof" the source addresses but who can likely
be trusted to do so, is considered completely unrealistic by large ISP's.

in 2002 i wrote <http://www.icann.org/committees/security/sac004.txt> and
in 2003 <http://www.cctec.com/maillists/nanog/historical/0306/msg00498.html>
and i forget how many other times and places i've bleated about BCP38 and
the implied "an armed society is a polite society" routing paradigm in use
on the internet and how dangerous it all is.  further suggestions welcomed!

# Given that any UDP service that generates a large reply is going to be
# a problem in the current environment, and open recursers are merely one
# potential datasource for such replies, it really seems to me that the
# problem is more one of fixing the _cause_ rather than the _symptom_.

i'm tempted to pour a beer and cry in it, but that's been done.