Advisory — D-root is changing its IPv4 address on the 3rd of January.

Mailman List Mirror (Read Only)
1

Advisory � D-root is changing its IPv4 address on the 3rd of January.

This is advance notice that there is a scheduled change to the IPv4
address for one of the authorities listed for the DNS root zone and
the .ARPA TLD. The change is to D.ROOT-SERVERS.NET, which is
administered by the University of Maryland.

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.

This change is anticipated to be implemented in the root zone on 3
January 2013, however the new address is currently operational. It
will replace the previous IP address of 128.8.10.90 (also once known
as TERP.UMD.EDU).

We encourage operators of DNS infrastructure to update any references
to the old IP address, and replace it with the new address. In
particular, many DNS resolvers have a DNS root �hints� file. This
should be updated with the new IP address.

New hints files will be available at the following URLs once the
change has been formally executed:

http://www.internic.net/domain/named.root

http://www.internic.net/domain/named.cache

The old address will continue to work for at least six months after
the transition, but will ultimately be retired from service.

- --
Jason Castonguay

Network Integration Software Engineer
Division of Information Technology
University of Maryland
College Park, MD 20742

2

Jason,

You've just given 3 weeks notice for a component change in one of the few
critical part of the Internet's infrastructure, at a time when most
networks have entered a configuration freeze (which will usually finish at
the end of 2013 week one or week two), and where two of those weeks are
holiday / slack periods in large parts of the world where many people won't
be working.

In addition, there is no further announcement notices on
www.root-servers.org, d.root-servers.net, www.iana.org or www.icann.org.

You are absolutely kidding, right?

Can I politely ask you / UMD to please reconsider the timing and
publicisation of this change because it has important operational
consequences for the entire globe.

If you decide reconsider this change, could you please:

- change the date to give the world several months warning.

- change the date something which doesn't conflict with any of the major
ethnic world holidays

- create notification pages on www.root-servers.org, d.root-servers.net,
www.iana.org or www.icann.org

- announce more widely across e.g. other global NOG mailing lists, RIR
mailing lists, etc

Nick

3

I think that /was/ the advance notification - you've got 6 months :slight_smile:

"The old address will continue to work for at least six months
  after the transition, but will ultimately be retired from
  service."

Cheers,

Matthew

4

Also, this appears to be par for the course for the last two IP Address
changes on root-servers.net.

That's why they keep the old address online for at least six months after
the official change.

5

Matthew Newton wrote:

6

Mike,

You will need to update your root.hints file on any of your forwarding DNS
servers. Most OS vendors will include an update but its a good idea to
manually check.

7

Matthew Newton wrote:

Advisory — D-root is changing its IPv4 address on the 3rd of January.

You've just given 3 weeks notice for a component change in one of the few
critical part of the Internet's infrastructure, at a time when most

I think that /was/ the advance notification - you've got 6 months :slight_smile:

"The old address will continue to work for at least six months
  after the transition, but will ultimately be retired from
  service."

So really stupid question, and hopefully it's just me, do I need to do
something
on my servers?

your crontab that updates your root-hints may already have caught the change...

Second question: I know that renumbering is important in the abstract, but
is there
really an overwhelming reason why renumbering the root servers is critical?
Shouldn't
they all be in PI space for starters?

;; ANSWER SECTION:
d.root-servers.net. 604800 IN A 128.8.10.90

128.8.0.0/16 - legacy space...

8

If I had to guess, I would guess that renumbering is likely required to get it into a more portable address assignment from a multi-homing perspective. Look at the whois information below

If I were hosting a root server or something similar, I would certainly want it segregated enough that I could manage multi-homing for that address prefix outside of my other networks.

In this case, I'd assume UMDNET-1 may have monetary or administrative policies regarding the ability to be multi-homed and the degree to which it can be, however providing multiple links to UMD-ROOTD-NET is likely much easier because those decisions (or cost of connections) don't necessarily need to affect UMDNET-1

NetRange: 128.8.0.0 - 128.8.255.255
CIDR: 128.8.0.0/16
OriginAS: AS27
NetName: UMDNET-1
NetHandle: NET-128-8-0-0-1
Parent: NET-128-0-0-0-0
NetType: Direct Assignment
RegDate: 1984-08-01
Updated: 2011-05-03
Ref: http://whois.arin.net/rest/net/NET-128-8-0-0-1

NetRange: 199.7.91.0 - 199.7.91.255
CIDR: 199.7.91.0/24
OriginAS: AS6059, AS27, AS10886
NetName: UMD-ROOTD-NET
NetHandle: NET-199-7-91-0-1
Parent: NET-199-0-0-0-0
NetType: Direct Assignment
RegDate: 2007-12-07
Updated: 2012-03-20
Ref: http://whois.arin.net/rest/net/NET-199-7-91-0-1

9

you might want to pick up the new belt/suspenders file aka root.hints, named.ca, et.al.
and install it on your servers in the course of the next two years.

if you can't reach D, then you should be able to reach the other 12.

i beleive that D has not changed its IP address since before the RIR system came into
existance and therefore had no idea what "PI" space means. Some of this stuff is
really old/stable and making changes to foundational/stable systems is fraught with
peril. Being careful is just being prudent.

