North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Just got on this thing (perhaps very belatedly) - root server trouble?

  • From: Karl Denninger
  • Date: Tue Feb 18 17:00:10 1997

> On Tue, 18 Feb 1997 13:01:06 -0600 (CST), [email protected] writes:
> >
> >In fact, our solution has you *SECONDARYING* ".", which means that in
> >general, other than the requirement for you to be able to reach a source for
> >that file on a every-few-days basis (to check the SOA record) you no longer
> >NEED connectivity to the root domain.
> >
> >This is demonstrably superior; you no longer need to make that query for
> >".", as you already know who is authoritative for all the TLDs under ".".
> Yiiii... Having everyone secondary "." sounds demonstrably inferior to
> me.  Just think what would happen if every nameserver that is
> authoritative for a .com domain started secondarying ".". There are
> approximately 50,000 name servers that are authoritative for .com
> (according to the .com zone file from the InterNIC). That would mean
> that the system ROOT-NS.MCS.NET would waste around 5 queries per
> second because those 50,000 name servers would be trying to check the
> SOA (at the time that I write this, the eDNS servers list a 3 *hour*
> refresh interval for the root zone with a 15 *minute* retry
> interval). Just think what will happen to poor ROOT-NS.MCS.NET when
> the serial number changes!
> With system currently in use, those 50,000 name servers would generate
> around 6 queries per second as those name servers refresh their list
> of root name servers - and those queries would be distributed fairly
> evenly among all of the root servers.
> And to top it all off, there are probably at least 2-3 times as many
> name servers that are not authoritative for a .com domain. Boy, that
> ROOT-NS.MCS.NET must be one huge piece of iron...
> Hmmm... under your scheme, every name server would have authoritative
> information for the root zone. So, really, the other eDNS root servers
> are pointless, since they will never be contacted. That leaves
> ROOT-NS.MCS.NET as a *single point of failure*. Plus, think of the
> hassles when it's decided that the IP address of ROOT-NS.MCS.NET needs
> to change.

Well, the LONG TERM solution is to secondary and list the "known to be good"

You CAN run the cache file if you want -- but then you get the same problem
that everyone else has -- that the IANA needs to change the roots too, and
guess what -- there's a boatload of cache files out there.

Actually, root-ns is a beefy piece of hardware, and it runs NOTHING other
than this.  I'm not worried about the load.  The SOA times need to come
down, but frankly, 5 queries/second is diddly-squat on a production machine,
and lost in the noise.

The point here is that if you can't reach one of the roots for a period of
time, its no disaster -- you know where the data is, so you just go there

Yes, there are scaling problems.  Yes, there are with the IANA system.  
When we have enough RFC-2010 roots in place then of course this changes.
But for right now it gives better stability AND better performance than the
IANA system -- which is, I believe, the point.

Karl Denninger ([email protected])| MCSNet - The Finest Internet Connectivity     | T1's from $600 monthly to FULL DS-3 Service
			     | 99 Analog numbers, 77 ISDN, Web servers $75/mo
Voice: [+1 312 803-MCS1 x219]| Email to "[email protected]" WWW:
Fax:   [+1 312 803-4929]     | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
- - - - - - - - - - - - - - - - -