D.ROOT-SERVERS.NET changing January 3rd 2013

[Charles Peters II]

[Impact]

named may use the wrong server for D.ROOT-SERVERS.NET on startup, as the IP address is changing. This will cause a startup delay as it times out and bootstraps from another root server instead. In the worst case, a malicious actor on the old IP could subvert DNS.

From the other direction, we should not cause unnecessary load on an IP address that is no longer a root server.

[Test Case]

It isn't really possible to effectively test this change, since named will automatically use any available root server.

It will suffice just to check that an updated installation of bind9 does not have the old entry of 199.7.91.13 for D-ROOT-SERVERS.NET in /etc/bind/db.root, does have the new entry of 128.8.10.90 for it, and that "dig www.ubuntu.com a @localhost" still works.

[Regression Potential]

We are changing the root hints file so we should check that named still bootstraps, which I've included in the test case.

[Original Description]

Currently we have:
/etc/bind/db.root:D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90

The new IPv4 address for this authority is 199.7.91.13

The current IPv6 address for this authority is 2001:500:2d::d and it will continue to remain unchanged.

See http://d.root-servers.org/

[Robie Basak (racb)]

Thank you for taking the time to report this bug and helping to make Ubuntu better.

In the past, I don't believe we've updated the hints file by introducing a delta in Ubuntu, since it isn't expected to cause any operational problems for just a single root server in the hints file to be out of date; bind will pick up the change automatically from another root server as soon as it starts. I think we usually just wait for the change to filter through from upstream.

Is there any specific reason to act differently this time?

[Mark (markovh)]

In response to Robie, As far as i'm aware, a recursive server will pick a random root name server to fetch the list of root name servers from. If this happens to be the D root server old ip is offline, it'll stall briefly while trying to connect to it. Granted it's only a once off and a 1/13 chance of happening. Considering it's such an easy patch, no reason not to apply it though.

[Robie Basak (racb)]

> Considering it's such an easy patch, no reason not to apply it though.

For the development release, it adds extra work to whoever does merges in the future, and introduces the risk of an accidental regression if not everything through to upstream has updated before Ubuntu. But if you get the change in Debian, then Ubuntu will in time merge it without any further ado.

To update stable releases, "Even the simplest of changes can cause unexpected regressions due to lurking problems". See https://wiki.ubuntu.com/StableReleaseUpdates

I'm reluctant to push for this unless a clear consensus is reached, somebody points out exactly what we've done in the past, or an experienced Ubuntu developer tells me otherwise. I think the best place to seek consensus on this is the ubuntu-server mailing list. If others agree that the change is worth it, then, as you say, it's trivial to actually do and I'd be happy to see it through.

Otherwise, this will get fixed in time as the change filters through from upstream. This seems to me to be the path of least resistance, especially because I don't think changing it earlier will result in any real practical benefit. Anyone who cares enough is presumably already running configuration management and can just change the conffile anyway.

[Mark (markovh)]

If it's not a trivial change or has potential for unexpected problems then, fair enough i agree. Just leave it out until at least bind pushes out a new version with the updated zone file. I suppose a 1/13 chance of a minor delay on the first query to a server after reboot isn't much to worry about.

[Charles Peters II (cp)]

Although not a serious problem, admins running LTS releases could be waiting a long time for the packages to include the correct IPv4 D root server.

I asked LaMont Jones, one of the Debian bind9 maintainers, about this D root change issue and he said:
It's fixed in 1:9.8.4.dfsg.P1-2, and will be in 9.9.2 when it makes it into sid.

I have brought up the issue with the Ubuntu Server Team, see https://lists.ubuntu.com/archives/ubuntu-server/2013-January/thread.html#6469.

I have manually updated the bind9 servers I run, in case someone wants to know how...
# wget http://www.internic.net/domain/named.root
# cat named.root > /etc/bind/db.root
# service bind9 restart

[Clint Byrum (clint-fewbar)]

This should be SRU'd to all supported releases. Its not a low Importance. Slowing down peoples' lookups 1/13th of the time is pretty lame. Also we do backport fixes like this when things outside Ubuntu change, such as an address of a service. There's no maintenance problem for merges, as its fixed in Debian and therefore can be dropped as an ubuntu only change ASAP.

[Clint Byrum (clint-fewbar)]

Note that as part of due diligence I checked this site for confirmation that this is the legitimate IP of "d":

https://www.iana.org/domains/root/servers

[LaMont Jones (lamont)]

An SRU into existing releases makes good sense. The change is very minimal, with the biggest risk being that somepoint after the current operator of D stops using the IP address, said address gets assigned to someone who decides that giving out the wrong answers would be a thing to do. I don't see that as even remotely likely.

As for what the issue actually causes: it slows down lookups a very very small fraction of the time, since BIND does round-trip time tracking on requests, and prefers hosts that answer faster, and rarely queries the root nameservers (most TLDs are 2 day TTLs) in any case.

[LaMont Jones (lamont)]

I've uploaded SRU-able versions of the package to my personal ppa. See https://launchpad.net/~lamont/+archive/ppa/+packages

[Robie Basak (racb)]

Confirmed fixed in raring on 1:9.9.2.dfsg.P1-2.

[Robie Basak (racb)]

I wasn't happy to ask for sponsorship for SRUs directly from LaMont's changes, since they included some autotools noise and updated the entire db.root file instead of just changing the IP of D.ROOT-SERVERS.NET. For example, they added new IPv6 entries in older releases that weren't there before. So I've created a set of minimal debdiffs from scratch which change the IP of D.ROOT-SERVERS.NET in db.root only. I've built and tested each one.

[Anand Kumria (wildfire)]

As noted in http://d.root-servers.org/renumber.html, the change will be done on the 3rd Jan and the old IP address will be retried 6 months later.

Could we get proposed-update packages before the 3rd Jun (when the old IP will stop responding)?

I'm presuming that the Ubuntu guys are waiting until the start of May so that 8.04 LTS does not need new packages.

[Rolf Leggewie (r0lf)]

oneiric has seen the end of its life and is no longer receiving any updates. Marking the oneiric task for this ticket as "Won't Fix".

[Rolf Leggewie (r0lf)]

quantal has seen the end of its life and is no longer receiving any updates. Marking the quantal task for this ticket as "Won't Fix".

[Rolf Leggewie (r0lf)]

lucid has seen the end of its life and is no longer receiving any updates. Marking the lucid task for this ticket as "Won't Fix".

[LaMont Jones (lamont)]

Precise reached EOL some time ago. Marking this "won't fix"