Re: New addresses for b.root-servers.net
Forgive me if I'm missing something obvious, but why are you renumbering at all? Of course the diversification of RIRs is a good thing, but couldn't that be accomplished just as well by transferring the current allocation to LACNIC? It seems to me that there are a lot of reasons why, when it concerns root servers, renumbering should be a last resort. Especially when you already renumbered relatively recently and when an administrative solution rather than an operational one is available. I administer a few public IRC servers for EFnet, and when I assign a /24 for such a server I consider the subnet unfit for any other purpose from that point forward. Practically lost for normal use. Now, a DNS root server is obviously not the same as an IRC server, but I'd guess that there is a lot in common concerning threats and mitigation of those threats. Only the scale is much larger and the service (much) more critical (though people on IRC will fight me for saying that :). So, it seems to me that you'd also like to avoid renumbering unless absolutely necessary, if only because it's a waste of a perfectly good subnet. NB. Apologies for top-posting, a script that is supposed to fix this is started corrupting my emails after an update and I haven't been able to find the problem. -- Regards, Terrence de Kat, PhD/MTh/BPsy Darkness Reigns (Holding) B.V. Please quote relevant replies. From: Robert Story <rstory@ant.isi.edu> Sent: Tuesday, 30 May 2023 18:19 To: NANOG Subject: New addresses for b.root-servers.net
USC/ISI is renumbering both its IPv4 and IPv6 addresses for b.root-servers.net on 2023-11-27. Our new IPv4 address will be 170.247.170.2 and our new IPv6 address will be 2801:1b8:10::b. USC/ISI will continue to support root service over our current IPv4 and IPv6 addresses for at least one year (until 2024-11-27) in order to provide a stable transition period while new root hints files are distributed in software and operating system packages.
We are renumbering to increase the resilience of the Root Servers System by further diversifying the number of Regional Internet Registries (RIRs) that have allocated IP addresses to Root Server Operators. Our addresses will be the first in the Root Server System to have been allocated by LACNIC and our routes will be verifiable through LACNIC’s Resource Public Key Infrastructure (RPKI) Trust Anchor Location (TAL). We thank LACNIC for helping make this renumbering possible, and ARIN for supporting our prior addressing assignments.
The LACNIC announcement, with English, Spanish and Portuguese translations, can be found on their website here:
https://www.lacnic.net/6868/1/lacnic/lacnic-asigna-recursos-de-numeracion-al...
Please direct any comments or questions to b-poc <at> isi.edu.
Regards, Robert
P.S. Apologies to anyone receiving multiple copies of this announcement.
-- Robert Story USC Information Sciences Institute <http://www.isi.edu/> Networking and Cybersecurity Division
On Sat 2023-06-03 23:00:33+0200 Terrence wrote:
Forgive me if I'm missing something obvious, but why are you renumbering at all?
Of course the diversification of RIRs is a good thing, but couldn't that be accomplished just as well by transferring the current allocation to LACNIC?
Hi Terrence, DNS Root Server addresses from ARIN are assigned from the critical infrastructure pool, and ARIN policy does not allow them to be transferred to another RIR. The relevant policy section is: 8.4. Inter-RIR Transfers to Specified Recipients [...] Conditions on source of the transfer: [...] Address resources from a reserved pool (including those designated in Section 4.4 and 4.10) are not eligible for transfer. Regards, -- Robert Story USC Information Sciences Institute <http://www.isi.edu/> Networking and Cybersecurity Division
Hi Robert, If the goal is increased robustness by having addresses present from a different RIR, wouldn't it make this whole tempest in a teapot moot if, instead of *reunubering*, you simply *added* a second set of IPs, but continued to answer queries on the original addresses as well? Is there any reason at all to unconfigure the original IPs from the servers after the LACNIC IP addresses are added to the servers? I mean, it's perfectly normal for servers to have multiple IP addresses on them, we've been doing it for decades, and IPv6 has really hammered home that it's normal and expected for hosts to have multiple IP addresses on them, often from different providers. Thanks! Matt On Sun, Jun 4, 2023 at 8:06 AM Robert Story <rstory@ant.isi.edu> wrote:
On Sat 2023-06-03 23:00:33+0200 Terrence wrote:
Forgive me if I'm missing something obvious, but why are you renumbering at all?
Of course the diversification of RIRs is a good thing, but couldn't that be accomplished just as well by transferring the current allocation to LACNIC?
Hi Terrence,
DNS Root Server addresses from ARIN are assigned from the critical infrastructure pool, and ARIN policy does not allow them to be transferred to another RIR. The relevant policy section is:
8.4. Inter-RIR Transfers to Specified Recipients
[...]
Conditions on source of the transfer:
[...] Address resources from a reserved pool (including those designated in Section 4.4 and 4.10) are not eligible for transfer.
Regards, -- Robert Story USC Information Sciences Institute <http://www.isi.edu/> Networking and Cybersecurity Division
On Wed 2023-06-07 15:34:12-0700 Matthew wrote:
If the goal is increased robustness by having addresses present from a different RIR, wouldn't it make this whole tempest in a teapot moot if, instead of *reunubering*, you simply *added* a second set of IPs, but continued to answer queries on the original addresses as well?
Hi Matt, That is exactly what we've done. We are currently answering requests on the new LACNIC addresses, the current ARIN address which we renumbered to in 2017, and even the addresses from before that (cerca 2004). The commitment to maintain service for 1 year after the new LACNIC addresses are switched in to the root.hints from IANA does not mean that this is a cutoff date and that we intend to turn off service on the older addresses after a year. We currently have no plans to do so for the foreseeable future. In fact, the possibility has not even been suggested or discussed at all. In short: Keep calm, and query on. :-) Regards, -- Robert Story USC Information Sciences Institute <http://www.isi.edu/> Networking and Cybersecurity Division
Robert Story wrote:
The commitment to maintain service for 1 year after the new LACNIC addresses are switched in to the root.hints from IANA does not mean that this is a cutoff date and that we intend to turn off service on the older addresses after a year. We currently have no plans to do so for the foreseeable future. In fact, the possibility has not even been suggested or discussed at all.
Such total lack of advance and public discussion and preparation on a substantial change on critical infrastructure is a serious problem, I'm afraid. Masataka Ohta
On 9 Jun 2023, at 14:29, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
Robert Story wrote:
The commitment to maintain service for 1 year after the new LACNIC addresses are switched in to the root.hints from IANA does not mean that this is a cutoff date and that we intend to turn off service on the older addresses after a year. We currently have no plans to do so for the foreseeable future. In fact, the possibility has not even been suggested or discussed at all.
Such total lack of advance and public discussion and preparation on a substantial change on critical infrastructure is a serious problem, I'm afraid.
Masataka Ohta
I’m curious about what more discussion you want to happen than has happen in the past. Over the last 20 years there have been lots of address changes. None of them have caused operational problems. None required more that has already happened for this change. Mark 4781. [maint] B.ROOT-SERVERS.NET is now 199.9.14.201. [RT #45889] 4633. [maint] Updated AAAA (2001:500:200::b) for B.ROOT-SERVERS.NET. 4490. [maint] Added AAAA (2001:500:12::d0d) for G.ROOT-SERVERS.NET. 4457. [maint] Added AAAA (2001:500:a8::e) for E.ROOT-SERVERS.NET. 4423. [maint] Added missing IPv6 address 2001:500:84::b for B.ROOT-SERVERS.NET. [RT #42898] 4333. [maint] L.ROOT-SERVERS.NET is now 199.7.83.42 and 2001:500:9f::42. 4261. [maint] H.ROOT-SERVERS.NET is 198.97.190.53 and 2001:500:1::53. [RT #40556] 3794. [maint] Added AAAA for C.ROOT-SERVERS.NET. 3556. [maint] Added AAAA for D.ROOT-SERVERS.NET. 3441. [maint] D.ROOT-SERVERS.NET is now 199.7.91.13. 2918. [maint] Add AAAA address for I.ROOT-SERVERS.NET. 2870. [maint] Add AAAA address for L.ROOT-SERVERS.NET. 2328. [maint] Add AAAA addresses for A.ROOT-SERVERS.NET, F.ROOT-SERVERS.NET, H.ROOT-SERVERS.NET, J.ROOT-SERVERS.NET, K.ROOT-SERVERS.NET and M.ROOT-SERVERS.NET. 2255. [maint] L.ROOT-SERVERS.NET is now 199.7.83.42. 1567. [maint] B.ROOT-SERVERS.NET is now 192.228.79.201. 1397. [maint] J.ROOT-SERVERS.NET is now 192.58.128.30. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Mark Andrews wrote:
The commitment to maintain service for 1 year after the new LACNIC addresses are switched in to the root.hints from IANA does not mean that this is a cutoff date and that we intend to turn off service on the older addresses after a year. We currently have no plans to do so for the foreseeable future. In fact, the possibility has not even been suggested or discussed at all.
Such total lack of advance and public discussion and preparation on a substantial change on critical infrastructure is a serious problem, I'm afraid.
I'm curious about what more discussion you want to happen than has happen in the past. Over the last 20 years there have been lots of address changes.
If such changes are performed without proper transition plans even after DNS became critical infrastructure (when?), they also are serious problems.
None of them have caused operational problems.
Thank you for a devil's proof. That you haven't noticed any problem does not mean there actually was no problem. Masataka Ohta
participants (5)
-
Mark Andrews -
Masataka Ohta -
Matthew Petach -
Robert Story -
Terrence de Kat