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.

[A copy of the headers and the PGP signature follow.]