Dear Geoff, Thank you for clarifying the source of the underlying concerns voiced in your review.
Your concern of the role of 3901bis as BCP parallels RFC6540 (BCP 177) "IPv6 Support Required for All IP-Capable Nodes" published in 2012. We propose to explicitly reference RFC 6540 (BCP 177) in the introduction. https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-3901bis/pull/65 I hope this change addresses your concern. Momoka Y On Wed, Jan 7, 2026 at 9:11 AM Geoff Huston <[email protected]> wrote: > My apologies for the delay in response as I took a break from email over > the > Christmas and New Year period. > > I see that others have chimed on with responses to my DNSDIR review, and I > don't propose to add to that conversation here. > > More generally, in my review I had taken an interpretation of the role of a > BCP document that the purpose of as BCP is to describe what is regarded as > current operational practices that result in service outcomes that are > reliable and efficient. I personally don't see a role for such documents > advocating what should (or should not) be an operational practice that is > not in common use today and the underlying rationale for such advocacy. > Informally, I see a BCP as saying "this is what we do operationally today > to > support a reliable and efficient service." > > In my view, this particular document heads into a proselytising mode that > esposes a possible future operational practice, "best" or otherwise. I > realise that this mode is standard operational practice for many IPv6 > evangelists, but for me such an approach confuses a factual description of > current reality with a desired outcome. > > It appears to me that _as an Informational RFC_, this draft is as ready as > it will ever be, and its a fine document. As a BCP, however, it is Not > Ready > in my view, as it strays beyond the role of a BCP. > > regards, > > Geoff > > > > > On 20 Dec 2025, at 6:07 am, Tobias Fiebig <tobias= > [email protected]> wrote: > > > > Dear Reviewer, > > > > thank you for your thoughtful feedback on our submission. After > > carefully reading your comments. To solicit further input from the WG, > > we also put the WG in Cc:; we would like to address your suggestions in > > the following ways: > > > >> 2 Section 3.3 - " At the time of writing" -> This reference is > >> already 2 > >> years old. Perhaps the document should explicitly state this as a > >> reference to measurements undertaken in 2023, as per the citation > > > > We would address this comment with the following PR: > > https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-3901bis/pull/58 > > > >> Issues: > >> > >> 1 Section 3 is a treatise on on the pontential fragmentary pressures > >> on a [...] Restating at length material from other DNS literature, > >> including RFCs, appears to this reviewer to wander from the intended > >> scope and purpose of this proposed revision to RFC3901. > > > > Inclusion of this section in its verbatim nature esp. regarding IP > > layer fragmentation has been the result of extensive discussions on the > > DNSOP mailinglist. Especially in 2024, prominent voices were notably > > adamant about including this text. > > > > Beyond that, the section also provides necessary context and background > > for non-fragmentation related aspects of the document, esp. in the > > context of NS validation at delegation time, as it also discusses Zone > > Misconfigurations (3.1) and intentional reasons (3.3) for namespace > > fragmentation; > > > > We would hence argue that, also following the extensive WG discussion, > > changes here are not strictly necessary. > > > > > >> 2 Section 4.1 "It is usually recommended that DNS zones contain at > >> least two name servers, which are geographically diverse and operate > >> under different routing policies [IANANS]." This reference to advice > >> from the IANA is advice that explicitly limits itself to > >> consideration of the root zone, and delegations in the TLDs .int and > >> .arpa, and does not purport to describe a usual case. Either the > >> text should be modified toi note the intended limited scope of the > >> IANA advice, or other DNS literature should be cite to justify this > >> claim. > > > > We would address this comment with the following PR: > > https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-3901bis/pull/59 > > > >> 3 Section 4.1: "RECOMMENDED that at least two name servers for a > >> zone are dual-stack name servers." There is no justification for this > >> recommendation, [...] The reviewer suggests that this recommendation > >> be rewritten to address a requrement for resilience in each protocol > >> familty. > > > > We would address this comment with the following PR: > > https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-3901bis/pull/60 > > > >> 4. Section 4.1: "IPv4 adoption: Every DNS zone SHOULD be served by at > >> least one IPv4-reachable authoritative DNS server". It appears that > >> the intent of the RECOMMENDATION in the previous paragragh is that > >> there is a minimum of TWO IPv4-reachable authoritative DNS servers. > >> Which is it? > > > > We would address this comment with the following PR: > > https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-3901bis/pull/61 > > > >> 5. Section 4.1: "Given the IPv4 address scarcity, operators MAY opt > >> not to provide DNS services via IPv4, if they can ensure that all > >> clients expected to resolve this zone do support DNS resolution via > >> IPv6." [...] The review suggests that this sentence has no place in a > >> BCP relating to the DNS on the public internet, and should be > >> removed. > > > > This author would like to respectfully disagree on this point. > > Operators expressed the need to at least have the option of creating > > domain specific services, e.g., an ISP who mostly provides IPv6 > > connectivity, that are IPv6 only, if they know that all clients to > > expect will have IPv6 connectivity. > > > > To ensure consensus in this point, the document leave the option (BCP14 > > MAY) to operators. > > > >> 6. Section 4.1: "To avoid reachability issues, authoritative DNS > >> servers SHOULD use native IPv6 addresses instead of IPv4-converted > >> IPv6 addresses for receiving queries." [...] the reviewer dowa not > >> believe that "native IPv6 addresses" is a well defined term in the > >> IPv6 address architecture. > > > > We would address this comment with the following PR: > > https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-3901bis/pull/57/files > > > > > >> 7. Section 4.1: "IPv6 adoption: Every DNS zone SHOULD be served by at > >> least one IPv6-reachable authoritative DNS server". It appears that > >> the intent of the RECOMMENDATION in the previous paragragh is that > >> there is a minimum of TWO IPv6-reachable authoritative DNS servers. > >> Which is it? > > > > We would address this comment with the following PR: > > https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-3901bis/pull/61 > > > >> 8. Section 4.1 Avoiding IP Fragmentation: This appears to be a more > >> concise treatment of the material [...] This reviewer suggests that > >> the material in Section 3 can be dropped in favour of this treatment > >> in Section 4.1. > > > > Please revisit our response to Point 1. > > > >> 9. Section 4.2: "Every recursive DNS resolver SHOULD be dual-stack." > >> This is not justified in the body of the document, [...] If > >> autheorativbe servers follow the recommendations on Section 4.1 then > >> it would appear thathere is no generic requirement for all recursive > >> resolvers to be dual-stacked in every instance. > > > > Especially this section has been extensively discussed in DNSOP, also > > during 124. There, operators also noted the progressing decline of IPv4 > > connection quality they observe in practice. > > > > The WG ultimately converged to the above recommendation, which includes > > a point on query forwarding, which has not been considered in this > > comment (see below). > > > >> 10. Section 4.2: "..a configuration where it forwards queries.." > >> Embedding non-explicit forwarding of queries in the DNS resolution > >> process is not exactly an instance of Best Current Practice. [...] > >> This reviewer suggests removing all references to query forwarding by > >> recursive resolvers in Section 4.2. > > > > The suggestion provided here would effectively only cause the issue > > identified above. The text is clear on leaving transition technologies, > > including using a dedicated upstream for non AFI resolvable names; > > Also, the text explicitly notes that the forwarded to system must have > > capabilities for the concerned AFI resolution. > > > > As such, we would again respectfully disagree with the reviewer on this > > issue, and point towards the text resulting from WG discussion instead. > > > >> 11. Section4.2: "when responding to recursive queries sent by stub > >> DNS". How can a recursive resolver know that a query has been sent by > >> a stub resolver? > > > > For all practical matters, any query received by a recursive resolver > > has been issued by either a stub resolver, or by another recursive > > resolver unable to perform recursion and, hence, in that instance, > > acting as a stub resolver. > > > >> 12. Section 5. Security Considerations: "introduce no new security\ > >> considerations into the DNS protocol." This reviewr differs with > >> respect to the recommendation that under certain circumstances a > >> recursive resolver may forward a query to another recursive resolver. > >> As already noted, the DNS resolution protocol has no form of query > >> loop detection or excessive resolver query chain detection, and there > >> is the potential for scenarios that can be used to launch a DOS > >> attacks on recursive resolvers. The authors should reconsider this > >> section in the light of the advice relating to resover-to-resolver > >> forwarding in this document. > > > > The reviewers concern is being heard. However, the text in the document > > clearly only leads to one(1) forwarding hop (if the necessary AFI is > > not supported by the recursive resolver first receiving the query). > > > > Theoretically, one could intentionally misconfigure a set of two single > > stack recursive resolver to allow for an infinite loop of a query if > > the query was neither resolvable via IPv4 nor IPv6. However, at the > > moment, it is unclear to this author how such a scenario could be > > created in practice. > > > > It would be appreciated if a working example could be provided by the > > reviewer who voiced the concern. > > > > > > With best regards, > > Tobias > > > > -- > > Dr.-Ing. Tobias Fiebig > > T +31 616 80 98 99 > > M [email protected] > > > > _______________________________________________ > > 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] >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
