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.

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,

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

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. :slight_smile:

Regards,

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 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