I would like to call y'all's attention to the fact that there is a huge overlap between the nanog and iepg and namedroppers mailing list, and it is unlikely in the extreme that this thread has been of value in all three places. Therefore please note, respect, and emulate my "Reply-To:" header.
Honored, and respected.
More apropos to this particular thread, how about having the root cache file expire? Put an expiration date in as a fake record in the file, and have bind warn (but probably *only* warn) if the file is "out of date".
One more beer and I'd've said that the above was "just plain silly." Instead I'll note that the age of a cache file isn't conclusive proof that it's bad. We call it "out of date" but what we mean is that is that it's "wrong."
But is there any *harm* in re-fetching a new copy when the old one is "out of date"--not wrong, simply "out of date". I think that's the real thrust of this debate; what is the safest technique to use to make sure 90% of the client named's have at least reasonably up-to-date information. I know I'd be happier on my DNS servers to know that the daemon itself was fetching a new copy of named.cache on a periodic basis, perhaps once every three months, especially if it was using something similar to a zone transfer, with consistency checking to make sure the data that arrived matched the data that was sent. I'm sure it's a pipe dream, but I'd like to think it's a reasonable one.
I will add, probably to BIND-4.9.5++ (which is looking more and more like it's going to be called BIND-8.1, to get it into synch with Sendmail's versioning), a feature such that when the startup bootstrapping happens, if the NS RRset for "." retrieved from one of the servers in your root.cache file does not match the NS RRset for "." in that root.cache file, BIND will complain.
Er, don't you mean BIND-8.8?? If you're running sendmail-8.1, maybe you need _your_ version to expire. :-)
This catches other forms of wrongness than just date differences, and I think it will make the net a better place. Note that I will _not_ add a feature by which the root.cache file is overwritten by data from the network, until and unless we can do so under the DNSSEC umbrella.
Can you have it fetch the different, possibly newer version, and save it as a temp file, and mail root with the location of the temp file, and request to review, and possibly install it? I don't necessarily condone blindly overwriting named.cache, but fetching a temp copy under a named-cache-datestamp filename would help considerably... :-) But then again, I guess I'm a bit lazy that way. Thanks for considering this! Matt Petach mpetach@netflight.com