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


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

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 ( 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

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.

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

       Header        |            QR AA RCODE=NOERROR          |
      Question       |             ns1.example. IN A           |
       Answer        |       ns1.example. IN A       |
                     |       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       |
      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

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.
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997.
[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.
[RFC6891] Damas, J., Graff, M. and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013.
[RFC7719] Hoffman, P., Sullivan, A. and K. Fujiwara, "DNS Terminology", RFC 7719, DOI 10.17487/RFC7719, December 2015.

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.

Authors' Addresses

Marek Vavrusa CloudFlare Inc. 101 Townsend St. San Francisco, 94107 USA EMail:
Olafur Gudmundsson CloudFlare Inc. 101 Townsend St. San Francisco, 94107 USA EMail: