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.
The cache file is only a hint - when a name server starts up it uses
the information in the cache file to contact one of the root name
servers and gets the latest list of root name servers from
there. Actually, you probably only need to know about one other name
server that has a list of root name servers.
However, if you ever have to renumber ROOT-NS.MCS.NET, you're in
trouble because there's no way for most name servers to update their
configuation files automatically to take notice of the new location of
the primary server.
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.
I don't care how beefy ROOT-NS.MCS.NET is, it's not going to handle
the load of all the zone transfers when you update the root zone's
serial number. You can make attempts to balance the zone transfer
load among name servers but that's a manual process and you're bound
to overload one of your root servers. The current system automatically
balances the load across all of the root name servers.
[A copy of the headers and the PGP signature follow.]