RE: "local" zones

["Barber, Piet" <pbarber@verisign.com>]

>>>         i guess it's "about 1/4 to 1/2", not 0.5%.
>>
>>         Considering that .local is used with Rendezvous, multicast DNS, 
>> etc..., this would probably be a good idea.  Or maybe a bad idea, if it 
>> causes things to break.  Dunno.  This needs more work.

> How much damage would be caused by adding NS glue records to the root zone

> for .local pointing at 127.0.0.1? Sites which misconfigure and allow 
> lookups for .local to leak out will be told to go ask themselves. 

Well, you asked, and I answer. I very closely monitor the traffic to A root
just about every day, so I guess I can speak with some experience.  

I believe what you propose would be a *** very *** bad idea. 

Why? 

There is a very-widely deployed breed of name servers out there (I will not
name names) which behave very badly when any delegation is lame.  In this
case, localhost/127.0.0.1 as the lone name server would be a lame
delegation.

These bad behavior name servers do not negatively cache or keep record of
this situation in any way.  Once they realize that all delegated name
servers are lame/unreachable/not answering DNS, they perform one last very
unhelpful final query to a name server in the parent delegation (in this
case, one of the root servers;) apparently to ensure that the delegation is
the same as when originally received.  

Since there is no negative caching of this situation at all, subsequent
queries follow the same loop, and at a very high rate. Lame delegations lead
to the majority of spike traffic on the root and gTLD servers (thousands of
times per second in extreme cases).  

  Matt Larson, John Brady, and I wrote a draft about this behavior about 2
years ago.  (OK, so the draft is expired)   Hmm... It's somewhere around
here.... <shuffle>  Ah! Here's an archive of it in PDF format.
http://www.cs.utk.edu/~moore/ID-PDF/draft-ietf-dnsop-bad-dns-res-00.pdf,
specifically section 2.1.


I firmly believe that if we implemented this "local. NS localhost." entry,
more damage would be created than repaired.  In the current situation, the
root servers answer for 'local.' with NXDOMAIN, which is negatively-cached
by the vast majority of name servers out there. This configuration would
create a lame delegation -- surely magnifying these useless queries to the
root servers. 


If we as DNSOP WG truly wanted to reduce the number of useless queries to
the root servers, somebody might want to consider a draft that tells IWFs
[*] how to configure their firewalls to let the root servers answers get
back into their networks. (...Alas: then it wouldn't be in the scope of
DNSOP WG).  

I have noticed that a large number of the re-query traffic to the root
servers is because of improperly configured firewalls.  The bad-behaving
name servers desperately seek answers from root servers, then the firewall
blocks the returning answer. The bad implementation of that name server
doesn't properly detect that it has already queried for that server 100
times in the past second, and that there wasn't an answer, so the next time
it gets a query from a client, it follows through the whole loop all over
again. Woo hoo! 

This is probably why the old IP address for j.root-servers.net (i.e.
198.41.0.10) is STILL getting 1/3rd of the queries it received as it did
when it was a true root server.  99% of the queries are from repeat
offenders, a full 5 months after we made the address change in the root
zone. 


[*] IWF is defined at:
http://www.merit.edu/mail.archives/nanog/2002-05/msg01083.html
#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.