<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' []>
<rfc ipr="trust200902" category="std" docName="draft-vavrusa-dnsop-aaaa-for-free-00">
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc private=""?>
<?rfc topblock="yes"?>
<?rfc comments="no"?>
<front>
<title abbrev="dns-dnsop-a-aaaa">Providing AAAA records for free with QTYPE=A</title>

<author initials="M." surname="Vavrusa" fullname="Marek Vavrusa">
<organization>CloudFlare Inc.</organization>
<address>
<postal>
<street>101 Townsend St.</street>
<city>San Francisco</city>
<code>94107</code>
<country>USA</country>
<region></region>
</postal>
<phone></phone>
<email>mvavrusa@cloudflare.com</email>
<uri></uri>
</address>
</author>
<author initials="O." surname="Gudmundsson" fullname="Olafur Gudmundsson">
<organization>CloudFlare Inc.</organization>
<address>
<postal>
<street>101 Townsend St.</street>
<city>San Francisco</city>
<code>94107</code>
<country>USA</country>
<region></region>
</postal>
<phone></phone>
<email>olafur@cloudflare.com</email>
<uri></uri>
</address>
</author>
<date year="2016" month="March" day="21"/>

<area>Internet</area>
<workgroup></workgroup>
<keyword>DNS</keyword>


<abstract>
<t>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.
</t>
</abstract>


</front>

<middle>

<section anchor="introduction" title="Introduction">
<t>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.
</t>

<section anchor="requirements" title="Requirements">
<t>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;,
&quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;MAY&quot;, and &quot;OPTIONAL&quot; in this
document are to be interpreted as described in <xref target="RFC2119"/>.
</t>
</section>

<section anchor="terminology" title="Terminology">
<t>The reader is assumed to be familiar with the basic DNS concepts described in <xref target="RFC1034"/>, <xref target="RFC1035"/>, <xref target="RFC2181"/> and <xref target="RFC6891"/>. Further DNS terminology is clarified in <xref target="RFC7719"/>.
</t>
</section>
</section>

<section anchor="motivation" title="Motivation">
<t>The DNS specification <xref target="RFC1034"/> <xref target="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.
</t>
<t>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.
</t>
</section>

<section anchor="behaviour-of-authoritative-dns-servers" title="Behaviour of authoritative DNS servers">
<t>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 <xref target="RFC1035"/> , <xref target="RFC4035"/>.  Namely, the authoritative server MUST add DNSSEC signatures for any such records if the zone is signed.
</t>
<t>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.
</t>
</section>

<section anchor="behaviour-of-recursive-dns-servers" title="Behaviour of recursive DNS servers">
<t>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 <xref target="RFC2181"/>, 5.4.1.
</t>
<t>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.
</t>
<t>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.
</t>
</section>

<section anchor="examples" title="Examples">

<section anchor="response-to-qtypea-with-additional-aaaa" title="Response to QTYPE=A with additional AAAA">

<figure anchor="fig-a-aaaa" align="center"><artwork align="center" type="ascii-art">
                     +-----------------------------------------+
       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      |                 &lt;empty&gt;                 |
                     +-----------------------------------------+
     Additional      |                 &lt;empty&gt;                 |
                     +-----------------------------------------+
</artwork></figure>
</section>

<section anchor="response-to-qtypea-with-missing-aaaa" title="Response to QTYPE=A with missing AAAA">

<figure anchor="fig-a-aaaa2" align="center"><artwork align="center" type="ascii-art">
                     +-----------------------------------------+
       Header        |            QR AA RCODE=NOERROR          |
                     +-----------------------------------------+
      Question       |             ns2.example. IN A           |
                     +-----------------------------------------+
       Answer        |       ns2.example. IN A 192.0.2.1       |
                     +-----------------------------------------+
      Authority      |                 &lt;empty&gt;                 |
                     +-----------------------------------------+
     Additional      |                 &lt;empty&gt;                 |
                     +-----------------------------------------+
</artwork></figure>
</section>

<section anchor="response-to-qtypea-with-missing-a-but-added-aaaa" title="Response to QTYPE=A with missing A, but added AAAA">

<figure anchor="fig-a-aaaa3" align="center"><artwork align="center" type="ascii-art">
                     +-----------------------------------------+
       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      |                 &lt;empty&gt;                 |
                     +-----------------------------------------+
</artwork></figure>
</section>
</section>

<section anchor="security-considerations" title="Security Considerations">
<t>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.
</t>
</section>

<section anchor="performance-considerations" title="Performance Considerations">
<t>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.
</t>
</section>

<section anchor="acknowledgements" title="Acknowledgements">
<t>Dani Grant, Vicky Shrestha and Filippo Valsorda provided valuable comments on the draft.
</t>
</section>

</middle>
<back>
<references title="Normative References">
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"?>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"?>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2181.xml"?>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4035.xml"?>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6891.xml"?>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7719.xml"?>
</references>
<references title="Informative References">
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
</references>

</back>
</rfc>
