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
_______________________________________________
dns-operations mailing list
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
