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

Geo. geoincidents at nls.net
Fri Mar 3 19:11:08 UTC 2006

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

Well I spend a lot of my day troubleshooting issues that others can't
resolve so for me being able to access other dns servers is a good way for
me to see if my dns is messed up or someone elses is or it's just a ttl
issue or whatever. DNS makes the internet work so troubleshooting it tends
to be high on my list.

Other than that there is a trust issue. No matter where I go or at what
point I get on the internet my computer always uses my dns servers because I
control them. He who controls the dns server you use controls you, so you
better trust them.

If I connect to the net from some wireless hotspot, how do I know their dns
servers are immune to cache poisoning? If I can't check any one elses dns
servers how would I even be able to confirm that they are?

> # ... 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.

Ok, well they aren't locking down their dns servers either, so either is
going to take effort to get it done.

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

Great, I'm the guy who had to actually make it happen, call customers and
get them to lock down their open relays, deal with new exchange servers
before exchange installed with relay disabled, etc. I had no problem with
that, it was the right solution for the problem.

This problem is spoofing being used to flood a target, it is only
tangentially related to DNS because todays version is using DNS to magnify
the attack. The attack itself is enabled by the ability to spoof. Heck we
could easily solve this by simply using only tcp for DNS and dropping
support for udp. Problem solved.

> 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

Maybe I didn't explain it right, it has nothing to do with folks using
non-local dns servers.

I'm picturing this as a DNS blacklist basically, so ok some ISP's will use
the service and some won't. Now you are on an ISP who doesn't use it, and
who is blacklisted and you use their local recursive servers. What is the
result you see when 10% of the dns servers on the internet refuse to respond
to your queries cause they use the blacklist but the other 90% respond as
always? Right, partial dns failures like some parts of the net are down.

Ok now lets suppose there is an ecommerce site on this part of the internet
that is blacklisted. That ecommerce site needs to process a transaction then
send an email back to the purchaser. The mail doesn't go thru, obviously
spam filters at the purchasers ISP so that's where everyone starts looking
but NOooooo it's a dns issue but the guy who handles the mail at the
receiving end will never know that because his dns servers respond properly
and he can't test anyone elses dns servers. Imagine SSL or PTR lookup spam
filters or any of a hundred of other functions that break if you have
partial dns failures.

The issues a blacklist of this type could cause would be a real nightmare to
track down and the guy having the nightmare isn't just the one blacklisted,
it would affect all of us. And then we still have to deal with the spoofing


More information about the dns-operations mailing list