Telechat Review of draft-ietf-dnsop-3901bis-10
review-ietf-dnsop-3901bis-10-dnsdir-telechat-huston-2026-01-08-00

Many of the issues raised in my previous review of this draft have been
addressed. There are, however, a number of issues which have not been
addressed and are repeated here, as they remain significant unresolved
issues, in my opinion.

1. Section 4.1, "IPv4 Adoption": "Given the IPv4 address scarcity, operator
   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 assume that it can apply a constraint or otherwise limit the
   clients that query it. The conditional expression in this text relating
   to ensuring all client can support DNS resolution via IPv6 transport
   appears to contradict the context of the public Internet. This sentence
   appears to be out of place in a BCP relating to the DNS on the public
   internet.
   
2. Section 4.1. "IPv6 adoption": "Authoritative DNS servers SHOULD use
   native IPv6 addresses instead of IPv4-converted IPv6 addresses for
   receiving queries." Neither RFC4291, nor RFC 6052 define a
   "IPv4-converted IPv6 address." The draft should state that:
   "Authoritative DNS servers SHOULD NOT use IPv4-Compatible IPv6 Addresses
   and IPv4-Mapped IPv6 Address [RFC4291]".
     
3. Section 4.2:  "..a configuration where it forwards queries.." Embedding
   non-explicit forwarding of queries in the DNS resolution process is not
   exactly an example of Best Current Practice. The DNS has no form of query
   loop detection or excessive resolver query chain detection, and
   application of this practice of query forwarding between recursive
   resolvers is best avoided, as a general behaviour. I suggest that all
   references to query forwarding by recursive resolvers should be removed
   in Section 4.2.

4. Section 4.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?

5. Section 5. Security Considerations: "introduce no new security
   considerations into the DNS protocol." This reviewer 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
   existing advice relating to resover-to-resolver forwarding in this document.
   
Also, I have seperately noted my reservation regading the inappropriate use of
Best Current Practice classification for documents that do not describe
what is understood to be current operational practice, and for completeness I am
repeating that reservation here.