Not Ready I have been assigned as the DNS Directorate reviewer of this draft. I have identified the following issues with this draft and the I suggest that these issues should be addressed before the draft advances towards publication as a BCP. Minor Nits: 1 Section 2 - Terminology : "recrusive" -> "recursive" 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 Issues: 1 Section 3 is a treatise on on the pontential fragmentary pressures on a single name space when a transport protocol-based failure to resolve a name may result in different views of the same name space when exclusively using one protocol or another. This section appears to this reviewer to stray from the purpose of a BCP document, namely to provide a description of guidelines, processes, and methods that are considered the best engineering judgment for designing, using, and managing the Internet. Some level of justification such processes and methods, but the material in Section 3 goes further than a brief justification and presents some general descriptions of DNS pathologies and remedial configuration settings for DNS servers and resolvers. 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. 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. 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, and there are clearly other ways of providing resilience in the DNS for single-stack DNS resolvers. For example, using two nameserve names that are accessible using IPv4-only and a further twp nameserver names that are acessible using IPv6-only meets the same requirement of resilience in both protocols. The reviewer suggests that this recommendation be rewritten to address a requrement for resilience in each protocol familty. 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? 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." In the context of the public Internet (which is the intended context of RFC3901 and presumably the intended context of this draft that proposes updating it), a DNS server is a promiscuous server and SHOULD NOT constraint or limit the clients that query it. The conditional expression in this text relating to ensuring all client c an support DNS resolution via IPv6 appears to contradict the context of the public Internet. The review suggests that this sentence has no place in a BCP relating to the DNS on the public internet, and should be removed. 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." Perhaps the draft should state that authoritative DNS servers SHOULD NOT use IPv4-Compatible IPv6 Addresses and IPv4-Mapped IPv6 Address [RFC4291]", as the reviewer dowa not believe that "native IPv6 addresses" is a well defined term in the IPv6 address architecture. 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? 8. Section 4.1 Avoiding IP Fragmentation: This appears to be a more concise treatment of the material in Section 3 in the subsections "DNS-over-UDP packets requiring fragmentation" and "DNS-over-TCP packets requiring fragmentation". This reviewer suggests that the material in Section 3 can be dropped in favour of this treatment in Section 4.1. 9. Section 4.2: "Every recursive DNS resolver SHOULD be dual-stack." This is not justified in the body of the document, and as such probably deserves further thought. Stub resolvers are encouraged to use a local configuration that has two (or more) recursive resolvers, and in such a scenario the stub resolver has recovery options if one of the configured recursive resolvers is unreachable. Secondly, there still exist many access networks in the public Internet where there is no IPv6 deployment. In such context this recommendation for local recursive resolver to be dual-stacked for its function of responding to the queries from the set of local stub resolvers makes no sense. At the very least this recommendation should be considered in respect to the stub-resolver-facing role of a recursive resolver and the authoritative server-facing role. 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. 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. The DNS has no form of query loop detection or excessive resolver query chain detection, and application of this practice in resolver implementations should be avoided as a general behaviour. This reviewer suggests removing all references to query forwarding by recursive resolvers in Section 4.2. 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? 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.