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