Internet-Draft 3901bis October 2024
Yamamoto & Fiebig Expires 24 April 2025 [Page]
Workgroup:
dnsop
Internet-Draft:
draft-momoka-dnsop-3901bis-06
Obsoletes:
3901 (if approved)
Published:
Intended Status:
Best Current Practice
Expires:
Authors:
Momoka. Y
WIDE Project
T. Fiebig
MPI-INF

DNS IPv6 Transport Operational Guidelines

Abstract

This memo provides guidelines and documents Best Current Practice for operating authoritative and recursive DNS servers, given that queries and responses are carried in a mixed environment of IPv4 and IPv6 networks. It expands on RFC 3901 by now suggesting authoritative and recursive resolvers to operate on both IPv4 and IPv6.

This document obsoletes RFC3901. (if approved)

Discussion Venues

This note is to be removed before publishing as an RFC.

Source for this draft and an issue tracker can be found at https://github.com/momoka0122y/draft-dnsop-3901bis.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 24 April 2025.

Table of Contents

1. Introduction

Despite IPv6 being first discussed in the mid-1990s [RFC1883], consistent deployment throughout the whole Internet has not yet been accomplished [RFC9386]. Hence, today, the Internet is a mixture of IPv4, dual-stack (networks connected via both IP versions), and IPv6 networks.

This creates a complex landscape where authoritative name servers might be accessible only via specific network protocols [V6DNSRDY-23]. At the same time, DNS resolvers may only be able to access the Internet via either IPv4 or IPv6. This poses a challenge for such resolvers because they may encounter names for which queries must be directed to authoritative name servers with which they do not share an IP version during the name resolution process.

[RFC3901] was initially written at a time when IPv6 deployment was not widespread, focusing primarily on maintaining namespace continuity within the IPv4 landscape. Now, nearly two decades later, with IPv6 not only widely deployed but also becoming the de facto standard in many areas, this document seeks to expand the scope of RFC3901 by recommending IPv6 compatibility for authoritative and recursive DNS resolvers.

In this document, we discuss:

While transitional technologies and dual-stack setups may mitigate some of the issues of DNS resolution in a mixed protocol-version Internet, making DNS data accessible over both IPv4 and IPv6 is the most robust and flexible approach, as it allows resolvers to reach the information they need without requiring intermediary translation or forwarding services which may introduce additional failure cases.

1.1. Requirements Language

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. Terminology

This document uses DNS terminology as described in [RFC9499]. Furthermore, the following terms are used with a defined meaning:

IPv4 name server:
A name server providing DNS services reachable via IPv4. It does not imply anything about what DNS data is served, but requires DNS queries to be received and answered over IPv4.
IPv6 name server:
A name server providing DNS services reachable via IPv6. It does not imply anything about what DNS data is served, but requires DNS queries to be received and answered over IPv6.
Dual-stack name server:
A name server that is both an "IPv4 name server" and also an "IPv6 name server".

3. Name Space Fragmentation

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, based on the referral, only accessible over a transport which the resolver cannot use, the resolver is unable to continue DNS resolution.

If this occurs, the DNS has, effectively, fragmented based on the resolver's and authoritative's mismatching IP version support.

In a mixed IP Internet, fragmentation can occur for different reasons. One reason is that DNS zones are consistently configured to support only either IPv4 or IPv6. Another reason is due to misconfigurations that make a zone unresolvable by either IPv4 or IPv6-only resolvers. The latter cases are often hard to identify, as the impact of misconfigurations for only one IP version (IPv4 or IPv6) may be hidden in a dual-stack setting. In the worst case, a specific name may only be resolvable via dual-stack enabled resolvers.

4. Policy Based Avoidance of Name Space Fragmentation

With the final exhaustion of IPv4 pools in RIRs, e.g., [RIPEV4], and the progressing deployment of IPv6, there no longer is a "preferred" IP version. Yet, while we now observe the first zones becoming exclusively IPv6 resolvable, we also still see a major portion of zones solely relying on legacy IP [V6DNSRDY-23]. Hence, at the moment, dual stack connectivity is instrumental to be able to resolve zones and avoid name space fragmentation.

Having zones served only by name servers reachable via one IP version would fragment the DNS. Hence, we need to find a way to avoid this fragmentation.

The recommended approach to maintain name space continuity is to use administrative policies, as described in this section.

4.1. Guidelines for Authoritative DNS Server Configuration

It is usually recommended that DNS zones contain at least two name servers, which are geographically diverse and operate under different routing policies [IANANS]. To reduce the chance of DNS name space fragmentation, it is RECOMMENDED that at least two name servers for a zone are dual stack name servers. Specifically, this means that the following minimal requirements SHOULD be implemented for a zone:

