I think we can trust Petr's analysis, given that he works on the code in question. The erratum should be accepted.
--Paul Hoffman On Nov 14, 2025, at 04:14, RFC Errata System <[email protected]> wrote: > > The following errata report has been submitted for RFC8806, > "Running a Root Server Local to a Resolver". > > -------------------------------------- > You may review the report below and at: > https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid8634__;!!PtGJab4!9nLfxjFrVHQ1u8ztP6qVXxm3GAyTldDHVD2vDET-kvFGhOF239WM8pnHjmGh_3j5VNAIe93jeFmWdsIbstLwsMZcg4HQJTXOxA$ > [rfc-editor[.]org] > > -------------------------------------- > Type: Technical > Reported by: Petr Špaček <[email protected]> > > Section: B.1 > > Original Text > ------------- > view root { > match-destinations { 127.12.12.12; }; > zone "." { > type slave; > file "rootzone.db"; > notify no; > masters { > 199.9.14.201; # b.root-servers.net > 192.33.4.12; # c.root-servers.net > 199.7.91.13; # d.root-servers.net > 192.5.5.241; # f.root-servers.net > 192.112.36.4; # g.root-servers.net > 193.0.14.129; # k.root-servers.net > 192.0.47.132; # xfr.cjr.dns.icann.org > 192.0.32.132; # xfr.lax.dns.icann.org > 2001:500:200::b; # b.root-servers.net > 2001:500:2::c; # c.root-servers.net > 2001:500:2d::d; # d.root-servers.net > 2001:500:2f::f; # f.root-servers.net > 2001:500:12::d0d; # g.root-servers.net > 2001:7fd::1; # k.root-servers.net > 2620:0:2830:202::132; # xfr.cjr.dns.icann.org > 2620:0:2d0:202::132; # xfr.lax.dns.icann.org > }; > }; > }; > > view recursive { > dnssec-validation auto; > allow-recursion { any; }; > recursion yes; > zone "." { > type static-stub; > server-addresses { 127.12.12.12; }; > }; > }; > > Corrected Text > -------------- > // Warning: > // Error handling and transitional states of a server with this > // configuration do not conform to the requirements given in > // this document. > > view root { > match-destinations { 127.12.12.12; }; > zone "." { > type slave; > file "rootzone.db"; > notify no; > masters { > 199.9.14.201; # b.root-servers.net > 192.33.4.12; # c.root-servers.net > 199.7.91.13; # d.root-servers.net > 192.5.5.241; # f.root-servers.net > 192.112.36.4; # g.root-servers.net > 193.0.14.129; # k.root-servers.net > 192.0.47.132; # xfr.cjr.dns.icann.org > 192.0.32.132; # xfr.lax.dns.icann.org > 2001:500:200::b; # b.root-servers.net > 2001:500:2::c; # c.root-servers.net > 2001:500:2d::d; # d.root-servers.net > 2001:500:2f::f; # f.root-servers.net > 2001:500:12::d0d; # g.root-servers.net > 2001:7fd::1; # k.root-servers.net > 2620:0:2830:202::132; # xfr.cjr.dns.icann.org > 2620:0:2d0:202::132; # xfr.lax.dns.icann.org > }; > }; > }; > > view recursive { > dnssec-validation auto; > allow-recursion { any; }; > recursion yes; > zone "." { > type static-stub; > server-addresses { 127.12.12.12; }; > }; > }; > > Notes > ----- > This requirement is not met by the listed configuration: > In a resolver that is using an internal service for the root zone, if the > contents of the root zone cannot be refreshed before the expire time in the > SOA, the resolver MUST immediately switch to using non-local root servers. > > Also, resolution will fail during server startup - before root zone is > transferred for the first time. I would not be surprised if other edge cases > are also non-conformant. > > That is a feature (= intended behavior) of the listed configuration, not a > bug in implementation. > > Instructions: > ------------- > This erratum is currently posted as "Reported". (If it is spam, it > will be removed shortly by the RFC Production Center.) Please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > will log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC8806 (draft-ietf-dnsop-7706bis-12) > -------------------------------------- > Title : Running a Root Server Local to a Resolver > Publication Date : June 2020 > Author(s) : W. Kumari, P. Hoffman > Category : INFORMATIONAL > Source : Domain Name System Operations > Stream : IETF > Verifying Party : IESG _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
