L-Root IPv6 address renumbering

[Robert Edmonds]

W.C.A. Wijngaards via Unbound-users wrote:
> I have updated the default root hints that ship inside the source code
> of Unbound (in the code repository, for future releases).  Thank you for
> the notification.
> 
> Users can upgrade the root hints right now by editing the named.root (or
> named.cache, or root.hints file) and using the root-hints: "filename"
> directive in unbound.conf.  Or they can wait for a source code upgrade
> if they are using defaults.

Hi, Wouter:

I wonder a few things. Probably there will be future root server
re-numberings. We have to patch and rebuild binary packages for several
recursive DNS servers each time this happens.

On Debian, we ship the root hints file in /usr/share/dns/root.hints
(in package dns-root-data). It would be nice if Unbound and other
recursive DNS servers could use the freshest hints available on the
system, either in the system's root.hints file, or in the compiled in
root hints. This would avoid the need to update packages in released
versions of Debian and the need to backport hint updates from trunk to
the latest release.

That is, the two policies available currently are "use hints from an
external file" and "use compiled in hints". Both of these policies can
easily fail, e.g. the "use external file" policy with an out-of-date
hints file and up-to-date binary, or "use compiled in hints" policy with
an out-of-date binary and up-to-date hints file.

What if there were a "use latest hints from either external file or
compiled in hints" policy? Unbound would need to compile in a timestamp
corresponding to the time that the hints were last updated, and compare
this to the mtime on the root hints file. The distros can then enable
this policy by default and point the parameter to a file in /usr whose
mtime will be no later than the time that the hint file was actually
updated (and not the time the package was built or the file was
downloaded, etc.). Since the file would not be a configuration file it
would never be modified by the sysadmin and the mtime should always
accurately reflect its age.

Maybe this is not that big a deal if one or two hint addresses are out
of date out of 20+ addresses, because the root priming algorithm will
update it at process startup, but at least the distros do feel some
pressure to keep the compiled in hints current, across all the recursive
DNS servers in the distro that build in hints and across all the
supported distro releases. If I wrote a patch implementing this policy
would it be something suitable for merging into the mainline?

The other thing I wonder is, if the root-servers.net zone were ever to
be signed with DNSSEC, could we just let the server securely store a
persistent copy of updated root hints into /var, like
auto-trust-anchor-file does for the root trust anchor? :-)

-- 
Robert Edmonds
edmonds at debian.org