Subject: RE: "local" zones

From: "Barber, Piet" <[email-masked]>
Date: Tue, 11 Mar 2003 21:44:53 -0500

>>>         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 <[email-masked]>.

---

From: Bruce Campbell <[email-masked]>
Date: Thu, 13 Mar 2003 10:51:42 +0100 (CET)

> case, localhost/127.0.0.1 as the lone name server would be a lame

Ok, so we currently have a problem with an amount of 'escaping' query
traffic.  ( Note that K.root does not see the same scale as Kato-san's
report, but the problem is visible. ).

A 'cute' way to fix it, that satisfies the slightly clueful, is to
delegate the problem TLD (.local) to 'localhost'.  The more clueful note
that this will probably cause more traffic (lame delegations cause more
problems than you'd believe).

However, what are we trying to fix?  The fact that the traffic is reaching
the roots, or that the traffic is escaping from the local networks?

If the former, we could correctly delegate (ie, not a lame delegation)
'.local' somewhere other than the roots, and let that sink the traffic.
Or simply put a wildcard record in for '*.local. IN A 127.0.0.1' and let
each site figure out whats wrong.

If the latter, we probably want to focus on active education, naturally
combined with a bit of trickery to rub people's noses in their
misconfiguration.  ( Writing RFCs is fine, but until they know about the
problem, people aren't going to read an informative document )

For that I'd suggest delegating '.local.' to the anycasted AS112 project
(so you've got localised traffic sinks), and wildcard records within to a
website hosted on each AS112, to the effect of 'If you can read this, you
have misconfigured your nameserver and local zone setup.  Here are a few
tips to correct this' (etc).

-- 
                             Bruce Campbell                            RIPE
                   Systems/Network Engineer                             NCC
                 www.ripe.net - PGP562C8B1B             Operations/Security

---

From: Måns Nilsson <[email-masked]>
Date: Wed, 12 Mar 2003 15:25:19 +0100

--On Tuesday, March 11, 2003 21:44:53 -0500 "Barber, Piet"
<[email-masked]> wrote:

> 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 Piet is right. 

Is it, instead of introducing this into the root, wise to do this a level
down or so? Perhaps an AS112 operation? 

Perhaps, it should not simply return 

local. IN NS localhost. 

at that level either, but perhaps something more clever? Are there any
studies made about what happens when That Companys Nameserver encounters
the NXDOMAIN that AS112 servers send? Is the behaviour similar? 

rgds, 
-- 
Måns Nilsson            Systems Specialist
+46 70 681 7204         KTHNOC  MN1334-RIPE

We're sysadmins. To us, data is a protocol-overhead.

---

From: Johan Ihren <[email-masked]>
Date: 15 Mar 2003 08:43:44 +0100

Bruce Campbell <[email-masked]> writes:

Bruce,

> each site figure out whats wrong.

Wildcards are evil. 

Wildcards in the root would by definition be the root of evil.

Bad idea.

...

> tips to correct this' (etc).

Ugh. While I see what you're trying to achieve here, I think the AS112
project should stick with providing nameservice for bogus lookups.
Diversifying into providing webservice for bogus surfing is not the
route to happiness.

Bad idea.

Johan Ihrén
Autonomica