On Fri, Nov 14, 2025 at 2:44 PM, Paul Hoffman <[email protected]>
wrote:

> I think we can trust Petr's analysis, given that he works on the code in
> question. The erratum should be accepted.
>


Yup, agreed….

W


> --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]

Reply via email to