|
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?
> > 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" roots. 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 directly. 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 http://www.mcs.net/~karl | 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: http://www.mcs.net/ Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal - - - - - - - - - - - - - - - - -
|