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

[Kim Davies]

Hi Doug,

Quoting Doug Barton on Saturday August 08, 2020:
> 
> 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?

The challenges of the current configuration are manifest.

On a day-to-day operational level, we have two distinct zones served
by the same authorities, one a child of the other. Edits to the NS-set
of one zone need to be coordinated with the another. When we change
the IP address of a root server, two parallel coordinated edits need
to be done synchronously in the arpa zone and the root zone. Approval
processes differ for both. As a consequence there are special-casing
rules throughout our root management code and business processes that
specifically pertain to "arpa" that we are keen to get rid of. Can
we continue to cater for it? Certainly. But there appears to be no
compelling reason to want to strive to persist this.

Distinct from that, the conservative approach to administration
of the root zone inhibits potential applicatons of the arpa zone.
Just one example is the notion of adding a DNAME record for an arpa
application - because such a record would be served using the shared
root infrastructure, it is assessed there would be the significant
impediment associated with all the due diligence that would go with
that. It is foreseeable that any future evolution of the arpa zone to
use new resource record types or other kinds of configuration changes
will be analysed through the lens of root operations so long as they
operate on shared infrastructure.

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

I don't foresee it as herculean, in fact, I think it represents
straightforward changes that will result in significant benefits. Other
zones, including top-level domains, change their authorities often and
it is not considered problematic — it is considered a normal part of
zone administration. The root zone is special as the entry point to the
DNS, but arpa is only drawn into this specialness by virtue of being on
shared infrastructure with the root.

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

Perhaps to level-set: the goal was not to convince this mailing list of
the need for a change, it was to get additional perspective to identify
potential problems that have not been foreseen with the approach. We
manage the arpa zone at the behest of the IAB, and in the context of
that relationship we'll ultimately agree the specifics of how to evolve
the zone.

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

What do you see as the operational impact of one versus the other? I
think before going into very specific levels of detail it should be
rooted in a discussion about the side-effects you are trying to avoid
and why they are specifically relevant to the arpa zone.

> Finally, by definition splitting the operations of the ARPA zone away from
> the current process increases the attack surface.

Can you elaborate further what you mean here? Are there any unique risks
that pertain to arpa you've identified, or the same general risks as
when you change the NS-set of any zone?

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

My take is this is a high-level expression of an operational change
that is notable, but the details that would underly its implementation
are not. Of course detailed plans are needed by the operator and other
directly involved parties, as is the case of any other zone, but such
ephemeral details are probably not best suited for RFCs.

I think the most useful thing is to identifying special considerations
that pertain uniquely the "arpa", as opposed to general concerns that
any other zone would have to consider, and highlight these issues and
how they are being addressed.

kim