L-Root IPv6 address renumbering

Unbound
1

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.

New hints files will be available at the following URLs once the change has been formally executed on March 23, 2016:

2

Hi David,

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

3

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? :slight_smile:

4

Hi Robert,

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

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

5

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?

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.

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.

I wasn't proposing changing the behavior of the existing root-hints
option, it would have had to have been a new option. Maybe
"newer-root-hints-file", with the mtime behavior implied by "newer-"
explicitly documented.

I would guess that most users don't make an active choice of whether to
use compiled in root hints or root hints from some file, they just
accept whatever the default behavior is. If they do make an explicit
choice by setting the "root-hints" option, that choice should be
respected, of course.

Basically, the logic would look like:

- If the user explicitly configured "root-hints", use the requested
   root hints file unconditionally.

- If "root-hints" unset and "newer-root-hints-file" unset, use the
   compiled in root hints.

- If "root-hints" unset and "newer-root-hints-file" set to some
   filename then:

    1) If the file exists, check if its mtime is greater than the
    compiled in timestamp of the last time the root hint data in
    compile_time_root_prime() was updated. If so, load hints from the
    specified file and ignore the compiled in root hints.

    2) If the file does not exist, or its mtime is older than the
    compiled in root hints, use the compiled in root hints.

Then in the Debian package we would set by default:

    newer-root-hints-file: "/usr/share/dns/root.hints"

and depend on the package that provides /usr/share/dns/root.hints.

But maybe that's overly complicated for too little gain and we should
just set:

    root-hints: "/usr/share/dns/root.hints"

and keep the file up to date.

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?

Comparing mtime of two files, one of which is an editable config file,
can easily fail though (newer mtime on the config file containing older
data).

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).

This could be useful. We can ensure (through the package update
mechanism) that /usr/share/dns/root.hints will always be up-to-date.

6

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?

7

>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.

8

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.

9

Hi,

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

10

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?

11

Hi Robert,