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

[Warren Kumari]

This seems to have died down, so I figured I'd ask if you'd managed to
pull anything like consensus out of it?

I intentionally didn't comment on the proposal, because, in my view
it's none of my business -- this is a purely operational change. The
IANA is responsible for making sure that lookups for things in .ARPA
resolve correctly; if decoupling it from the current architecture and
serving it using e.g a lightly toasted eggplant results in something
easier/better/stronger/faster, that's entirely the IANA's call.

It's nice to publish the plans and ask if it's going to break
anything/if anyone sees any issues (the root and arpa are somewhat
unusual), but as long as the queries still get answered correctly, how
you do so should be entirely your business.

The IANA is competent enough that if you say this will make things
better, I have no reason to doubt it.

W

On Fri, Aug 14, 2020 at 5:19 PM Kim Davies <kim.davies at iana.org> wrote:
>
> 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
>
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf