[dns-operations] FreeBSD and the slaving of the root zone

Paul Vixie paul at vix.com
Thu Aug 2 16:27:58 UTC 2007


> From: David Malone <dwmalone at maths.tcd.ie>
...
> If anyone actually wants to document the pros and cons of slaving the
> root compared to the hints file, I'd be glad to try and help.

i've been thinking for 15 years or so that BIND needs an intermediate hint
cache: persistent and generated.  (we have persistent and supplied, and
ephemeral and generated, now.)  the idea would be that after a successful
priming, or perhaps three primings that all produce identical results, the
result would be written to persistent storage and used preferrentially on
subsequent reboots.  this would make the root hint more like a stub zone,
and would allow root name servers to renumber without "stale hint files"
lasting decades after the last sysadmin retires.  clearly this isn't BIND
specific, any full resolver that had persistent malleable config storage
could do this.

i cannot think of a way to similarly optimize the slave zone case, beyond
generating $INCLUDE files.  to me, this feature is more attractive than
keeping local crud local.  i'd rather anycast more root name servers than
have IP addresses hardcoded in something that's not a "zone file" today.

and lest i be misunderstood about the crud issue.  rootops look at their
crud all the time, and we like to complain about it, but not because it
ought to have been answered locally -- rather, because it ought never be
generated at all.  since most crud generators are global designs with a
lot of local instantiations (like windows XP for example), there's not
much benefit in hiding the crud from the people who can actually get
vendors to change their products.  as long as DDoS remains 200X larger
than crud, the crud is not in and of itself a provisioning problem.  no
work should be done in recursive nameservers to save work for the root
nameservers, other than properly implementing negative caching and other
protocol features, and other than getting dns clients to stop asking stupid
questions in the first place.



More information about the dns-operations mailing list