North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Work Work Work
> > 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 [email protected] - - - - - - - - - - - - - - - - -
|