Elkins 26241 USA WV tjw.ietf@gmail.com

Ops DNSOP This memo provides guidelines and Best Current Practice for operating DNS in a world where queries and responses are carried in a mixed environment of IPv4 and IPv6 networks.

Introduction The Internet is well on its way to a mixture of IPv4 and IPv6 networks. The concern is that a resolver using only a particular version of IP and querying information about another node using the same version of IP can not do it because somewhere in the chain of servers accessed during the resolution process, one or more of them will only be accessible with the other version of IP.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. DNS terminology is as described in . The phrase "IPv4 name server" indicates a name server available over IPv4 transport. It does not imply anything about what DNS data is served. Likewise, "IPv6 name server" indicates a name server available over IPv6 transport. The phrase "dual-stack name server" indicates a name server that is configured to run both IPv4 and IPv6.

Name Space Fragmentation: following the referral chain A resolver that tries to look up a name starts out at the root, and follows referrals until it is referred to a name server that is authoritative for the name. If somewhere down the chain of referrals it is referred to a name server that is only accessible over a transport which the resolver cannot use, the resolver is unable to finish the task. With all DNS data only available over IPv4 transport everything is simple. IPv4 resolvers can use the intended mechanism of following referrals from the root and down while IPv6 resolvers have to work through a "translator", i.e., they have to use a recursive name server on a so-called "dual stack" host as a "forwarder" since they cannot access the DNS data directly. With all DNS data only available over IPv6 transport everything would be equally simple, with the exception of IPv4 recursive name servers having to switch to a forwarding configuration. The transition from IPv4 only to a mixture of IPv4 and IPv6, with three categories of DNS data depending on whether the information is available only over IPv4 transport, only over IPv6 or both. Having DNS data available on both transports is the optimal situation.

Policy Based Avoidance of Name Space Fragmentation Today there are only a small number of DNS zones that are available over IPv6-only. The recommended approach to maintain name space continuity is to use administrative policies, as described in the next section.

Common Causes of Name Resolution Failure in IPv6 Successful name resolution under IPv6 demands careful attention to certain configuration prerequisites. Configuration mistakes can be summarised to the following.

• Parent zone not IPv6-resolvable: For a zone to be resolvable via IPv6, the parent zones up to the root zone must be IPv6-resolvable. Any non-IPv6-resolvable zone breaks the delegation chain for all its children.
• No AAAA records for NS names: If none of the NS records for a zone in their parent zone have associated AAAA records, resolution via IPv6 is not possible.
• Missing GLUE: If the name from an NS record for a zone is in-bailiwick, i.e., the name is within the zone or below, a parent zone must contain an IPv6 GLUE record, i.e., a parent must serve the corresponding AAAA record(s) as ADDITIONAL data when returning the NS record in the ANSWER section.
• No AAAA record for in-bailiwick NS: If an NS record of a zone points to a name that is in-bailiwick but the name lacks AAAA record(s) in its zone, IPv6-only resolution will fail even if the parent provides GLUE, when the recursive server validates the delegation path. One such example is Unbound with the setting harden-glue: yes–the default.
• Zone of out-of-bailiwick NS not resolving: If an NS record of a zone is out-of-bailiwick, the corresponding zone must be IPv6-resolvable as well. It is insufficient if the name pointed to by the NS record has an associated AAAA record.

Recognizing and addressing these configuration requirements is fundamental to the seamless operation of DNS in an environment that blends IPv4 and IPv6. [https://link.springer.com/chapter/10.1007/978-3-031-28486-1_22]

DNS IPv6 Transport recommended Guidelines In order to preserve name space continuity, the following administrative policies are recommended:

• every recursive name server SHOULD support the local network configuration. If the local network supports both IPv4 and IPv5, the resolver SHOULD be dual stack.
• If the service is offering IPv4 as a Service (IPv4aaS), the recursive name server SHOULD accept IPv6, and support dual stack recursive methods.
• every authorative DNS zone SHOULD be dual stack IPv4/IPv6.

A DNS zone can be served by at least one IPv4-reachable authoritative name server. This rules out DNS zones served only by IPv6-only authoritative name servers. Note: zone validation processes SHOULD ensure that there is at least one IPv4 address record available for the name servers of any child delegations within the zone.

IANA Considerations None

Security Considerations None

Normative References Informative References

Acknowledgements Mark Andrews. No, really.