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

[Kim Davies]

Hi Paul,

Quoting Paul Wouters on Wednesday August 12, 2020:
> 
> > 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 am confused as to what would happen. Either, the root zone operators
> will drop the .arpa zone, or they will keep serving it under a new
> agreement. 

It is worth noting that basically the entire publication and distribution of
the arpa zone is not contracted or otherwise covered by any agreements: 

* The RZMA, where ICANN contracts Verisign to produce and disseminate the
  root zone to the RSOs, has no mention of .arpa;

* Agreements that exist right now for individual RSOs don't mention .arpa
  <https://www.icann.org/resources/pages/root-server-operators-2015-06-01-en>;

* RFC 2870, while superseded, for a long time stood stating root servers
  "MUST NOT provide secondary service for any zones other than the root
  and root-servers.net zones"

> If they keep servigin it, either they will use the same
> nameservers as for the root, or they will use different nameservers. If
> they use the same nameservers, then in practise nothing will change except
> some paperwork and people will still not want the new fancy RRTYPEs in
> the .arpa zone. If they will use different servers, why can't they do
> that right now?

Changing the hostnames of the nameservers appears to be a precursor to any
other kind of reconfiguration. It seems certain that .arpa can't have any
meaningfully differentiated service so long as it is using
{a-i,k-m}.root-servers.net as its NS-set.

But that doesn't mean the end goal is necessarily full separation!

The only concrete outcome proposed in this document is those hostname
changes, and there is text that notes fuller separation would comprise
changes in other areas as well. I think the need to progress down those
paths, and the pace required, will depend on a number of factors such
as whether there are new demands for the zone and whether the current
parties are willing to continue their roles. Just as for any other zone
operator, changes in the operational environment and evolving demands
for the zone will inform future planning.

> I am concerned that de-coupling .arpa might lead to the zone being
> underserved. Or that IETF needs to start budgeting for running this
> zone in the future itself. That might lead to instability as we
> currently don't even have enough money to pay salaries due to a
> pandemic and are temporarilly charging for things that we normally
> do for free (online participation).
> So from a risk management point of view, I see no reason for the
> IETF to make a change, unless we can guarantee some longterm plan
> for financing running the .arpa domain.

Because of the lack of contracts or agreements noted above, I don't
think there are any fundamental guarantees of service today and
presumably the current operators could withdraw service at their
discretion. Leaving the current configuration unmodified provides no
certainty of future success.

Identifying the proper operational expectations, and putting in place
any necessary agreements around that, I think is a component of maturing
the approach. Given running this domain is part of the IANA functions,
my assumption is any additional costs borne in operating it would likely
be borne as part of how the IANA functions are funded. This would mean
there would be public review and engagement process associated with
budget development on an annual basis.

kim