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

[Kim Davies]

Hi Warren,

Quoting Warren Kumari on Thursday August 20, 2020:
> This seems to have died down, so I figured I'd ask if you'd managed to
> pull anything like consensus out of it?

This thread has triggered discussions in other groups, and I've been
asked to present the topic to three of them in the coming few weeks.
I've not received any feedback that the approach has fundamental flaws,
but I am eager to hear of any concerns or perspective they have before
taking additional steps.

kim
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

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

[Wes Hardaker]

Kim Davies  writes:

> > 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
>   ;
> 
> * 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"

Though we don't have an agreement on the above mentioned page, speaking
with my USC/ISI root server operator hat on: we're here to do as the
community needs and if there is a desire to separate .arpa away from the
infrastructure that serves the root, great.  If there is a desire to
keep them together, great: we certainly won't stop serving it as "that
would be (extremely) bad for the Internet".  I suspect some of these
questions surrounding the long standing missing contracts/mous/etc
around the service of the root, root-servers.net and probably .arpa will
probably/hopefully come out of the ICANN GWG as well.  Whether to push
this work forward, and whether to push it forward before or after the
GWG's done with their work is something that the community needs to
carefully consider.

-- 
Wes Hardaker
USC/ISI
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [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  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
>   ;
>
> * 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@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



-- 
I don't 

Re: [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
  ;

* 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@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

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

[John Levine]

In article  you write:
>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.

If ever there were a place *not* to deploy whizzo new DNS technology,
the root is it. We don't need features, we need stability and
reliability. The fewer changes the better.

I note that this change is primarily a change to the .ARPA domain and
the only change to the root is changing NS and glue which we know they
can change reliably because they've done it for lots of other TLDs.

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

Rater than assuming that ICANN is incompetent, why don't we ask Kim
what the provisioning strategy will be.

R's,
John
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [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
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [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 

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

[Kim Davies]

Quoting John Levine on Friday August 07, 2020:
> 
> One can download the .ARPA zone files from the same places as the root
> zone, by https or ftp from internic.net and by AXFR from two icann.org
> servers. Will that change? As far as I know it's not documented
> anywhere; you just have to know it's in the same places as the root.

No changes planned in that regard, and my expectation is all the same 
locations for download will continue to work as today.

kim
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

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

[Dave Lawrence]

Kim Davies writes:
> 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.

I very much agree with this.  That said, I would like to see that
Phillip's proposal for evolving the key ceremony is pursued as well.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [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
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations