Internet DRAFT - draft-tjw-dnsop-3901bis

draft-tjw-dnsop-3901bis







DNSOP                                                  T. Wicinski. (ed)
Internet-Draft                                           23 October 2023
Obsoletes: 3901 (if approved)                                           
Intended status: Best Current Practice                                  
Expires: 25 April 2024


               DNS IPv6 Transport Operational Guidelines
                       draft-tjw-dnsop-3901bis-01

Abstract

   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.

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 25 April 2024.

Copyright Notice

   Copyright (c) 2023 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.





Wicinski. (ed)            Expires 25 April 2024                 [Page 1]

Internet-Draft                   3901bis                    October 2023


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Name Space Fragmentation: following the referral chain  . . .   2
   4.  Policy Based Avoidance of Name Space Fragmentation  . . . . .   3
   5.  Common Causes of Name Resolution Failure in IPv6  . . . . . .   3
   6.  DNS IPv6 Transport recommended Guidelines . . . . . . . . . .   4
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   10. Informative References  . . . . . . . . . . . . . . . . . . .   5
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

1.  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.

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

   The phrase "IPv4 name server" indicates a name server available over
   IPv4 transport.  It does not imply anything about what DNS [RFC1034]
   [RFC1035] data is served.  Likewise, "IPv6 name server" [RFC3596]
   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.

3.  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.



Wicinski. (ed)            Expires 25 April 2024                 [Page 2]

Internet-Draft                   3901bis                    October 2023


   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.

4.  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.

5.  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.





Wicinski. (ed)            Expires 25 April 2024                 [Page 3]

Internet-Draft                   3901bis                    October 2023


   *  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 (https://link.springer.com/
   chapter/10.1007/978-3-031-28486-1_22)]

6.  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.

7.  IANA Considerations

   None





Wicinski. (ed)            Expires 25 April 2024                 [Page 4]

Internet-Draft                   3901bis                    October 2023


8.  Security Considerations

   None

9.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <https://www.rfc-editor.org/info/rfc1034>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
              "DNS Extensions to Support IP Version 6", STD 88,
              RFC 3596, DOI 10.17487/RFC3596, October 2003,
              <https://www.rfc-editor.org/info/rfc3596>.

10.  Informative References

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8499]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
              Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
              January 2019, <https://www.rfc-editor.org/info/rfc8499>.

Acknowledgements

   Mark Andrews.  No, really.

Author's Address

   Tim Wicinski
   Elkins, WV 26241
   United States of America
   Email: tjw.ietf@gmail.com







Wicinski. (ed)            Expires 25 April 2024                 [Page 5]