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?
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 :)
Paul W
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
