Subject: Re: root zone file

From: Simon Higgs <[email-masked]>
Date: Mon, 29 Apr 2002 12:08:33 -0700

[ post by non-subscriber ]

At 08:08 AM 4/28/2002 -0700, Paul Vixie wrote:

> > Replacing the hints file with the top level zone speeds up lookups,
>
>nope.  there are less than 300 top level delegations, and a proper
>caching implementation will only hit the roots once a week per tld.

That's still 300 hits on the root per DNS server if they all get queried. 
Verses one axfr.

> > and removes the burden from the root servers:
>
>wrong again.  (consider the impact of all those axfr's, from millions
>of name servers, whenever the root zone changes.)

Seems to me to be much less traffic than a continuous stream of arbitrary 
hits because the data is not in the other guys cache. But that's just what 
we're seeing. You may not be so lucky with the f root machines.

>but what it _will_ do is add one more config file which contains a
>dotted quad that might have to change some day.

Actually no. It just moves the hints info into a different config file. 
Remove the hints file completely, and create a slave "." file. ;-)

>every few years a
>root name server is added or moved.  everything is fine as long as
>there is _some_ overlap between your hints and the truth.  but it's
>a whole lot easier to automate the change tracking for a hints file
>than for something that tries to make every one of millions of name
>servers into stealth slaves of the "." zone.

First, no-one *EVER* changes their hints file. For the majority of 
machines, it only gets changed *IF* it gets updated in a named upgrade. The 
problem is how to make it dynamic in a way that is hard to compromise. One 
observation is that by putting the hints IPs into the master section of a 
root zone axfr, there is a due diligence that has to be observed to ensure 
each IP is going to give you the same root info from an axfr. Downloading a 
cryptographically signed list of current 'hints' IPs would work (BIND won't 
do that in this context as far as I can tell), as long as the IPs and keys 
are end user configurable and not hard coded. Anyway, the axfr is just one 
way to get around the 13 root limit.

Best Regards,

Simon

--
###

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: bert hubert <[email-masked]>
Date: Tue, 30 Apr 2002 00:33:34 +0200

> >caching implementation will only hit the roots once a week per tld.

Doesn't bind decrease the internal ttl by 5% per 'use'? Not sure, I don't
read the bind source all that often :-)

> That's still 300 hits on the root per DNS server if they all get queried. 

There are only in the order of 20 to 30 thousand important recursing
nameserver installations out there. 

So I wouldn't worry too much about this, as a root-server often gets in the
order of 3000 questions/second already.

Over a 30 minute period, we see 8000 different remote IP addresses on a
nameserver authoritative for in the order of 5000 domains with mostly 3600
second TTLs.

We did the measurements on a 24 hour period once and found somewhere in the
order of 20.000 remote addresses.

Regards,

bert

-- 
http://www.PowerDNS.com          Versatile DNS Software & Services
http://www.tk                              the dot in .tk
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO

---

From: [email-masked]
Date: Tue, 30 Apr 2002 09:37:03 +1000

> >caching implementation will only hit the roots once a week per tld.

	Plus all the negative traffic which has a much lower TTL and is
	a much higher percentage of the traffic at the root than positive
	traffic.

	Note the current way we search for a address record (A/AAAA/A6)
	appear to be flawed.  We really should be performing parallel
	searches rather than walking the search list for each type
	sequentially.  This has the possibilty of getting A/AAAA/A6 from
	different owners merged together.  It also adds unnecessary queries
	to the roots when one of the address types does not exist and an
	unqualified name is looked up.

	Mark
 
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]