D.ROOT-SERVERS.NET changing January 3rd 2013
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
bind9 (Ubuntu) |
Fix Released
|
Medium
|
Unassigned | ||
Lucid |
Won't Fix
|
Undecided
|
Unassigned | ||
Oneiric |
Won't Fix
|
Undecided
|
LaMont Jones | ||
Precise |
Won't Fix
|
Undecided
|
LaMont Jones | ||
Quantal |
Won't Fix
|
Undecided
|
LaMont Jones | ||
Raring |
Fix Released
|
Medium
|
Unassigned |
Bug Description
[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/
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.
description: | updated |
Changed in bind9 (Ubuntu Quantal): | |
assignee: | nobody → LaMont Jones (lamont) |
Changed in bind9 (Ubuntu Precise): | |
assignee: | nobody → LaMont Jones (lamont) |
Changed in bind9 (Ubuntu Oneiric): | |
assignee: | nobody → LaMont Jones (lamont) |
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?