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

[Joe Greco]

New to the list.  But very interested.

> On Mon, 27 Feb 2006, Gadi Evron wrote:
> > william(at)elan.net wrote:
> >> And BTW - what is correct way to deal with queries at the dns server side?
> >> Lets assume we want appropriate security applied and have dns server only 
> >> answer regarding netzones it serves or on behalf of clients on pre-set 
> >> (local) network. If query comes in for non-served zone from remote net, 
> >> should dns server simply ignore the query and not send any answer?
> >
> > I believe it was Valdis on NANOG a few mounths back who said it best. The 
> > server which answers your users/clients should not be the same one 
> > facing the world.
> 
> He's probably right and all new places should be configured this way.
> 
> 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).

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.

Mixing messages a bit, Paul Vixie writes:
> #...
> #
> #Even if you block all the non-local recursive queries there are
> #still enough authoritative servers with big RRsets that you can
> #query for.
> 
> <wince>
> 
> since such servers would be doing nothing wrong, there'd be no basis for
> shunning them.  still, some kind of WRED could be employed at the victim's
> border if the number of servers sending these big responses was small
> enough.
> my gut-level assumption is that there won't be 580K authority servers (or
> 122K or 1M or whatever) available to participate in this kind of
> amplification
> the way that's currently being seen with open recursive servers.  (right?)

While I appreciate the specific current problem, it seems that the answer
isn't exactly a perfect fit.

More and more sites are indeed closing their open recursers, but this has
other side effects too.  For example, on Friday, a client had an issue
where their Internet connections in Miami got pulled over a DDoS attack,
and as a result all four of their nameservers went offline.  The colo in
question has told them to "talk to us Monday" or something like that; as
a result, I had their zones transferred to us so we could begin serving
them and provide some basic disaster recovery.  The downside:  they've
got customers all over the globe, and it has been a real pain to figure
out why some sites are still not resolving their names correctly.  In
the old days, we just played nameserver hopscotch and tracked down the
bad data...  but in this new wonderful fscked up "closed recurser" world,
we're left guessing.  Nice.

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.

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.

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

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.