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