[dns-operations] Separating .ARPA operations from the root zone

[Doug Barton]

On 8/7/20 9:25 AM, Kim Davies wrote:
> Folks,
> 
> I wanted to draw attention to an Internet-Draft under development that 
> seeks to remove the unique interdependency that the .arpa zone has with 
> the root zone, by virtue of the zone being served by the root servers:
> 
> https://www.ietf.org/id/draft-iana-arpa-authoritative-servers-01.txt
> 
> We are looking for additional review of the proposed changes before 
> taking further steps.

With hats former IANA manager (with the associated responsibility for 
ARPA) and experienced DNS administrator, but not speaking for any 
employers current or former ...

Before I forget, 3.1 has a "to to" you probably want to fix.  :)

I'm not convinced by this draft as-is that there is any purpose to 
making this split. You refer several times to proposed novel changes to 
the ARPA zone that can't be done because of the entanglement, where are 
the references? I realize that I-Ds are not supposed to be used as 
protocol references, but this is an example of where referring to them 
as works in progress is justified. Folks reading the RFC 10 or 20 years 
from now won't have the context that some current readers do, and for 
that matter, I don't have it now. Without some way to judge the value 
that would accrue from making this change, it's impossible to justify 
the herculean effort it would take to do this change, and do it 
properly/safely.

Without a convincing argument for the value of making the change, I 
prefer the status quo. As you point out in the doc, the operational 
requirements for both zones are the same, and I always considered the 
fate-sharing between the two a feature.

Assuming you convince us that the change is needed, I suggest that you 
change the ns name space to arpa-servers. I understand the value of 
keeping the name server host names short, but given the unique role of 
the ARPA zone I can easily imagine a scenario where it would be 
desirable to use the ns name space for something else down the road. I 
do realize that even today there are places in the world that are 
bandwidth-constrained, but using the same label across the NS set allows 
for compression which would essentially eliminate the "cost" of the 
longer label.

Whatever the label turns out to be, I think you should make clear 
whether or not (and I assume not) you intend for the name server name 
space to be a delegated subzone, or just a host name convention, and 
why. It's a fairly nitpicky detail, but when you're making an 
operational plan that has this many moving parts, with this many players 
in the game, and affecting so many end users, I don't think it hurts to 
over-specify the requirements a little.  :)

Regarding the migration plan of adding new host names for the NS set 
which point to the same IP addresses as the current set, I've been using 
that exact technique with great success for a project involving the 
migration of five figures worth of zones. That approach should work well 
for this project. I do think that you should specify the plan in more 
detail, however. Off the top of my head I'd design it this way:

1. Add the new name server host names to the root and arpa zones
2. Standard waiting period between changes of 48 hours, or four root 
zone updates, whichever is later
3. Introduce the new name server host names in addition to the existing ones
	- Right now an NS query is 241 bytes
	- You could probably get all 26 servers in at the same time without 
going over 512 bytes
	- If not, I suggest something like:
		- Add six new ones, wait one period
		- Remove six old, add seven new, wait one period
		- Remove seven old
		- Wait one period before making any address changes
	- This may sound overly paranoid, but even with so much of the Internet 
going parent-centric, there are still plenty of old/broken resolving 
name servers out there which will choke if they don't see name servers 
they are already familiar with in the new NS set.
	- Having the old and new NS sets pointing to the same IP addresses 
initially will alleviate the parent-centric "trap" for the host name 
transition period, of course
4. The IP address change plan should be similarly specified. Again off 
the top of my head I'd say change one host, wait a period, change the 
next one, lather, rinse, repeat.

Opening up the concrete plan for the migration to discussion at this 
point (whether it's in this draft, or a separate one) will help you 
catch any potential gotchas far in advance of making actual changes. The 
volume and diversity of ways that old/broken name server software can 
screw up even the most well-planned delegation change still surprises 
me, and I've been doing this for over 25 years.  :)

Finally, by definition splitting the operations of the ARPA zone away 
from the current process increases the attack surface. You'll have 
more/different eyes and hands at every step of the way. That should be 
acknowledged in the Security section. I would also like to see a robust 
description regarding how the integrity of the content of the zone is 
going to be secured, how the change process is going to work, etc. As 
written the Security section basically says, "It'll be like it is now," 
which of course is not, strictly speaking, the case.

hope this helps,

Doug