On Fri, 2026-01-09 at 21:27 +1100, Geoff Huston wrote: > Hi > > Could you please expand these PR URLS into this email thread?
Inline; > > > 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 diff --git a/draft-ietf-dnsop-3901bis.xml b/draft-ietf-dnsop- 3901bis.xml index b59ece6..bf8cb0d 100644 --- a/draft-ietf-dnsop-3901bis.xml +++ b/draft-ietf-dnsop-3901bis.xml @@ -39,7 +39,7 @@ <t indent="0" pn="section-abstract-1"> This document provides guidelines and documents Best Current Practice for operating authoritative DNS servers, recursive resolvers and stub resolvers in a mixed IPv4/IPv6 environment. This document recommends that both authoritative DNS servers and recursive resolvers support IPv4 and IPv6. - It also provides guidance on how recursive DNS resolvers should select upstream DNS servers when both native and IPv4- embedded IPv6 addresses are available. + It also provides guidance on how recursive DNS resolvers should select upstream DNS servers when both native, as well as IPv4-compatible or IPv4-mapped IPv6 addresses are available. </t> <t indent="0" pn="section-abstract-2"> This document obsoletes RFC 3901. @@ -325,7 +325,7 @@ </dt> <dd> Every DNS zone <bcp14>SHOULD</bcp14> be served by at least two IPv6-reachable authoritative DNS servers to maintain name space continuity. - To avoid reachability issues, authoritative DNS servers <bcp14>SHOULD</bcp14> use native IPv6 addresses instead of IPv4-converted IPv6 addresses for receiving queries. + To avoid reachability issues, authoritative DNS servers <bcp14>SHOULD NOT</bcp14> use IPv4-Embedded <xref target="RFC6052"/>, IPv4-Compatible, or IPv4-Mapped IPv6 Addresses <xref target="RFC4291"/> for receiving queries. The delegation configuration (Resolution of the parent, resolution of sibling domain names, glue) <bcp14>MUST NOT</bcp14> rely on IPv4 connectivity being available. </dd> <dt> @@ -441,6 +441,7 @@ <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.1034.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.1035.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2119.xml"/> + <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4291.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4821.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6052.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6724.xml"/> > > > > > 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 diff --git a/draft-ietf-dnsop-3901bis.xml b/draft-ietf-dnsop- 3901bis.xml index b59ece6..a5f3e6a 100644 --- a/draft-ietf-dnsop-3901bis.xml +++ b/draft-ietf-dnsop-3901bis.xml @@ -376,7 +376,7 @@ Similarly, a recursive DNS resolver <bcp14>MAY</bcp14> be IPv4-only, if it uses a configuration where such resolvers forward queries failing IPv4-only DNS resolution to a recursive DNS resolver that is able to perform DNS resolution over IPv6. </t> <t> - Finally, when responding to recursive queries sent by stub DNS resolvers, a DNS resolver SHOULD follow the above guidance on fragmentation avoidance (<xref target="guidelines-for-authoritative- dns-configuration"/>) for communication between authoritative DNS servers and recursive DNS resolvers analogously. + Finally, when responding to recursive queries, i.e., a query with the RD bit set <xref target="RFC1035"/>, a DNS resolver SHOULD follow the above guidance on fragmentation avoidance (<xref target="guidelines-for-authoritative-dns-configuration"/>) for communication between authoritative DNS servers and recursive DNS resolvers analogously. </t> </section> <section anchor="guidelines-for-dns-stub"> > > > 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 > > > diff --git a/draft-ietf-dnsop-3901bis.xml b/draft-ietf-dnsop- 3901bis.xml index b59ece6..2e3b83d 100644 --- a/draft-ietf-dnsop-3901bis.xml +++ b/draft-ietf-dnsop-3901bis.xml @@ -369,11 +369,11 @@ </t> <t> While the zones that IPv6-only recursive DNS resolvers can resolve are growing, they do not yet cover all zones. - Hence, a recursive DNS resolver <bcp14>MAY</bcp14> be IPv6-only, if it uses a transition mechanism that allows it to also query IPv4-only authoritative DNS servers, or uses a configuration where it forwards queries failing IPv6-only DNS resolution to a recursive DNS resolver that is able to perform DNS resolution over IPv4. + Hence, a recursive DNS resolver <bcp14>MAY</bcp14> be IPv6-only, if it uses a transition mechanism that allows it to also query IPv4-only authoritative DNS servers, or uses a configuration where it forwards queries failing IPv6-only DNS resolution to a dual- stack recursive DNS resolver, i.e., one that is also able to perform DNS resolution over IPv4. If a recursive DNS resolver is aware of a PREF64 to use for NAT64 <xref target="RFC6146"/>, either through static configuration or by discovering it (e.g., <xref target="RFC8781"/>), it <bcp14>MAY</bcp14> synthesize IPv6 addresses for remote authoritative DNS servers. </t> <t> - Similarly, a recursive DNS resolver <bcp14>MAY</bcp14> be IPv4-only, if it uses a configuration where such resolvers forward queries failing IPv4-only DNS resolution to a recursive DNS resolver that is able to perform DNS resolution over IPv6. + Similarly, a recursive DNS resolver <bcp14>MAY</bcp14> be IPv4-only, if it uses a configuration where such resolvers forward queries failing IPv4-only DNS resolution to a dual- stack recursive DNS resolver, i.e., one that is also able to perform DNS resolution over IPv6. </t> <t> Finally, when responding to recursive queries sent by stub DNS resolvers, a DNS resolver SHOULD follow the above guidance on fragmentation avoidance (<xref target="guidelines-for-authoritative- dns-configuration"/>) for communication between authoritative DNS servers and recursive DNS resolvers analogously. @@ -398,7 +398,34 @@ <section anchor="security-considerations"> <name>Security Considerations</name> <t> - The guidelines described in this memo introduce no new security considerations into the DNS protocol. + The guidelines described in this memo introduce no new security considerations into the DNS protocol itself. + </t> + <t> + Nevertheless, corner cases exist where forwarding queries requiring an IP address family for resolution that is not supported by the initial resolver lead to an endless loop, when: + </t> + <ul spacing="normal"> + <li> + <t>Two resolvers handle queries for a set of clients, and,</t> + </li> + <li> + <t>One of the resolvers only supports DNS resolution via IPv4, and,</t> + </li> + <li> + <t>The other resolver only supports DNS reslution via IPv6, and,</t> + </li> + <li> + <t>Both resolvers are configured to forward queries requiring DNS resolution via the IP address family they do not support to the other, and,</t> + </li> + <li> + <t>A query for a zone that is not resolvable via IPv4 and not resolvable via IPv6 is received.</t> + </li> + </ul> + <t> + In that case, a query for the non-resolvable zone would be endlessly forwarded between the resolvers. + </t> + <t> + To prevent this, single stack recrusive DNS resolvers <bcp14>SHOULD</bcp14> only be configured to forward queries they cannot resolve due to lacking support for one address family to dual-stack recursive DNS resolvers. + Furthermore, recursive DNS resolvers <bcp14>MUST NOT</bcp14> be configured to forward queries to DNS resolvers that are configured to forward queries to them in the first place, i.e., the above cornercase <bcp14>MUST</bcp14> be avoided. </t> <t> Recommendations for recursive and stub resolvers rely on a correctly discovered PREF64. > > -- 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]
