designing worldwide name service in a north american forum

Wed Feb 19 06:26:03 UTC 1997

It appears that I'm about to add Karl to my mailproc rules since he really
does belong next to Jim Fleming.  But before I do that...

> Well, the LONG TERM solution is to secondary and list the "known to be good"
> roots.

In what order?  With 1,000,000 name servers (remember, you're talking
LONG TERM here) this is a hell of a lot of SOA queries against the first
server in the list.

> You CAN run the cache file if you want -- but then you get the same problem
> that everyone else has -- that the IANA needs to change the roots too, and
> guess what -- there's a boatload of cache files out there.

Or you could use existing technology (invented by Mark Andrews in this case)
and solve the REAL problem without also dealing with Karl's odd politics:

	zone "." {
		type stub;
		file "root.cache.stub";
		masters {
			192.36.148.17; 192.203.230.10; 128.8.10.90;
			192.33.4.12; 128.9.0.107; 128.63.2.53;
			198.41.0.4; 198.41.0.11; 198.41.0.10;
			192.112.36.4; 192.5.5.241;
		};
		check-names warn;
		allow-update { none; };
		allow-transfer { any; };
		allow-query { any; };
	};

That's on BIND 8.1.  If you're running BIND 4.9.5 it's a lot simpler.  What
this does is do a ". NS" query (with UDP) and store the results.  If there
is no answer, the "masters" list becomes like a "forwarders" for the zone,
which in this case makes it just like an explicated hint zone.

> Actually, root-ns is a beefy piece of hardware, and it runs NOTHING other
> than this.  I'm not worried about the load.  

You should be worried about what you'll do when its address changes.  That
is, you would have to worry if this name server was ever going to matter in
the larger scheme of things, which it is not.