Internet DRAFT - draft-v6ops-byrne-dnssecaaaa

draft-v6ops-byrne-dnssecaaaa



 



INTERNET-DRAFT                                                  C. Byrne
Intended Status: Informational                              T-Mobile USA
Expires: January 1, 2019                                   June 30, 2018


              DNSSEC Resource Record Should Include AAAA 
                    draft-v6ops-byrne-dnssecaaaa-00


Abstract

   DNS64 is a widely deployed technology allowing hundreds of millions
   of IPv6-only hosts to reach IPv4-only resources.  DNSSEC is a
   technology used to validate the authenticity of information in the
   DNS. Currently, there are scenarios where DNS64 and DNSSEC do not
   work well together. This document states that any DNSSEC signed
   resources record should include a native IPv6 resource record as the
   most complete and expedient path to solve any deployment conflict
   with DNS64 and DNSSEC. 


Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright and License Notice

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

 


<Byrne>                 Expires January 1, 2019                 [Page 1]

INTERNET DRAFT   <DNSSEC Resource Should Include AAAA>     June 30, 2018


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://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 Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



Table of Contents

   1  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  The conflict between DNS64 and DNSSEC  . . . . . . . . . . . .  3
   3.  Resolving the DNS64 and DNSSEC Conflict  . . . . . . . . . . .  3
   3  Security Considerations . . . . . . . . . . . . . . . . . . . .  4
   4  IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  4
   5  Informative References  . . . . . . . . . . . . . . . . . . . .  4
   Authors Address  . . . . . . . . . . . . . . . . . . . . . . . . .  4



























 


<Byrne>                 Expires January 1, 2019                 [Page 2]

INTERNET DRAFT   <DNSSEC Resource Should Include AAAA>     June 30, 2018


1  Introduction

   DNS64 [RFC6147] has documented scenarios where DNS64 may negatively
   interact with DNSSEC [RFC4033].  This document simply states the most
   complete and expedient path to avoid any negative interactions is for
   the DNSSEC signed resources to always include IPv6 AAAA resources
   records. As stated in [RFC6540], IPv6 [RFC8200] is not optional and
   failing to support IPv6 may result in failure to communicate on the
   internet, especially when DNSSEC signed IPv4-only resources are
   present.  

2.  The conflict between DNS64 and DNSSEC

   DNS64 is a key part of widely deployed IPv6-only transition mechanism
   such as 464XLAT [RFC6877] and Happy Eyeballs Version 2 [RFC8305]. 
   Currently, hundreds of millions of host rely on DNS64 for access to
   the internet.  A core function of DNS64 is generating an inauthentic
   AAAA DNS record when an authentic AAAA DNS record for a host is not
   available from the authoritative namesever.  DNSSEC's fundamental
   feature is detecting and denying inauthentic DNS resource records. 
   While [RFC6147] outlines how DNS64 and DNSSEC may work in harmony,
   the preconditions may not always exist for harmony to be achieved  

3.  Resolving the DNS64 and DNSSEC Conflict 

   DNS64 and DNSSEC are both important components of the current and
   future internet.  The limitation for how these protocols interact is
   unlikely to changes.  Deploying DNSSEC and IPv6 are both commonly
   achievable for a typical internet system operator using their own
   systems or using a third party service.  The resolution to the DNS64
   and DNSSEC conflict is to simply deploy both IPv6 and DNSSEC in
   tandem.  Deploying DNSSEC signed IPv4 resources records without
   matching IPv6 records is a risk and not recommend.  Ultimately, this
   guidance is simply restating [RFC6540] that IPv6 is mandatory for all
   internet systems.













 


<Byrne>                 Expires January 1, 2019                 [Page 3]

INTERNET DRAFT   <DNSSEC Resource Should Include AAAA>     June 30, 2018


3  Security Considerations

   DNSSEC is a good security practice.  Providing AAAA DNSSEC signed
   records wherever a DNSSEC signed A record is used ensures the  most
   effective use of DNSSEC.

4  IANA Considerations

   None.


5  Informative References

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC4033, March 2005.
   [RFC6540]  George, W., Donley, C., Liljenstolpe, C., and L. Howard,
              "IPv6 Support Required for All IP-Capable Nodes", BCP 177,
              RFC 6540, DOI 10.17487/RFC6540, April 2012,
              <https://www.rfc-editor.org/info/rfc6540>.
   [RFC6147]  Bagnulo, M., Sullivan, A., Matthews, P., and I. van
              Beijnum, "DNS64: DNS Extensions for Network Address
              Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
              DOI 10.17487/RFC6147, April 2011, <https://www.rfc-
              editor.org/info/rfc6147>.
   [RFC6877]  Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
              Combination of Stateful and Stateless Translation", RFC
              6877, DOI 10.17487/RFC6877, April 2013, <https://www.rfc-
              editor.org/info/rfc6877>.
   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200, DOI
              10.17487/RFC8200, July 2017, <https://www.rfc-
              editor.org/info/rfc8200>. Authors' Addresses
   [RFC8305]  Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
              Better Connectivity Using Concurrency", RFC 8305, DOI
              10.17487/RFC8305, December 2017, <https://www.rfc-
              editor.org/info/rfc8305>.

Authors Address

              Cameron Byrne
              T-Mobile USA
              Bellevue, WA
              United States of America
              EMail: Cameron.Byrne@T-Mobile.com






<Byrne>                 Expires January 1, 2019                 [Page 4]