Re: L-Root IPv6 address renumbering
Hi, On 17/03/16 05:55, Dave Warren via Unbound-users wrote: > On 2016-03-16 14:06, Robert Edmonds via Unbound-users wrote: >> Dave Warren via Unbound-users wrote: >> This is a good point, it doesn't really matter for the distro user, I >> guess. > > I may be wrong, but for those who take the time and effort to build > their own Unbound, I see them either using a root.hints file because > they know what they're doing, or not because they've never heard of it > (or because they know what they're doing) The simple solution, set a root-hints: "/usr/share/dns/root.hints" file in unbound.conf; or as a drop-in file in /etc/unbound.conf.d/*.conf if you have that. And then keep that file up to date? The defaults are for people that don't have a file around, but if you want to maintain it, use the root-hints file. If you want more complicated decisions around the file; having a script that makes symlinks one way or the other or something along those lines is something you can cobble together. But I think just setting the configuration option for root-hints in unbound.conf is probably just what you want? Do you still need to be able to set a default value for the root-hints file location, or is it just as good to set it in unbound.conf (or unbound.conf.d/ drop-file) ? Best regards, Wouter > > I'm sure there's some small group that will create one and abandon it, > but I just can't imagine that this type would remember to manually > update the binary. > > >> I agree, the consequences are extremely mild in the first place. We >> still go to the trouble of backporting the root hint updates, though. > > I agree that it's worth doing, but the keep-it-simple of just reading > the configured file or not seems like it's more valuable than guessing > at whether the file should be used or ignored. Also, the principle of > least surprise, a user will expect that the file will be used or not. > > > signature.asc Description: OpenPGP digital signature
Re: L-Root IPv6 address renumbering
On 2016-03-16 10:46, Robert Edmonds via Unbound-users wrote: Not quite, I want to avoid two things: 1) The sysadmin should never have to update the root hints by hand. "apt update && apt upgrade" should upgrade any packages needed to bring the root hints up to date. 2) The package maintainers shouldn't have to patch and rebuild each package with compiled in root hints when a root server is renumbered. At what point would a binary have a newer internal roots hints than the filesystem root.hints file when a user is using #1 to keep updated? Is there a subset of users who would update the binary but not apt update/upgrade? I guess to me, it seems better to directly address whatever failed to update the external root.hints than to add complexity of a "will-she won't-she" of using defined data files. Also, does any of this matter? The root hints just used to find the root servers on initialization, and then the resolver retrieves and uses the current roots anyway. Resolvers need to update eventually, but it's not a networking-breaking level of urgency either, is it? -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren
Re: L-Root IPv6 address renumbering
Dave Warren via Unbound-users wrote: > On 2016-03-16 10:46, Robert Edmonds via Unbound-users wrote: > >Not quite, I want to avoid two things: > > > >1) The sysadmin should never have to update the root hints by hand. > >"apt update && apt upgrade" should upgrade any packages needed to bring > >the root hints up to date. > > > >2) The package maintainers shouldn't have to patch and rebuild each > >package with compiled in root hints when a root server is renumbered. > > At what point would a binary have a newer internal roots hints than the > filesystem root.hints file when a user is using #1 to keep updated? Is there > a subset of users who would update the binary but not apt update/upgrade? This is a good point, it doesn't really matter for the distro user, I guess. > I guess to me, it seems better to directly address whatever failed to update > the external root.hints than to add complexity of a "will-she won't-she" of > using defined data files. > > Also, does any of this matter? The root hints just used to find the root > servers on initialization, and then the resolver retrieves and uses the > current roots anyway. Resolvers need to update eventually, but it's not a > networking-breaking level of urgency either, is it? I agree, the consequences are extremely mild in the first place. We still go to the trouble of backporting the root hint updates, though. -- Robert Edmonds edmo...@debian.org
Re: L-Root IPv6 address renumbering
On 2016-03-16 14:06, Robert Edmonds via Unbound-users wrote: Dave Warren via Unbound-users wrote: On 2016-03-16 10:46, Robert Edmonds via Unbound-users wrote: Not quite, I want to avoid two things: 1) The sysadmin should never have to update the root hints by hand. "apt update && apt upgrade" should upgrade any packages needed to bring the root hints up to date. 2) The package maintainers shouldn't have to patch and rebuild each package with compiled in root hints when a root server is renumbered. At what point would a binary have a newer internal roots hints than the filesystem root.hints file when a user is using #1 to keep updated? Is there a subset of users who would update the binary but not apt update/upgrade? This is a good point, it doesn't really matter for the distro user, I guess. I may be wrong, but for those who take the time and effort to build their own Unbound, I see them either using a root.hints file because they know what they're doing, or not because they've never heard of it (or because they know what they're doing) I'm sure there's some small group that will create one and abandon it, but I just can't imagine that this type would remember to manually update the binary. I agree, the consequences are extremely mild in the first place. We still go to the trouble of backporting the root hint updates, though. I agree that it's worth doing, but the keep-it-simple of just reading the configured file or not seems like it's more valuable than guessing at whether the file should be used or ignored. Also, the principle of least surprise, a user will expect that the file will be used or not. -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren
Re: L-Root IPv6 address renumbering
W.C.A. Wijngaards via Unbound-users wrote: > But I think just setting the configuration option for root-hints in > unbound.conf is probably just what you want? Do you still need to be > able to set a default value for the root-hints file location, or is it > just as good to set it in unbound.conf (or unbound.conf.d/ drop-file) ? Would setting a compile-time default value also apply to libunbound? Just setting it in /etc/unbound.conf will only apply to the daemon, right? -- Robert Edmonds edmo...@debian.org
Re: L-Root IPv6 address renumbering
Hi Robert, On 17/03/16 14:53, Robert Edmonds via Unbound-users wrote: > W.C.A. Wijngaards via Unbound-users wrote: >> But I think just setting the configuration option for root-hints in >> unbound.conf is probably just what you want? Do you still need to be >> able to set a default value for the root-hints file location, or is it >> just as good to set it in unbound.conf (or unbound.conf.d/ drop-file) ? > > Would setting a compile-time default value also apply to libunbound? > Just setting it in /etc/unbound.conf will only apply to the daemon, > right? Yes you are right. Compile time is default for libunbound. In unbound.conf only for the daemon (and for people that make libunbound read the config file, but most wouldn't, and then probably a different debug config file). Best regards, Wouter signature.asc Description: OpenPGP digital signature
Re: L-Root IPv6 address renumbering
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
Re: L-Root IPv6 address renumbering
Hi David, On 09/03/16 22:06, David Soltero via Unbound-users wrote: > > This is advance notice that there is a scheduled change to the IPv6 > addresses in the Root Zone for the L root-server, also known as > L.ROOT-SERVERS.NET, which is administered by the ICANN. > > The current IP addresses for the L.ROOT-SERVERS.NET service are: > > 199.7.83.42 > > 2001:500:3::42 > > > > As of March 23, 2016, the new IP addresses for > the L.ROOT-SERVERS.NET service will be: > > 199.7.83.42 > > 2001:500:9f::42 > > > > The change will be implemented on the root zone on March 23, 2016 > 2100UTC, however the new address is already operational. > > > We encourage DNS infrastructure operators to update their DNS resolvers > root "hints” file. 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. Best regards, Wouter > > New hints files will be available at the following URLs once the change > has been formally executed on March 23, 2016: > > * http://www.internic.net/domain/named.root > * http://www.internic.net/domain/named.cache > signature.asc Description: OpenPGP digital signature
