Hi Could you please expand these PR URLS into this email thread?
thanks Geoff > On 9 Jan 2026, at 8:35 pm, Tobias Fiebig <[email protected]> > wrote: > > Good Morning, > >> 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. > > This point was already discussed in your prior review. This statement > is the result of WG consensus; To cite Tommy Jensen in reply to the > last review: > > "I agree there are real situations where IPv6 connectivity can be > guaranteed to be universally provided through an administered network > that requires this. I equally strongly oppose removing this MAY given > that this is only something a network operator can assert, not a > resolver operator when the roles are distinct. I think it is already > balanced." > > We read the subsequent response of: > > "I see that others have chimed on with responses to my DNSDIR review, > and I don't propose to add to that conversation here." > > As agreement to the WG's rational. Hence, we are somewhat confused to > see this point being brought up again. > >> 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]". > > The prior instance of this comment was addressed by Med suggesting a > definition to be added. We agree that explicit text provided might > improve readability. > > Please see the following PR: > https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-3901bis/pull/66 > >> 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. > > As previously discussed on the same point, forwarding is effectively > limited to one hop. An operator would have to consciously create a > specific corner-case to cause loops, and then would also need to use a > zone neither resolvable via IPv4 nor IPv6. This was already discussed > in response to your last review. > >> 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? > > RFC1035 defines an 'RD' bit in DNS queries. If it is present in a > query, a recursive resolver can safely assume that the query has not > been sent by a recursive resolver acting as a recursive resolver for > this specific query. > > We clarify this with the following PR: > https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-3901bis/pull/67 > >> 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. > > We still argue that this is a corner case that would require an > intentional misconfiguration on the recursive resolver operator's side. > > Nevertheless, we added corresponding text to the section, see: > https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-3901bis/pull/68 > >> 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. > > We hear the reviewers concerns. As already mentioned by Med earlier, > per RFC2026, a BCP: > > "is a vehicle by which the IETF community can define and ratify > the community's best current thinking on a statement of principle > or on what is believed to be the best way to perform > some operations or IETF process function." > > The present document falls under the RFC2026 BCP definition. > > With best regards, > Tobias > > -- > Dr.-Ing. Tobias Fiebig > T +31 616 80 98 99 > M [email protected] > Pronouns: he/him/his > > _______________________________________________ > 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]
