idnits 2.17.1 draft-vavrusa-dnsop-aaaa-for-free-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 21, 2016) is 2951 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7719 (Obsoleted by RFC 8499) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Vavrusa 3 Internet-Draft O. Gudmundsson 4 Intended status: Standards Track CloudFlare Inc. 5 Expires: September 22, 2016 March 21, 2016 7 Providing AAAA records for free with QTYPE=A 8 draft-vavrusa-dnsop-aaaa-for-free-00 10 Abstract 12 This document enables DNS servers to include AAAA addresses in the 13 answer section for DNS queries with QTYPE=A in order to reduce the 14 number of resolver round-trips during address lookups, and also 15 provides guidance for recursive DNS servers in accepting such 16 records. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 22, 2016. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 2 54 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 3. Behaviour of authoritative DNS servers . . . . . . . . . . . 3 57 4. Behaviour of recursive DNS servers . . . . . . . . . . . . . 3 58 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 5.1. Response to QTYPE=A with additional AAAA . . . . . . . . 3 60 5.2. Response to QTYPE=A with missing AAAA . . . . . . . . . . 4 61 5.3. Response to QTYPE=A with missing A, but added AAAA . . . 4 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 63 7. Performance Considerations . . . . . . . . . . . . . . . . . 5 64 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 67 9.2. Informative References . . . . . . . . . . . . . . . . . 6 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 70 1. Introduction 72 Over the years, there have been a number of attempts to extend DNS to 73 allow multiple questions in a DNS query. While it is possible to 74 place more than one query in the question section there is is only 75 one RCODE for the combined answer and there are no semantics on how 76 to set the RCODE if there are multiple questions that have different 77 results. 79 1.1. Requirements 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC2119]. 85 1.2. Terminology 87 The reader is assumed to be familiar with the basic DNS concepts 88 described in [RFC1034], [RFC1035], [RFC2181] and [RFC6891]. Further 89 DNS terminology is clarified in [RFC7719]. 91 2. Motivation 93 The DNS specification [RFC1034] [RFC1035] doesn't provide any 94 guidance on how to handle records in answer sections with matching 95 QNAME, but mismatching QTYPE with the exception of CNAME and DNAME 96 records. 98 The most frequently looked up types are address records, A for IPv4 99 addresses, and AAAA for IPv6 addresses. Stub resolvers attempt to 100 optimize latency by issuing both queries in parallel, but both 101 recursive and authoritative DNS servers then treat both queries 102 independently, thus in the worst case, loss of one answer triggers 103 requery for both. Furthermore, when client is behind an anycast 104 resolver cluster, the two queries may go to different resolver 105 instances. Resolvers also use queries for both record types 106 internally when determining referral chain topology, and the loss of 107 one answer leads either to an added round-trip if requerying, or 108 suboptimal address selection if the recursor continues without it. 110 3. Behaviour of authoritative DNS servers 112 The authoritative server MAY treat a query with QTYPE=A effectively 113 as a request for any IP address type, regardless of the address 114 protocol with all the requirements due to [RFC1035] , [RFC4035]. 115 Namely, the authoritative server MUST add DNSSEC signatures for any 116 such records if the zone is signed. 118 However, if there is a direct answer to the original question, but no 119 records for other address protocols, the authoritative DNS server 120 SHOULD NOT prove their non-existence. In this respect, they are 121 treated as additional data. 123 4. Behaviour of recursive DNS servers 125 The recursive resolver MAY accept RRs with TYPE=AAAA and owner equal 126 to SNAME, therefore a direct answer to the query or matching the the 127 final target of the CNAME chain. They MUST be treated as 128 authoritative data as in [RFC2181], 5.4.1. 130 Notably, a recursive resolver MUST verify DNSSEC signatures on any 131 such records and it MUST reject any such records if the validation 132 fails, and the zone is not provably secure. In other words, they are 133 subject to the same requirements as a direct answer. 135 A resolver SHOULD accept other IP address records even if there are 136 no records matching the original QTYPE, given that authoritative DNS 137 server proves non-existence of the direct answer. 139 5. Examples 141 5.1. Response to QTYPE=A with additional AAAA 142 +-----------------------------------------+ 143 Header | QR AA RCODE=NOERROR | 144 +-----------------------------------------+ 145 Question | ns1.example. IN A | 146 +-----------------------------------------+ 147 Answer | ns1.example. IN A 192.0.2.1 | 148 | ns1.example. IN AAAA 2001:db8::1 | 149 +-----------------------------------------+ 150 Authority | | 151 +-----------------------------------------+ 152 Additional | | 153 +-----------------------------------------+ 155 Figure 1 157 5.2. Response to QTYPE=A with missing AAAA 159 +-----------------------------------------+ 160 Header | QR AA RCODE=NOERROR | 161 +-----------------------------------------+ 162 Question | ns2.example. IN A | 163 +-----------------------------------------+ 164 Answer | ns2.example. IN A 192.0.2.1 | 165 +-----------------------------------------+ 166 Authority | | 167 +-----------------------------------------+ 168 Additional | | 169 +-----------------------------------------+ 171 Figure 2 173 5.3. Response to QTYPE=A with missing A, but added AAAA 175 +-----------------------------------------+ 176 Header | QR AA RCODE=NOERROR | 177 +-----------------------------------------+ 178 Question | ns3.example. IN A | 179 +-----------------------------------------+ 180 Answer | ns3.example. IN AAAA 2001:db8::2 | 181 +-----------------------------------------+ 182 Authority | example. IN SOA a.example. x.w.example. | 183 | 1081539377 3600 300 3600000 3600 | 184 +-----------------------------------------+ 185 Additional | | 186 +-----------------------------------------+ 188 Figure 3 190 6. Security Considerations 192 In cases where a caching resolver either doesn't validate or the 193 authoritative answer is insecure, a successful spoofing attack may 194 poison both address types in one successful attempt. However, the 195 chance of successful spoofing attack is not affected. 197 7. Performance Considerations 199 Some resolvers might reject the answer due to "extra" records in the 200 answer section, but more likely the resolver will discard the AAAA 201 records, thus we are no different than today. 203 8. Acknowledgements 205 Dani Grant, Vicky Shrestha and Filippo Valsorda provided valuable 206 comments on the draft. 208 9. References 210 9.1. Normative References 212 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 213 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 214 . 216 [RFC1035] Mockapetris, P., "Domain names - implementation and 217 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 218 November 1987, . 220 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 221 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 222 . 224 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 225 Rose, "Protocol Modifications for the DNS Security 226 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 227 . 229 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 230 for DNS (EDNS(0))", STD 75, RFC 6891, 231 DOI 10.17487/RFC6891, April 2013, 232 . 234 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 235 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 236 2015, . 238 9.2. Informative References 240 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 241 Requirement Levels", BCP 14, RFC 2119, 242 DOI 10.17487/RFC2119, March 1997, 243 . 245 Authors' Addresses 247 Marek Vavrusa 248 CloudFlare Inc. 249 101 Townsend St. 250 San Francisco 94107 251 USA 253 Email: mvavrusa@cloudflare.com 255 Olafur Gudmundsson 256 CloudFlare Inc. 257 101 Townsend St. 258 San Francisco 94107 259 USA 261 Email: olafur@cloudflare.com