IPv4 adoption:
Every authoritative DNS zone SHOULD be served by at least one IPv4-reachable authoritative name server to maintain name space continuity. The delegation configuration (Resolution of the parent, resolution of sibling domain names, GLUE) MUST not rely on IPv6 connectivity being available. As we acknowledge IPv4 scarcity, operators 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.
IPv6 adoption:
Every authoritative DNS zone SHOULD be served by at least one IPv6-reachable authoritative name server to maintain name space continuity. The delegation configuration (Resolution of the parent, resolution of sibling domain names, GLUE) MUST not rely on IPv4 connectivity being available.
Consistency:
Both IPv4 and IPv6 transports should serve identical DNS data to ensure a consistent resolution experience across different network types.
Avoiding Fragmentation:
IP fragmentation has been reported to be fragile [RFC8900]. Furthermore, IPv6 transition technologies can introduce unexpected MTU breaks, e.g., when NAT64 is used [RFC7269]. Therefore, IP fragmentation should be avoided by following guidance on maximum DNS payload sizes [I-D.ietf-dnsop-avoid-fragmentation] and providing TCP fall-back options [RFC7766].

Note: zone validation processes SHOULD ensure that there is at least one IPv4 address record and one IPv6 address record available for the name servers of any child delegation within the zone.

4.2. Guidelines for DNS Resolvers

Every recurisve DNS resolver SHOULD be dual stack.

While the zones that IPv6-only recursive DNS resolvers can resolve are growing but do not yet cover all zones, they cannot fully resolve all zones. Hence, a recursive resolver MAY be IPv6-only, if it uses a transition mechanism for IPv4 reachability [I-D.ietf-v6ops-ipv6-only-resolver] or uses a configuration where such resolvers forward queries failing IPv6-only DNS resolution to a set of dual-stack recursive name servers that perform the actual recursive queries.

Similarly, a recursive resolver MAY be IPv4-only, if it uses a configuration where such resolvers forward queries failing IPv4-only DNS resolution to a set of dual-stack recursive name servers that perform the actual recursive queries.

5. Security Considerations

The guidelines described in this memo introduce no new security considerations into the DNS protocol or associated operational scenarios.

6. IANA Considerations

This document asks IANA to update its technical requirements for authoritative name servers to require an IPv4 and an IPv6 address for each authoritative server [IANANS].

Acknowledgments

TODO: acknowledge people.

Thank you for reading this draft.

References

Normative References

[I-D.ietf-dnsop-avoid-fragmentation]
Fujiwara, K. and P. A. Vixie, "IP Fragmentation Avoidance in DNS over UDP", Work in Progress, Internet-Draft, draft-ietf-dnsop-avoid-fragmentation-20, , <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-avoid-fragmentation-20>.
[I-D.ietf-dnsop-ns-revalidation]
Huque, S., Vixie, P. A., and W. Toorop, "Delegation Revalidation by DNS Resolvers", Work in Progress, Internet-Draft, draft-ietf-dnsop-ns-revalidation-07, , <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-ns-revalidation-07>.
[RFC1883]
Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, DOI 10.17487/RFC1883, , <https://www.rfc-editor.org/info/rfc1883>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC3901]
Durand, A. and J. Ihren, "DNS IPv6 Transport Operational Guidelines", BCP 91, RFC 3901, DOI 10.17487/RFC3901, , <https://www.rfc-editor.org/info/rfc3901>.
[RFC7766]
Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and D. Wessels, "DNS Transport over TCP - Implementation Requirements", RFC 7766, DOI 10.17487/RFC7766, , <https://www.rfc-editor.org/info/rfc7766>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.

Informative References

[I-D.ietf-v6ops-ipv6-only-resolver]
Yamamoto, M. and Y. Toyota, "IPv6-only Capable Resolvers Utilising NAT64", Work in Progress, Internet-Draft, draft-ietf-v6ops-ipv6-only-resolver-00, , <https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6-only-resolver-00>.
[IANANS]
IANA, "Technical requirements for authoritative name servers", <https://www.iana.org/help/nameserver-requirements>.
[RFC7269]
Chen, G., Cao, Z., Xie, C., and D. Binet, "NAT64 Deployment Options and Experience", RFC 7269, DOI 10.17487/RFC7269, , <https://www.rfc-editor.org/info/rfc7269>.
[RFC8900]
Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., and F. Gont, "IP Fragmentation Considered Fragile", BCP 230, RFC 8900, DOI 10.17487/RFC8900, , <https://www.rfc-editor.org/info/rfc8900>.
[RFC9386]
Fioccola, G., Volpato, P., Palet Martinez, J., Mishra, G., and C. Xie, "IPv6 Deployment Status", RFC 9386, DOI 10.17487/RFC9386, , <https://www.rfc-editor.org/info/rfc9386>.
[RFC9499]
Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, RFC 9499, DOI 10.17487/RFC9499, , <https://www.rfc-editor.org/info/rfc9499>.
[RIPEV4]
RIPE NCC, "The RIPE NCC has run out of IPv4 Addresses", , <https://www.ripe.net/publications/news/about-ripe-ncc-and-ripe/the-ripe-ncc-has-run-out-of-ipv4-addresses>.
[V6DNSRDY-23]
Streibelt, F., Sattler, P., Lichtblau, F., Hernandez-Gañán, C., Gasser, O., and T. Fiebig, "How Ready is DNS for an IPv6-Only World?", , <https://link.springer.com/chapter/10.1007/978-3-031-28486-1_22>.

Authors' Addresses

Momoka Yamamoto
WIDE Project
Additional contact information:
山本 桃歌
WIDE Project
Tobias Fiebig
Max-Planck-Institut fuer Informatik
Campus E14
66123 Saarbruecken
Germany