Paul, Thanks for your note. See comments inline below.
Steve On Tue, Nov 11, 2025 at 1:07 PM Paul Wouters <[email protected]> wrote: > On Tue, 11 Nov 2025, Paul Hoffman wrote: > > [mostly responding to Steve's message] > > >> 1. Transitioning to hyperlocal root zone access, as including designing > and deploying the infrastructure to distribute copies of the root zone to, > say, a million hyperlocal caches. > > > > The DNSOP WG would be the right place to specify how to do "hyperlocal > root zone access", as it did for RFC 7706 and RFC 8806. It is unclear where > work on transitioning to that mechanism would go. Maybe the IAB (it's > architecture), maybe DNSOP (it's DNS operations), maybe a new WG (it's a > departure, not an extension, to the current DNS), ... . > > Didn't it already do everything? It is now up to the OSes to use the > protocols we defined? > As more and more resolvers switch to using local copies of the root zone, there may be a need to strengthen the process of providing those copies to a very large set of resolvers. That's the part that is not yet scoped and may need design and implementation. > > >> 2. Redesign of the root zone update process to be fully encased in a > tamperproof enclosure, with updates of each portion of the zone requiring > cryptographic approval by the relevant TLD operator. A key ceremony > equivalent would also exist for the exceptional cases to override the > regular process, eg initiate a new TLD, replace lost device, etc. > > > > Maybe the IAB (it's architecture), maybe DNSOP (it's DNS operations), > maybe a new WG (it's a departure, not an extension, to the current DNS), > ... . > > I am not sure what this adds to the current deployment. The TLDs give > DS'es to the root. If there is ever a signature of root over something > the TLD operator did not submit as DS RRset, or a deep signed record > within that TLD for something else (SVCB, ECH, HTTPS, TLSA) then you > would have cryptographic evidence of root misbehaviour. > > If you want something that can prevent (some) abuse, you would be > better of having the independent rootzone operators provide a DNSKEY > and RRSIG over everyhing and run the root with 13 keys :P And you can > do "n of m" or just trust the root operators you trust for whatever > personal reasons you have, for example just trust F :) > The primary purpose of such a design is to prevent improper forceful removal of legitimate entries from the root zone. This is stronger than detecting the problem after the fact. > > Paul W > -- Sent by a Verified sender
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