Perhaps of real interest to the NANOG community is the ability to "see" this prefix
in their routing tables.

/bill

10

Matthew Newton wrote:
So really stupid question, and hopefully it's just me, do I need to do something
on my servers?

Update the hints file. /var/named/ somewhere in all likelihood.

Second question: I know that renumbering is important in the abstract, but is there
really an overwhelming reason why renumbering the root servers is critical? Shouldn't
they all be in PI space for starters?

Starters was a _long_ time ago, and the person who did it shouldn't be disturbed.

                                -Bill

11

Hi Michael,

Matthew Newton wrote:

Advisory — D-root is changing its IPv4 address on the 3rd of January.

You've just given 3 weeks notice for a component change in one of the few
critical part of the Internet's infrastructure, at a time when most

I think that /was/ the advance notification - you've got 6 months :slight_smile:
"The old address will continue to work for at least six months
after the transition, but will ultimately be retired from
service."

So really stupid question, and hopefully it's just me, do I need to do something
on my servers?

When nameservers first boot, all they have is a hints file. This is either baked in to the software, or provided as a "hints file", or some combination. The hints file you have today will have the current/outgoing D-Root address.

The first thing a resolver does before it is ready for service, again, armed only with the hints file, is to send a priming query to a root server. This query is of the form ". IN NS?". Resolvers will try servers from the hints file until they get a response. Once the priming response is received, the data originally harvested from the hints file can be thrown away.

Once D-Root renumbers, a freshly booted resolver with an old hints file will either:

- send a priming query to one of A, B, C, E, F, G, H, I, J, K, L, M, and obtain a response that contains the new D-Root address
- send a priming query to the old D-Root v4 address, and also obtain a response that contains the new D-Root address

Once service is discontinued on the current/outgoing D-Root address, such a resolver might fail to obtain a response to its priming query if it happens to try the D/v4 address first. It will re-try with a different address until it succeeds. In principle, you only need one reachable address in the hints file to work to get up and running.

In summary, theory (and practice) tells us that:

1. You should update your hints file from time to time, and

2. If you don't, chances are overwhelmingly good that it will make no difference, and everything will work as normal.

Joe

12

I'm suggesting a lot more notification than 6 months before 128.8.10.90 is
switched off. And corroborative announcements backed up from authoritative
sources, not just a single email to nanog. It turns out that the Internet
extends far beyond the borders of continental north america, and this
change affects everyone who runs a resolver server.

It would be really good to have a formal public statement of intent from
UMD about their long term plans for 128.8.10.90 after retirement so that we
don't have a repeat of the L root hijacking debacle in 2008.

Everyone is extremely appreciative of the work that UMD has done in hosting
this service since 1987. However, hosting a root server is a pretty big
responsibility which includes maintenance of not just the existing
addresses, but also all historical addresses to ensure that people who hit
them after retirement (whether now or 20 years down the line) are not
served bogus data.

Nick

13

You've just given 3 weeks notice for a component change in one of the few
critical part of the Internet's infrastructure, at a time when most
networks have entered a configuration freeze (which will usually finish at
the end of 2013 week one or week two), and where two of those weeks are
holiday / slack periods in large parts of the world where many people won't
be working.

To be clear:

- there is no configuration change necessary in the next 3 weeks for resolvers
- there is no configuration change necessary in the next 6 months for resolvers
- even after 6 months, chances are resolvers which are not reconfigured will continue to work as normal

You are absolutely kidding, right?

These changes have happened before (other root servers have renumbered). I have never heard of an operational problem caused by such an exercise, and I guarantee there are resolvers running happily today with hints files that are *ancient*.

Can I politely ask you / UMD to please reconsider the timing and
publicisation of this change because it has important operational
consequences for the entire globe.

I think the trailing clause in your message above is over-stated. In fact, there are near zero operational consequences.

Joe

14

i had one, back last century, when B renumbered. the old address of B was the last
  working address in the bootstrap file from 1986. :slight_smile:

  i'm fairly confident that 99.9999% of all the existant bootstrap files on the Internet
  today contain at least 9 working IP addresses for root nameservers.

  That said, its -very- important to ensure (at each ISP, worldwide) that you have
  reachability to the new prefix.

  (wrt notification, I'm persuaded its valid and that the notice will be sent to many
  more groups as the hours/days progress ... remember, its not a flash change)

/bill

15

Nick,

  I feel compelled to point out that the new service address is
available now, and the old one will be available for another six months.
Feel free to wait until after the holidays to make your changes.

  Cheers,

  --msa

16

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.

But of course, they can do it *now*, too, so I guess it doesn't matter
anymore.

Cheers,
-- jra

17

> So really stupid question, and hopefully it's just me, do I need to do
> something
> on my servers?

your crontab that updates your root-hints may already have caught the chang=
e...

That seems like a spectacularly bad idea. How do you validate the new
root-hints automatically? What if someone manages to send you something
malicious in place of the correct one?

... JG

18

This is an extremely good point... Where will the former addresses be
going after this?

I'm sure someone's thought about that though...I hope.

19

<hand wavey>dnssec</hand wavey>

20

I've no doubt they have, but let's put it out on display.

Nick