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 edmo...@debian.org