Wes and Warren, Thanks for this. Well written and IMHO very important to put the various methods in the right context. Having analysed root-server traffic via DITL data, I am acutely aware about the need for *complete* privacy protection. Since the best way to keep things secret is not to tell anyone, I see that LocalRoot fulfills that promise. The other methods go a long way, but do not stop your queries from ending up in, say, DITL data.
As a sidenote, this document may benefit from an operational cost/benefit section, compared to plain old DNS resolution. For instance, Qname-minimisation may lead to additional queries and thus latency; Encrypted and Authenticated may lead to more traffic due to session setup and breakdown, and thus latency. LocalRoot needs scaling and provisioning in different ways than RSS scaling. Keep this going, I am following this with interest! Warmly, Roy > On 1 Jun 2026, at 23:18, Wes Hardaker <[email protected]> wrote: > > > In the last DNSOP meeting we held two discussions about different > approaches to serving the root zone from DNS resolvers. The ensuing > discussion centered on "why something like LocalRoot / RootCache > technologies might be a good thing" and the discussion participants > specifically wanted to see what benefits LocalRoot / RootCache > technologies were providing that differed from existing technologies. > So I set out to produce a document showing the differences in > functionality brought to various problems by the following protocol > extensions when communicating with the root server system: > > - QName Minimization > - Aggressive NSEC > - Encrypted and Authenticated DNS > - Serve Stale > - DNSSEC > - LocalRoot > > [note: This is not so much a "versus" list as comparison, but the > subject line was shorter using "vs"] > > The first document below (draft-hardaker-dnsop-rss-usage-considerations) > has the complete write up. I'm sure it's not complete and other people > may have opinions (I hope). I don't necessarily think it needs to be > published in the long run, but is written as an IETF draft as that's > what we're all used to reading. > > If you just want a summary, here's the table from the end of it. > Obviously, I suggest you read the draft instead (it's short). > > |---------------|-----------|------------|-----------|-------------|--------|-----------| > | | QName-Min | Aggr.-NSEC | Encr/Auth | Serve-Stale | DNSSEC | > LocalRoot | > |---------------|-----------|------------|-----------|-------------|--------|-----------| > | Privacy | Signif | Signif | Moderate | | | > Complete | > | Disconnection | | | | Signif | | > Complete* | > | Auth Prot | | | Complete | | Signif | > Complete | > | Non-auth Prot | | | Complete | | Signif | > Complete | > | Bit Flipping | | | Signif | | Signif | > Signif | > | Latency | | Signif | | | | > Complete | > |---------------|-----------|------------|-----------|-------------|--------|-----------| > > [Signif = "Significant"] > > > Technology comparisons: > - > https://datatracker.ietf.org/doc/draft-hardaker-dnsop-rss-usage-considerations/ > > LocalRoot specific documents: > - https://datatracker.ietf.org/doc/draft-wkumari-dnsop-localroot-bcp/ > - https://datatracker.ietf.org/doc/draft-hardaker-dnsop-dns-xfr-scheme/ > - > https://datatracker.ietf.org/doc/draft-hardaker-dnsop-root-zone-publication-points/ > - > https://datatracker.ietf.org/doc/draft-hardaker-dnsop-root-zone-pub-list-guidelines/ > > > -- > Wes Hardaker > Google > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
