Quite so: UMD: Where will the old IP route after the 6 month period is
complete? Somewhere safe?
In point of fact, ISTM that there *is no way* to make this completely safe;
granted that it's a low percentage attack, and thus probably not useful
to actual attackers, but the possibility exists that someone could hijack
that block at a provider level, and provide their own replacement for that
old server IP.
This is an extremely good point... Where will the former addresses be
going after this?
As I understand it (but ask UMD!)
- D-Root is currently numbered out of a general-purpose UMD /16 into a dedicated, specifically-assigned /24
- the UMD /16 is not going anywhere
The announcement is that D-Root is being renumbered, not that UMD is renumbering its whole network.
Other root servers have renumbered out of institutional, general-purpose networks into dedicated networks in the past. I think the last one was B-Root in 2004, from an address within 128.9.0.0/16 to an address within 192.228.79.0/24 (see <http://www.root-servers.org/news/new-ip-b.html>\).
I'm sure someone's thought about that though...I hope.
But this is important to those who write DNS server software to ensure
they embed the most up to date version of the root servers in their
binaries.
There are also a number of much older systems which no longer get
software updates (such as VAX-VMS) so it is good practice to manually
maintain the root.hints files so that over time, you don't accumulate
more than a couple of disused root server IP addresses.
So, in short, UMD will still own the losing allocation, and be able to make
relatively sure nothing else is placed at that IP (though of course they
won't necessarily be able to make sure no one hijacks that entire prefix --
does Renesys have a pay-special-attention list?)
the smart-ass answer to the nagging question on prefix reuse
is:
"Top Men are working on it"
A more reasoned (maybe) response might be:
To my knowledge, there is tension between creating "golden" addresses
and address flexablity/reuse. I'd really like to swing back toward
address flexability/reuse, but there is a whole lot of inertia behind
the "golden" address crowd.
Of the six renumbering events that come to mind, four of the prefixes
are sequestered. The two that are not were in net 10. I am unaware of
-anyone- who still points at the old addresses in net 10 space.
I think there were other renumbering events, but have not kept track
of the old prefix use.
I've given 3 weeks + 6 months (at least) notice on a service change that
will not be noticed by most anyone. Its a change to the HINTS file, which
is only used on bootstrapping. So anyone who does not update it will
connect to any of the other 12 root-servers, and receive the updated IP
from then on. If you have not updated your HINTS file since 1987 you may
have issues bootstrapping, but you are good from 89/09/18 on.
Additionally, we will be actively monitoring usage after the 6 month
period to determine when best to terminate the service on the old IP.
The old address, which is in the middle of UMD's network, is going to be
black-holed once the change is over. Nothing will be on that IP once we
move the root off. The rest of UMD's network is staying put. This move
is part of UMD's commitment to improve the service, so we can support
DNS anycast.
Additional notice to other listservs and on web pages is coming soon.
Upon hearing your announcement, I went and dig myself a new root.hints
file from one of the root servers. the "D" root is still pointing to the
old address. So I had to go in and manually edit the root.hints file
myself. I blame you for all that extra work
Would there be any impact to having the root servers immediatly provide
the new IP for the D server so that a
dig ns . @a.root-servers.net. > root.hints would yield the new updated
file ?
I realise that keeping the old IP functional for some time is important
for all the static configurations. But does it matter if a dynamic list
is updated "real time" without much advance warning ?
I've given 3 weeks + 6 months (at least) notice on a service change that
will not be noticed by most anyone.
Upon hearing your announcement, I went and dig myself a new root.hints
file from one of the root servers. the "D" root is still pointing to the
old address. So I had to go in and manually edit the root.hints file
myself. I blame you for all that extra work
derp derp
Would there be any impact to having the root servers immediatly provide
the new IP for the D server so that a
dig ns . @a.root-servers.net. > root.hints would yield the new updated
file ?
As far as I understand, after 3 January 2013 such a dig command would
create a new updated file with the new IP address.
Just a quick question....if the old block is going to be black-holed but
kept allocated...why does it need to be changed in the first place, or why
does the existing have to be disabled? (just have both addresses
active/responding?)
because you would not accept a /30 cutout of the UMD /16 coming
from some random IX in Singapore. (see Joe Ableys post earlier today
on why legacy nodes are / have renumbered.)
Agreed on the routing (although I wouldn't ever expect to see the subnet
encompassing a root server IP advertised in the wild with..anything even
close to 30 bits), and understood on the minimal/non-existant operational
impacts. Guess I'm just being curious.
Additionally, we will be actively monitoring usage after the 6 month
period to determine when best to terminate the service on the old IP.
Good to hear that.
The old address, which is in the middle of UMD's network, is going to be
black-holed once the change is over. Nothing will be on that IP once we
move the root off.
Thank you, very important to get that confirmed
Additional notice to other listservs and on web pages is coming soon.
Hosts like that should be using forwarders, not running their own
recursive resolver.
(And probably ported to Alpha at least in the VMS case, which is still
"receiving updates" even if its been two and a half years since the last
release)
Outside of VAX-VMS or old Windows systems I doubt there's much out there
that runs a recursive resolver that can't just have the current version
of bind installed fairly easily. There's probably some appliance type
systems, but the vast majority of those are so broken that an out of
date hints file is the least of their worries.
> I've given 3 weeks + 6 months (at least) notice on a service change that
> will not be noticed by most anyone.
Upon hearing your announcement, I went and dig myself a new root.hints
file from one of the root servers. the "D" root is still pointing to the
old address. So I had to go in and manually edit the root.hints file
myself. I blame you for all that extra work
Yet you appear to have not read the announcement.
Would there be any impact to having the root servers immediatly provide
the new IP for the D server so that a
dig ns . @a.root-servers.net. > root.hints would yield the new updated
file ?
Then people would complain "You didn't give us any warning". This is a
HEADSUP of an upcoming change.
I realise that keeping the old IP functional for some time is important
for all the static configurations. But does it matter if a dynamic list
is updated "real time" without much advance warning ?
3 weeks is plenty for a service that in 6 months you may see degraded to 12/13 capacity if you haven't properly maintained it AND it is used for recursive service. (trusting a referral from a root or sub-root delegation to the root is crazy!).
I could only wish my automobile would notify me 6 months of its impending failure should I take no action...
