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

[Kim Davies]

Hi Phillip,

Quoting Phillip Hallam-Baker on Friday August 07, 2020:
> 
> What has never been fully appreciate is that while the root zone is the
> apex of the naming hierarchy. The .arpa zone is potentially the apex of the
> trust hierarchy.

Any zone has the potential to be the apex of a trust hierarchy. Is there
any specific proposal pertaining to "arpa" itself that it be used in
such a way where it wouldn't be suitable to inherit trust using existing
mechanisms in the DNS?

> We should do it right because the .ARPA zone is evolving into the trust
> root of the legacy telephone system. 

I presume this is referring to the "e164.arpa" zone which is a distinct
zone from "arpa" and administered separately.

> What this means in practice is that as with the DNS apex root servers, the
> .ARPA root servers need to have stable, static IP addresses that change
> infrequently with long notice times. The zones should be signed using
> appropriate ceremonies.

I am not aware of any proposal that would require this. I suspect if
future technologies need different operational parameters for .ARPA
along these lines, then it would specified in the requirements for that
technology (i.e. as "IANA Considerations"), and the zone's operations
would adapt accordingly upon adoption. In the absence of any specific
reason to do this, placing an arbitrary requirement that the zone have
long-lived static IP addresses is burdensome and seems to run counter to
giving .ARPA new flexibility.

> So what I would suggest is:
> 1) Separate the hosts for .ARPA from the root zone hosts.
> 2) Create a separate set of HSMs for .ARPA but administer them within the
> ICANN root ceremony
> 3) Transition ARPA to next generation technology which avoids the need to
> meet to perform ceremonies in person.

Nothing in this proposal prejudices changes to how the KSK for the
"arpa" zone may evolve in the future. I would suggest any effort
to define new baseline requirements for the "arpa" KSK be handled
separately as they are distinct from the objective of this draft. The
goal here is to delink the day-to-day administration of .ARPA from
the root zone such as that .ARPA would be treated like any other TLD,
allowing it to evolve in its own direction at its own pace.

kim