L-Root IPv6 address renumbering
wouter at nlnetlabs.nl
Wed Mar 16 07:37:33 UTC 2016
-----BEGIN PGP SIGNED MESSAGE-----
On 15/03/16 18:45, Robert Edmonds via Unbound-users wrote:
> 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
> 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
The sysadmin edits the root.hints file? The unbound.conf file is just
pointing to the root.hints file. I don't really see sysadmins editing
the root.hints file. Only very sporadic, perhaps, updating it
themselves. But then they have to keep doing it?
But that seems to be the only use case for the mtime comparison. And
it is very unusual?
I do not like mixing the internal compiled root hints with the
external file. I would like the internal compiled root hints to shut
off completely, when the root-hints config is given in unbound.conf.
This to make sure that the user's choice of root servers is used, and
the code does not (accidentally) use the wrong root servers.
But, having a second root-hints file, root-hints-backup or so? And
then mtime comparing it with the first root hints file, and using the
newest of the two files?
Also, would you want to have a configure-time default for the
root-hints value, i.e. never use the compiled-in defaults and always
read from a specific file (at default location)? (that would be,
unless overridden in unbound.conf).
Best regards, Wouter
> 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? :-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
-----END PGP SIGNATURE-----
More information about the Unbound-users