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]
