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

[George Michaelson <[e-mail]>]

I'm broadly comfortable with the document separation but it does beg the
question what is the impact of one or other of them being blocked, or left
to rot? Because if we're in an all-or-nothing world it needs to be called
out (I am pretty sure we aren't btw)

I am least comfortable with the last one. I think IANA would not want to be
given the task of judging suitability to list. The constraints behind when
you are added and why you had to be removed are all pretty torrid. Not that
I don't think there ARE minimum operational requirements but like "lameness
checks" in WHOIS I can't see they have strong force, can be enforced, or
that IANA could welcome being asked to enforce them.

That said, I do think there should be a published list. perhaps like the
OID registry, it's light touch management?

That aside, I like the intent. I would like to see resolver code developers
normalise the enabling of this feature. in fact I'd like to make the
operational norm.

-G (personal opinion only, no structural roles occupied whilst typing this
response)

On Thu, Jan 22, 2026 at 3:12 AM Wes Hardaker <[e-mail]> wrote:

>
> 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
>
> _______________________________________________
> DNSOP mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>