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

>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.