[4253] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Work Work Work

daemon@ATHENA.MIT.EDU (Paul A Vixie)
Mon Sep 9 23:25:02 1996

To: nanog@merit.edu, iepg@iepg.org, namedroppers <namedroppers@internic.net>
Reply-To: nanog@merit.edu
In-Reply-To: Your message of "Mon, 09 Sep 1996 18:47:55 PDT."
             <96Sep9.184804pdt.177595@crevenia.parc.xerox.com> 
Date: Mon, 09 Sep 1996 20:23:49 -0700
From: Paul A Vixie <vixie@wisdom.home.vix.com>

I wasn't going to answer this, but someone forwarded me yet another copy
(I got it on namedroppers and nanog and iepg, too) saying that they thought
this was a good idea.  I don't, and I will explain the why of that below.

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.

> 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."

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.

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.

home help back first fref pref prev next nref lref last post