Work Work Work

Matthew Petach mpetach at netflight.com
Tue Sep 10 06:44:21 UTC 1996


> 
> 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 at netflight.com
 






More information about the NANOG mailing list