Advisory — D-root is changing its IPv4 address on the 3rd of January.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDKXLEACgkQA5NiLuECHn4lRQCgoOlYQhq+kXk2Az3nPeN1hUfz 0e4AoKCwp0cLpABJFc/7RV5E/ecfWwoJ =ktnM -----END PGP SIGNATURE-----
On 13/12/2012 22:54, Jason Castonguay wrote:
Advisory — D-root is changing its IPv4 address on the 3rd of January.
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
On Fri, Dec 14, 2012 at 04:42:46PM +0000, Nick Hilliard wrote:
On 13/12/2012 22:54, Jason Castonguay 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 :) "The old address will continue to work for at least six months after the transition, but will ultimately be retired from service." Cheers, Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Architect (UNIX and Networks), Network Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
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. On Fri, Dec 14, 2012 at 8:52 AM, Matthew Newton <mcn4@leicester.ac.uk>wrote:
On Fri, Dec 14, 2012 at 04:42:46PM +0000, Nick Hilliard wrote:
On 13/12/2012 22:54, Jason Castonguay 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 :)
"The old address will continue to work for at least six months after the transition, but will ultimately be retired from service."
Cheers,
Matthew
-- Matthew Newton, Ph.D. <mcn4@le.ac.uk>
Systems Architect (UNIX and Networks), Network Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom
For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
-- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
Matthew Newton wrote:
On Fri, Dec 14, 2012 at 04:42:46PM +0000, Nick Hilliard wrote:
On 13/12/2012 22:54, Jason Castonguay 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 :)
"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? 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? Mike
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. On Fri, Dec 14, 2012 at 10:59 AM, Michael Thomas <mike@mtcc.com> wrote:
Matthew Newton wrote:
On Fri, Dec 14, 2012 at 04:42:46PM +0000, Nick Hilliard wrote:
On 13/12/2012 22:54, Jason Castonguay 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 :)
"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?
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?
Mike
On Fri, Dec 14, 2012 at 11:59 AM, Michael Thomas <mike@mtcc.com> wrote:
Matthew Newton wrote:
On Fri, Dec 14, 2012 at 04:42:46PM +0000, Nick Hilliard wrote:
On 13/12/2012 22:54, Jason Castonguay 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 :)
"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...
Mike
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 -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
<hand wavey>dnssec</hand wavey> On Dec 14, 2012 1:06 PM, "Joe Greco" <jgreco@ns.sol.net> wrote:
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 -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
On Fri, Dec 14, 2012 at 08:59:19AM -0800, Michael Thomas wrote:
Matthew Newton wrote:
On Fri, Dec 14, 2012 at 04:42:46PM +0000, Nick Hilliard wrote:
On 13/12/2012 22:54, Jason Castonguay wrote:
Advisory 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 :)
"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?
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?
Mike
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
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 ----- Original Message ----- From: "Michael Thomas" <mike@mtcc.com> To: "Matthew Newton" <mcn4@leicester.ac.uk> Cc: nanog@nanog.org Sent: Friday, December 14, 2012 8:59:19 AM Subject: Re: Advisory — D-root is changing its IPv4 address on the 3rd of January. Matthew Newton wrote:
On Fri, Dec 14, 2012 at 04:42:46PM +0000, Nick Hilliard wrote:
On 13/12/2012 22:54, Jason Castonguay 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 :)
"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? 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? Mike
On Dec 14, 2012, at 8:59 AM, Michael Thomas <mike@mtcc.com> wrote:
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
Hi Michael, On 2012-12-14, at 11:59, Michael Thomas <mike@mtcc.com> wrote:
Matthew Newton wrote:
On Fri, Dec 14, 2012 at 04:42:46PM +0000, Nick Hilliard wrote:
On 13/12/2012 22:54, Jason Castonguay 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 :) "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
On 12-12-14 12:13, Joe Abley wrote:
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.
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.
On 15/12/12 06:03, Jean-Francois Mezei wrote:
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.
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.
On 14/12/2012 16:52, Matthew Newton wrote:
"The old address will continue to work for at least six months after the transition, but will ultimately be retired from service."
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
----- Original Message -----
From: "Nick Hilliard" <nick@foobar.org>
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.
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 -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
On Fri, Dec 14, 2012 at 11:56 AM, Jay Ashworth <jra@baylink.com> wrote:
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? I'm sure someone's thought about that though...I hope.
On 2012-12-14, at 13:17, Joe Antkowiak <antkojm1@gmail.com> wrote:
On Fri, Dec 14, 2012 at 11:56 AM, Jay Ashworth <jra@baylink.com> wrote:
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.
Joe
----- Original Message -----
From: "Joe Abley" <jabley@hopcount.ca>
Quite so: UMD: Where will the old IP route after the 6 month period is complete? Somewhere safe?
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.
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?) Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
On Fri, Dec 14, 2012 at 02:25:43PM -0500, Jay Ashworth wrote:
----- Original Message -----
From: "Joe Abley" <jabley@hopcount.ca>
Quite so: UMD: Where will the old IP route after the 6 month period is complete? Somewhere safe?
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.
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?)
Cheers, -- jra
But how do you know the Renesys allocations haven't been hijacked?? /bill
----- Original Message -----
From: bmanning@vacation.karoshi.com
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?)
But how do you know the Renesys allocations haven't been hijacked??
I know you're being a smartass, Bill, but you're right: I assume Renesys has made provisions for that, but I don't know what they are. No doubt they'll pop in and post a link to a blog post they wrote 5 years ago which explains. ;-) Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
On Fri, Dec 14, 2012 at 02:46:49PM -0500, Jay Ashworth wrote:
----- Original Message -----
From: bmanning@vacation.karoshi.com
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?)
But how do you know the Renesys allocations haven't been hijacked??
I know you're being a smartass, Bill, but you're right: I assume Renesys has made provisions for that, but I don't know what they are.
No doubt they'll pop in and post a link to a blog post they wrote 5 years ago which explains. ;-)
Cheers, -- jra
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. /bill
On Fri, Dec 14, 2012 at 08:48:07PM -0800, David Conrad wrote:
On Dec 14, 2012, at 11:02 AM, Joe Abley <jabley@hopcount.ca> wrote:
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,
Actually, it was "L" in 2007... :)
Regards, -drc
SOME people have very long memories. /bill
On 12/14/2012 9:50 PM, bmanning@vacation.karoshi.com wrote:
On Fri, Dec 14, 2012 at 08:48:07PM -0800, David Conrad wrote:
On Dec 14, 2012, at 11:02 AM, Joe Abley<jabley@hopcount.ca> wrote:
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,
Actually, it was "L" in 2007... :)
SOME people have very long memories.
Actually, I have an excellent memory also. The one thing I do NOT remember is this much Sturm und Drang over any of the past changes. I believe that the first few changes were actually painful (they were for me), but really, everything has gone along just fine and dandy until now. I gently point out the following resource (which I'm sure nearly everyone here already knew about): http://www.zakon.org/robert/internet/timeline/ DNS first reared its head in 1984. For the very longest time I even kept my copy of hints updated by hand, leaving notes as to the old IP, so that I'd notice if anything from my end was trying to reach an old IP (the amount of stupidity hard coded in was just as bad then as now). I downloaded one of the last hosts.txt files, in 1992, out of sentiment. It still makes me nostalgic to look at it. Is it just me? I do not remember L or previous entries garnering this much attention, and it seems there was actually a bit less time between announcement of the change, and my ::face::palm:: when I saw log entries, and realized I was lazy. I have no idea when the IP was turned off, since it wouldn't have *mattered* to me. I do remember quite a bit of discussion here and there when the first ones were changing, but it was local discussion, when my world was a bit more narrow and focused. I did actually look (although not very hard) for an actual history of the original hosts, and the migrations from legacy IPs and legacy names into the less colorful format of *.root-servers.net that we know and love today. For those of you still worried, I promise it will all be okay. I promise. -- Put a smile on it, even if you don't feel like it. Try building something up, instead of tearing it down. Santa believes in you, even if you don't believe in him.
and ones who don't read posts before responding. On Mon, Dec 17, 2012 at 8:14 AM, Randy Bush <randy@psg.com> wrote:
Actually, I have an excellent memory also. The one thing I do NOT remember is this much Sturm und Drang over any of the past changes.
increase in number of people who can't resist telling others what they should do
randy
On 2012-12-14, at 11:42, Nick Hilliard <nick@foobar.org> wrote:
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
On Fri, Dec 14, 2012 at 12:45:00PM -0500, Joe Abley wrote:
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*.
Joe
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. :) 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
On Fri, Dec 14, 2012 at 04:42:46PM +0000, Nick Hilliard wrote:
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.
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/14/12 11:42, Nick Hilliard wrote:
On 13/12/2012 22:54, Jason Castonguay wrote:
Advisory — D-root is changing its IPv4 address on the 3rd of January.
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?
Hi Nick, and Nanog, 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. Thanks, - -- Jason -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDLiHcACgkQA5NiLuECHn7U0wCgrNA/kNTNT65yHPG9uVgUxn9m khkAoNu/kKkcTVVsFbgd7IlIHkvrDLdD =+DnX -----END PGP SIGNATURE-----
On 12-12-14 15:13, Jason Castonguay wrote:
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 :-) 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 ?
Hi Jean, On Dec 14, 2012, at 9:12 PM, Jean-Francois Mezei <jfmezei_nanog@vaxination.ca> wrote:
On 12-12-14 15:13, Jason Castonguay wrote:
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. Kind regards, Job
On 12/14/2012 03:12 PM, Jean-Francois Mezei wrote:
On 12-12-14 15:13, Jason Castonguay wrote:
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 :-)
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 ?
Hi Jean-Francois, On the 3rd you should be able to dig and see the new entry, like the dynamic list you have mentioned. Thanks, -- Jason
In message <50CB882A.30502@vaxination.ca>, Jean-Francois Mezei writes:
On 12-12-14 15:13, Jason Castonguay wrote:
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 not a lot of "advance warning". -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Dec 15, 2012, at 4:58 PM, Mark Andrews <marka@isc.org> wrote:
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 not a lot of "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... Oh, and you can just download the root zone from ftp://ftp.internic.net/domain/root.zone ... - Jared
On Dec 15, 2012, at 2:13 PM, Jared Mauch <jared@puck.nether.net> wrote:
Oh, and you can just download the root zone from ftp://ftp.internic.net/domain/root.zone ...
Or, perhaps more conveniently, zone transfer the root zone from xfr.lax.dns.icann.org or xfr.cjr.dns.icann.org (see http://dns.icann.org/services/axfr/). Regards, -drc
In message <42515678-F2CE-48CE-A0E6-4211C5F0F1A1@puck.nether.net>, Jared Mauch writes:
On Dec 15, 2012, at 4:58 PM, Mark Andrews <marka@isc.org> wrote:
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 ? =20 3 weeks is not a lot of "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!).
3 weeks is not a lot of time to inform every recursive service operator in the world that there is a change coming. Remember nameservers will start logging warning messages as of January 3rd. There is a big difference between 'This is just fallout from D changing it's address' to 'What does this message mean and do I have to worry?'
I could only wish my automobile would notify me 6 months of its = impending failure should I take no action...
Oh, and you can just download the root zone from = ftp://ftp.internic.net/domain/root.zone ...
- Jared= -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 12-12-15 17:32, Mark Andrews wrote:
3 weeks is not a lot of time to inform every recursive service operator in the world that there is a change coming. Remember nameservers will start logging warning messages as of January 3rd.
Nameservers will NOT log messages starting Jan 3rd. The old IP address will continue to work for 6 months after that. Tempest in a tea pot. Besides all this is moot since the simulation which runs our universe ends this friday (the 21st is the end of the world, remember ? :-) So you edit your root.hints file today, and schedule a rndc refresh before June 3rd when convenient.
On Dec 15, 2012, at 2:32 PM, Mark Andrews <marka@isc.org> wrote:
3 weeks is not a lot of time to inform every recursive service operator in the world that there is a change coming.
Given the impact of the change, I figure 3 weeks is plenty.
Remember nameservers will start logging warning messages as of January 3rd.
And if they do, recursive service operators who haven't seen the message will (if they care) update their root hints. This seems to be exactly the right thing. I fail to see the concern here.
There is a big difference between 'This is just fallout from D changing it's address' to 'What does this message mean and do I have to worry?'
Are BIND's warning messages so opaque that someone who is looking at name server log messages can't figure out that the warning is talking about a root server IP address being changed? The handwringing over this issue is a bit over the top. Regards, -drc
On 12/15/12 6:07 PM, David Conrad wrote:
Are BIND's warning messages so opaque that someone who is looking at name server log messages can't figure out that the warning is talking about a root server IP address being changed?
What about the people that are running BIND 4 on an old Solaris 2.6 box, and the log file filled up at 2gb back in 2006? Also they forgot the root password, and no one has a boot disk. Won't somebody think of the boxen? -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net
Let us all have a moment of silence to remember all those poor unmanaged servers out there......Thank you now nuke them all and start over :) On Sat, Dec 15, 2012 at 6:21 PM, Bryan Fields <Bryan@bryanfields.net> wrote:
On 12/15/12 6:07 PM, David Conrad wrote:
Are BIND's warning messages so opaque that someone who is looking at name server log messages can't figure out that the warning is talking about a root server IP address being changed?
What about the people that are running BIND 4 on an old Solaris 2.6 box, and the log file filled up at 2gb back in 2006? Also they forgot the root password, and no one has a boot disk.
Won't somebody think of the boxen?
-- Bryan Fields
727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net
On 15/12/2012 23:07, David Conrad wrote:
The handwringing over this issue is a bit over the top.
It's a question of what's procedurally sensible. Sensible things would include longer notice of the impending change to the root zone, more widespread notice of what's happening and generally not poking around with really important bits of the Internet at times which are well known for having configuration freezes and/or when many people are going to be on holidays. There are many bits of the internet where changes will only affect small areas, but this change will affect everyone even if they people don't realise it (and yes, it probably won't affect them visibly because of root cache repriming). Other sensible things might include: - liaising with operating system vendors and recurser servers code authors and providing them with extra advance notice so that they can roll these changes into their code in a structured way. Software update release cycles often take many months to roll out, particularly for non OSS code. - perhaps some targeted localisation of the d.root-servers.org notice so that more than 15% of the world population can read it (english == 5% native speakers, 10% second language)? Lots of people are aware that resolver dns servers will automatically reprime their root cache without manual intervention. However, not everyone will realise it and a random punter who looks at this notice and doesn't understand root cache mechanics may well think that they need to start updating their DNS configuration files on Jan 3. It's not clear from the change notification that you don't necessarily need to do this. This change wasn't planned over a coffee last thursday morning. It's obviously been on the cards for several years, so asking for more carefully structured notice in a procedurally sensible sort of way isn't an unreasonable thing to expect as part of the migration plan. Nick
On 12-12-15 19:45, Nick Hilliard wrote:
widespread notice of what's happening and generally not poking around with really important bits of the Internet at times which are well known for having configuration freezes and/or when many people are going to be on holidays.
You have 6.75 months to implement this before the current IP address no longer works. Use idle time during holidays to plan when you will do this change if your configs are frozen during holidays. I did react with a sense of urgency when I first read the message, but once you re-read it, you realise the timing and advance notice are plenty sufficient.
Software update release cycles often take many months to roll out, particularly for non OSS code.
Those one support can get a patch from their vendor or simple instructions on how to edit their root.honts file to change an IP address it in (or use dig to get the new one).
This change wasn't planned over a coffee last thursday morning. It's obviously been on the cards for several years,
But probably can't make an announcement until everything has been approved. Also, if you annouce something that will happen 1 year from now, more people will just postpone the change and forgot about it.
Nick, On Dec 15, 2012, at 4:45 PM, Nick Hilliard <nick@foobar.org> wrote:
On 15/12/2012 23:07, David Conrad wrote:
The handwringing over this issue is a bit over the top. It's a question of what's procedurally sensible. Sensible things would include longer notice of the impending change to the root zone,
Given reality and the way root priming works, 3 weeks notice and 6 months of continued service seems sensible to me.
more widespread notice of what's happening
I gather recursive server implementations provide a warning message telling folks that the IP address has changed. That seems like a more useful notification methodology than sending email to a few (or even many) mailing lists.
and generally not poking around with really important bits of the Internet at times which are well known for having configuration freezes and/or when many people are going to be on holidays.
It simply doesn't matter if folks refuse to make a change during the holidays. The worst case scenario is they'll get a warning message in their recursive server log files. Presumably, the folks who look at those log files will be able to understand what it means. They have 6 months after the change occurs to update their root hints. Even if they don't, this particular change will only affect people 1/13th of the time their name servers reprime and will do so in a way that is wildly unlikely to even be noticed.
This change wasn't planned over a coffee last thursday morning. It's obviously been on the cards for several years, so asking for more carefully structured notice in a procedurally sensible sort of way isn't an unreasonable thing to expect as part of the migration plan.
You seem to be a bit confused about roles and prerogatives here. The UMD folks are making a change to _their_ infrastructure. They have sent out a notice in advance of that change to folks who might be interested. They were under absolutely no obligation to do so. There is no contractual or service level agreement between UMD and _anyone_ that requires them to do _anything_ with regards to root service. The fact that they gave 3 weeks notice that they were changing the IP addresses of their server shows they are nice folks. Neither you nor anyone else that uses "D" has any right to dictate how UMD operates their infrastructure, how much notice to give when making changes to that infrastructure, who gets notified, etc. Welcome to the wonderful wacky world of volunteer root service! With that said, I would argue it should be the responsibility of the maintainers of the root hints to notify software vendors, recursive operators, etc. of a change since the maintainer of the root hints file has vetted/implemented the change. It is also more likely that the world has at least heard of the maintainers of the root hints than some random person posting unsigned messages from a University (no offense Jason :-)). Regards, -drc
On 16/12/2012 02:26, David Conrad wrote:
The UMD folks are making a change to _their_ infrastructure.
as is their prerogative. It's just that they happen to operate a particular chunk of Internet infrastructure which is pretty important in the scale of things.
They have sent out a notice in advance of that change to folks who might be interested. They were under absolutely no obligation to do so. There is no contractual or service level agreement between UMD and _anyone_ that requires them to do _anything_ with regards to root service.
yep, absolutely.
The fact that they gave 3 weeks notice that they were changing the IP addresses of their server shows they are nice folks. Neither you nor anyone else that uses "D" has any right to dictate how UMD operates their infrastructure, how much notice to give when making changes to that infrastructure, who gets notified, etc.
No-one's dictating: I'm just asking them politely to take some suggestions into consideration - suggestions which no-one has so far pointed out as being unreasonable, and which I would tend to view as being procedurally sensible and good things to do. That's all. Nick
On 16/12/2012 02:26, David Conrad wrote:
The UMD folks are making a change to _their_ infrastructure. A site who hosts a Global Internet critical infrastructure is not bound to
Nick Hilliard wrote: the same procedures as a regular site. It takes a certain amount of trust to have one of the Internet's core devices hosted at your site. While it is sometimes required to perform changes, it is no wonder that the community is involved and worried, since the D root server is a global infrastructure device, regardless of where it is located, and it is expected from UMD to behave accordingly (not that they are not, but just in the grand scheme of things). I am pretty sure that UMD doesn't think that the D root is akin their web server, as you would suggest in your mail (their infrastructure, their server, their procedure, not owe anything to anyone, etc etc...) It is critical to all of us, and we can and should lend our advice or even request (and sometimes require) a level of assurance that we (that is the operators on theInternet which is being served by D, since D is no local UMD service) will not end up hurt. It is their decision to make ultimately, but they can and should hear us, and if there is actually a grain of wisdom in what is being said, to consider it and amend plans. While there is no "specific and contractual" SLA in place, that does not mean that a root server operator is free to do whatever they please with critical global infrastructure, and I am very sure that this attitude is not prevalent with any Root operator out there. best, -- Ariel -- Ariel Biener e-mail: ariel@post.tau.ac.il PGP: http://www.tau.ac.il/~ariel/pgp.html
On 12-12-16 07:07, Nick Hilliard wrote:
No-one's dictating: I'm just asking them politely to take some suggestions into consideration - suggestions which no-one has so far pointed out as being unreasonable, and which I would tend to view as being procedurally sensible and good things to do. That's all.
I believe you are assuming that the department which runs tne root server at UMD has a choice in the matter. Consider a campus-wide IPv4 address space reorganisation to make better use of their available space. It would make sense to do this during summer when students are away. Having to stop using that IP by June would fit that scenario. The scarcity of IPv4 will result in more and more streamlining of network address spaces within organisations. While I have seen this announcement because I subscribed to nanog, I wouldnt be surprised to see that news spread via many other means. And how much more warning would one really need ? It isn't as if they were to announce that the end of the world will be this coming friday. (that one was announced centuries ago and isn't getting much press :-) This is a simple change, the internet will not stop running. It may take an extra second to reboot the bind servers that haven't gotten updates.
On Sun, Dec 16, 2012 at 12:45:32AM +0000, Nick Hilliard wrote:
On 15/12/2012 23:07, David Conrad wrote:
The handwringing over this issue is a bit over the top.
It's a question of what's procedurally sensible. Sensible things would include longer notice of the impending change to the root zone, more widespread notice of what's happening and generally not poking around with really important bits of the Internet at times which are well known for having configuration freezes and/or when many people are going to be on holidays. There are many bits of the internet where changes will only affect small areas, but this change will affect everyone even if they people don't realise it (and yes, it probably won't affect them visibly because of root cache repriming).
how much notice would you like?
Other sensible things might include:
- liaising with operating system vendors and recurser servers code authors and providing them with extra advance notice so that they can roll these changes into their code in a structured way. Software update release cycles often take many months to roll out, particularly for non OSS code.
its not clear this has not been done. nor is it clear that it would be needed, given the bootstrap methods that have been current for more than a decade.
- perhaps some targeted localisation of the d.root-servers.org notice so that more than 15% of the world population can read it (english == 5% native speakers, 10% second language)?
its not clear this has not been done. where you you localise this notice and what methods would you use?
Lots of people are aware that resolver dns servers will automatically reprime their root cache without manual intervention. However, not everyone will realise it and a random punter who looks at this notice and doesn't understand root cache mechanics may well think that they need to start updating their DNS configuration files on Jan 3. It's not clear from the change notification that you don't necessarily need to do this.
true - there is an expectation that the reader has a basic understanding of the DNS. My grandmother would be confused, but would clearly understand from the notice that there were many months before the existing system would change. Perhaps the notice should suggest talking with your service provider if you don't understand or have questions.
This change wasn't planned over a coffee last thursday morning. It's obviously been on the cards for several years, so asking for more carefully structured notice in a procedurally sensible sort of way isn't an unreasonable thing to expect as part of the migration plan.
are these all the points that concern you? are there others? lets get them all on the table.
Nick
On 12/15/2012 02:13 PM, Jared Mauch wrote:
3 weeks is plenty for a service that in 6 months you may see degraded to 12/13 capacity
... or 21/22 capacity, if you have IPv6. :) And the v6 address of D is not changing. FWIW I agree with the "tempest in a teapot" assessment. I think UMD has given more than adequate notice, and I'm looking at this from not only my perspective as former IANA-dude, but also as someone who formerly would have been the person to update this in FreeBSD. From a real, operational perspective, this is simply not that big a deal. In fact, it's hardly a deal at all. Doug
On Fri, Dec 14, 2012 at 2:13 PM, Jason Castonguay <castongj@umd.edu> wrote:
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.
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?) Forgive me if I'm missing something.
On Fri, Dec 14, 2012 at 03:10:44PM -0600, Joe Antkowiak wrote:
On Fri, Dec 14, 2012 at 2:13 PM, Jason Castonguay <castongj@umd.edu> wrote:
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.
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?)
Forgive me if I'm missing something.
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.) /bill
Hi,
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.
Thanks! Sander
participants (29)
-
Ariel Biener -
Bill Woodcock -
bmanning＠vacation.karoshi.com -
Brian Henson -
Bryan Fields -
Christopher Morrow -
David Conrad -
Doug Barton -
greg whynott -
Jared Mauch -
Jason Castonguay -
Jay Ashworth -
Jean-Francois Mezei -
Job Snijders -
Joe Abley -
Joe Antkowiak -
Joe Greco -
Joseph Jackson -
Julien Goodwin -
Lynda -
Majdi S. Abbas -
Mark Andrews -
Matthew Newton -
Michael Thomas -
Mike Hale -
Nick Hilliard -
Randy Bush -
Sander Steffann -
Walter Keen