[DNSOP] 4 documents for consideration about the future of LocalRoot behavior.

[Wes Hardaker <[e-mail]>]

Greetings DNSOP,

10 years has passed (!) since the publication of RFC7706 (later followed by RFC8806), which specified how resolvers can integrate a copy of the root zone into their local operational environment.  A lot of experience has been gained since then, from a fair amount of implementation and deployment.  A number of observations during this period have been made surrounding the feasibility of running an authoritative engine on the loopback like the current RFCs suggest, along with improvements to use other protocols like HTTP(S) for collecting data.  
Finally, the RFC7706 and RFC8806documents were published as Informational and it is now time to consider whether downloading and making use of root zone data directly during resolution should be a Proposed Standard or a BCP so that more resolvers gain the benefit from incorporating locally cached root zone data into their resolution processes.  To this end, the following four documents have been published for consideration.  They each discuss/solve a different piece of the problem space and certainly could be kept separated or combined further in the future if need be.

- https://datatracker.ietf.org/doc/draft-wkumari-dnsop-localroot-bcp/

This document name is a misnomer at the moment as based on discussions the authors have had to date we have actually targeted it as proposed standard instead.  This document is functionally a complete replacement of RFC8806 (more than just a bis), based on the experiences and deployment discussed above.  Specifically, it relaxes the requirement for running as an authoritative engine on the loopback in parallel with a resolver, and instead describes the requirements of an implementation rather than a specific required implementation mechanism (actual implementations varied code base to code base). The new document also discusses the larger aspects of being configured with or gathering a list of publication points and some guidelines and requirements around querying multiple publication points for the IANA root zone data.


- https://datatracker.ietf.org/doc/draft-hardaker-dnsop-root-zone-publication-points/

This document should be considered a starting discussion around how a list of publication points can be gathered and consumed for where root zone data is available.  Right now the list of available sources are only available in Appendix A of RFC8806, but this document discusses how to make a real list and its format published by IANA containing URLs of publication points.

Note: the format in this draft is just a starting point for discussion – I honestly expect something like signed json to win in the end.

- https://datatracker.ietf.org/doc/draft-hardaker-dnsop-dns-xfr-scheme/

If we have URLs for publication points, then we need to be able to refer to targets of axfr, ixfr, and xot appropriately.  Thus this short document specifies new URLs schemes for zone transfers over DNS.

- https://datatracker.ietf.org/doc/draft-hardaker-dnsop-root-zone-publ-list-guidelines

This document may or may not be needed based on WG and IANA opinions.  Fundamentally, it outlines guidelines for what the minimum operational requirements are for being listed on the IANA publication point list above.  It may be that if all these documents go forward in one way or another, this one gets dropped to letting IANA just do whatever it deems best, or the IETF may want to provide some minimal guidance.

The authors will certainly be having discussions with IANA and ICANN about the documents that directly affect them.

—--

We look forward to the discussion within DNSOP about each of these topics.  I’d suggest for now that we concentrate on whether or not each is needed, and not whether or not they’re best kept in 4 documents vs a smaller number.  And certainly the author/editors list of all documents is likely to change as well as time goes on.

(and with that, I'm going to lose internet connectivity for a day while I wiggle into my flame retardant suit)
-- 
Wes Hardaker
Google