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

[Paul Wouters]

On Mon, 10 Aug 2020, Kim Davies wrote:

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

I agree the draft should clarify this as without a good use case, this
entire endeavour would not be needed.

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

If only we had CNS records :)

> 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'm sad to see that the root infrastructure, an infrastructure that is
ideal to update partially due to its extreme redundancy, would be a
place where we keep old stuffy software instead of keeping up to date
with new DNS technology. I feel this might almost be a reason to do
this, as to ensure that the root servers keep up to date (and spec)

> I don't foresee it as herculean, in fact, I think it represents
> straightforward changes that will result in significant benefits.

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

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.

Paul