[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Network Working Group                                         M. Vavrusa
Internet-Draft                                            O. Gudmundsson
Intended status: Standards Track                         CloudFlare Inc.
Expires: September 22, 2016                               March 21, 2016


              Providing AAAA records for free with QTYPE=A
                  draft-vavrusa-dnsop-aaaa-for-free-00

Abstract

   This document enables DNS servers to include AAAA addresses in the
   answer section for DNS queries with QTYPE=A in order to reduce the
   number of resolver round-trips during address lookups, and also
   provides guidance for recursive DNS servers in accepting such
   records.

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 http://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 September 22, 2016.

Copyright Notice

   Copyright (c) 2016 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
   (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.



Vavrusa & Gudmundsson  Expires September 22, 2016               [Page 1]


Internet-Draft              dns-dnsop-a-aaaa                  March 2016


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements  . . . . . . . . . . . . . . . . . . . . . .   2
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Behaviour of authoritative DNS servers  . . . . . . . . . . .   3
   4.  Behaviour of recursive DNS servers  . . . . . . . . . . . . .   3
   5.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     5.1.  Response to QTYPE=A with additional AAAA  . . . . . . . .   3
     5.2.  Response to QTYPE=A with missing AAAA . . . . . . . . . .   4
     5.3.  Response to QTYPE=A with missing A, but added AAAA  . . .   4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   7.  Performance Considerations  . . . . . . . . . . . . . . . . .   5
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   Over the years, there have been a number of attempts to extend DNS to
   allow multiple questions in a DNS query.  While it is possible to
   place more than one query in the question section there is is only
   one RCODE for the combined answer and there are no semantics on how
   to set the RCODE if there are multiple questions that have different
   results.

1.1.  Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

1.2.  Terminology

   The reader is assumed to be familiar with the basic DNS concepts
   described in [RFC1034], [RFC1035], [RFC2181] and [RFC6891].  Further
   DNS terminology is clarified in [RFC7719].

2.  Motivation

   The DNS specification [RFC1034] [RFC1035] doesn't provide any
   guidance on how to handle records in answer sections with matching
   QNAME, but mismatching QTYPE with the exception of CNAME and DNAME
   records.




Vavrusa & Gudmundsson  Expires September 22, 2016               [Page 2]


Internet-Draft              dns-dnsop-a-aaaa                  March 2016


   The most frequently looked up types are address records, A for IPv4
   addresses, and AAAA for IPv6 addresses.  Stub resolvers attempt to
   optimize latency by issuing both queries in parallel, but both
   recursive and authoritative DNS servers then treat both queries
   independently, thus in the worst case, loss of one answer triggers
   requery for both.  Furthermore, when client is behind an anycast
   resolver cluster, the two queries may go to different resolver
   instances.  Resolvers also use queries for both record types
   internally when determining referral chain topology, and the loss of
   one answer leads either to an added round-trip if requerying, or
   suboptimal address selection if the recursor continues without it.

3.  Behaviour of authoritative DNS servers

   The authoritative server MAY treat a query with QTYPE=A effectively
   as a request for any IP address type, regardless of the address
   protocol with all the requirements due to [RFC1035] , [RFC4035].
   Namely, the authoritative server MUST add DNSSEC signatures for any
   such records if the zone is signed.

   However, if there is a direct answer to the original question, but no
   records for other address protocols, the authoritative DNS server
   SHOULD NOT prove their non-existence.  In this respect, they are
   treated as additional data.

4.  Behaviour of recursive DNS servers

   The recursive resolver MAY accept RRs with TYPE=AAAA and owner equal
   to SNAME, therefore a direct answer to the query or matching the the
   final target of the CNAME chain.  They MUST be treated as
   authoritative data as in [RFC2181], 5.4.1.

   Notably, a recursive resolver MUST verify DNSSEC signatures on any
   such records and it MUST reject any such records if the validation
   fails, and the zone is not provably secure.  In other words, they are
   subject to the same requirements as a direct answer.

   A resolver SHOULD accept other IP address records even if there are
   no records matching the original QTYPE, given that authoritative DNS
   server proves non-existence of the direct answer.

5.  Examples

5.1.  Response to QTYPE=A with additional AAAA







Vavrusa & Gudmundsson  Expires September 22, 2016               [Page 3]


Internet-Draft              dns-dnsop-a-aaaa                  March 2016


                          +-----------------------------------------+
            Header        |            QR AA RCODE=NOERROR          |
                          +-----------------------------------------+
           Question       |             ns1.example. IN A           |
                          +-----------------------------------------+
            Answer        |       ns1.example. IN A 192.0.2.1       |
                          |       ns1.example. IN AAAA 2001:db8::1  |
                          +-----------------------------------------+
           Authority      |                 <empty>                 |
                          +-----------------------------------------+
          Additional      |                 <empty>                 |
                          +-----------------------------------------+

                                 Figure 1

5.2.  Response to QTYPE=A with missing AAAA

                          +-----------------------------------------+
            Header        |            QR AA RCODE=NOERROR          |
                          +-----------------------------------------+
           Question       |             ns2.example. IN A           |
                          +-----------------------------------------+
            Answer        |       ns2.example. IN A 192.0.2.1       |
                          +-----------------------------------------+
           Authority      |                 <empty>                 |
                          +-----------------------------------------+
          Additional      |                 <empty>                 |
                          +-----------------------------------------+

                                 Figure 2

5.3.  Response to QTYPE=A with missing A, but added AAAA

                          +-----------------------------------------+
            Header        |            QR AA RCODE=NOERROR          |
                          +-----------------------------------------+
           Question       |             ns3.example. IN A           |
                          +-----------------------------------------+
            Answer        |    ns3.example. IN AAAA 2001:db8::2     |
                          +-----------------------------------------+
           Authority      | example. IN SOA a.example. x.w.example. |
                          |    1081539377 3600 300 3600000 3600     |
                          +-----------------------------------------+
          Additional      |                 <empty>                 |
                          +-----------------------------------------+

                                 Figure 3




Vavrusa & Gudmundsson  Expires September 22, 2016               [Page 4]


Internet-Draft              dns-dnsop-a-aaaa                  March 2016


6.  Security Considerations

   In cases where a caching resolver either doesn't validate or the
   authoritative answer is insecure, a successful spoofing attack may
   poison both address types in one successful attempt.  However, the
   chance of successful spoofing attack is not affected.

7.  Performance Considerations

   Some resolvers might reject the answer due to "extra" records in the
   answer section, but more likely the resolver will discard the AAAA
   records, thus we are no different than today.

8.  Acknowledgements

   Dani Grant, Vicky Shrestha and Filippo Valsorda provided valuable
   comments on the draft.

9.  References

9.1.  Normative References

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

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

   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
              Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
              <http://www.rfc-editor.org/info/rfc2181>.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
              <http://www.rfc-editor.org/info/rfc4035>.

   [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
              for DNS (EDNS(0))", STD 75, RFC 6891,
              DOI 10.17487/RFC6891, April 2013,
              <http://www.rfc-editor.org/info/rfc6891>.

   [RFC7719]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
              Terminology", RFC 7719, DOI 10.17487/RFC7719, December
              2015, <http://www.rfc-editor.org/info/rfc7719>.




Vavrusa & Gudmundsson  Expires September 22, 2016               [Page 5]


Internet-Draft              dns-dnsop-a-aaaa                  March 2016


9.2.  Informative References

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

Authors' Addresses

   Marek Vavrusa
   CloudFlare Inc.
   101 Townsend St.
   San Francisco  94107
   USA

   Email: mvavrusa@cloudflare.com


   Olafur Gudmundsson
   CloudFlare Inc.
   101 Townsend St.
   San Francisco  94107
   USA

   Email: olafur@cloudflare.com


























Vavrusa & Gudmundsson  Expires September 22, 2016               [Page 6]