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

Paul Vixie paul at vix.com
Fri Mar 3 18:10:33 UTC 2006

# > so if OARC were to set up a public web page that allowed folks to do
# > lookups using HTTP, (1) that would be a useful thing and (2) you'd stop
# > worrying?
# Not unless you are convinced that is the only possible valid use for
# querying someone elses dns server.

it is the only possible valid use you have identified.  if you (or others
here) think there are others, i'd like to see the full list.  

# Can't we just accept that there are valid uses for a free and open internet
# functionality, even uses we haven't come up with yet, 

no, we can't.  the onus of proof is on he who asserts the positive.  if you
want me to agree that this is "useful" then you have to tell me uses -- QED.

# and instead look at this from the point of view that we should not kill
# functionality unless it's the last possible course of action?

you can look at it any way you want.  but the world in general is going to
look at it from a cost:benefit analysis point of view.  "known harm to self"
vs. "unknown good to others" is a pretty compelling tradeoff.

# > |       A: emits queries spoofed to come from C, aims them at B
# If A is connected to AS17173 then he can't emit queries spoofed to come from
# C,

what colour is the sky on your planet?  on my planet, "A" can emit whatever
he damn well pleases.

# ... as more and more network segments implement *gress filtering it will
# become less and less of a problem.

except that more and more segments aren't implementing any kind of filtering.
i have only anecdotal evidence (same as you, so KC is going to be mad at us)
but it shows this problem getting neither worse (which is an improvement) nor
better (as you claim) over the last five years.

# It's no different then trying to lock down recursive name servers except
# that for an ISP it's a lot easier to put a couple rules in their backbone
# routers than to find and secure every dns server connected to their network
# and deal with every new one that appears daily. You asked about motivation,
# where is the motivation for that going to come from?

i expect OARC to operate a clearinghouse for attack data, and offer some kind
of BGP or HTTPS (or whatever) feed of the results.  if an ISP can block these
servers without having to wait to be directly attacked, and just depending on
some trusted(?) middleman to be the data-blender, motive would be "in reach".

# >if "C" blocks "B" then "B" gains incentive to stop being an amplifier.
# Who is B? 5000 dns servers scattered planet wide on 5000 different network
# segments with 5000 different abuse addresses. You're going to block access
# via some sort of blacklist? Why not just turn the internet off because when
# dns does a PARTIAL fail it's not going to be like blocking smtp.

so you say.  me: i was part of the team who identified the open-smtp-relay
problem, argued that it be changed, caused it to be changed, and i claim
that there is an exact parallel between that and this, even down to the
tone of your concerned complaints about removing this functionality.

# It's going to affect people all over the planet who are trying to do
# commerce with sites who use those 5000 servers and the errors are going to
# be weird and difficult to troubleshoot. And since you can't troubleshoot by
# querying someone elses dns servers you are going to have to explain to them
# how to do it..

i would really like to meet some of those 5,000 people, and hear the ways in
which they depend on nonlocal open recursive nameservers, but right now all
i see is you, and all i hear is that you like to debug problems using other
folks' recursive nameservers, and your claims that a diagnostic web-based
tool would somehow be inadequate because there might also be other uses.

# Let me know when you turn this system on because I'm scheduling my vacation
# for that year..

best you call your travel agent, then.

More information about the dns-operations mailing list