idnits 2.17.1 draft-wkumari-dnsop-multiple-responses-05.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 3, 2017) is 2490 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) == Unused Reference: 'RFC7873' is defined on line 345, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5395 (Obsoleted by RFC 6195) ** Obsolete normative reference: RFC 6555 (Obsoleted by RFC 8305) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsop W. Kumari 3 Internet-Draft Google 4 Intended status: Standards Track Z. Yan 5 Expires: January 4, 2018 CNNIC 6 W. Hardaker 7 USC/ISI 8 D. Lawrence 9 Akamai Technologies 10 July 3, 2017 12 Returning extra answers in DNS responses. 13 draft-wkumari-dnsop-multiple-responses-05 15 Abstract 17 This document (re)introduces the ability to provide multiple answers 18 in a DNS response. This is especially useful as, in many cases, the 19 entity making the request has no a prori knowledge of what other 20 questions it will need to ask. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 4, 2018. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 58 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Returning multiple answers . . . . . . . . . . . . . . . . . 4 61 5. The EXTRA Resource Record . . . . . . . . . . . . . . . . . . 5 62 5.1. File Format . . . . . . . . . . . . . . . . . . . . . . . 5 63 5.2. Wire Format . . . . . . . . . . . . . . . . . . . . . . . 5 64 6. Signaling support . . . . . . . . . . . . . . . . . . . . . . 6 65 7. Stub-Resolver Considerations . . . . . . . . . . . . . . . . 6 66 8. Use of Additional information . . . . . . . . . . . . . . . . 6 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 70 12. Normative References . . . . . . . . . . . . . . . . . . . . 7 71 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 In many cases a name being resolved in the DNS provides the reason 77 behind why the name is being resolved. This may allow the 78 authoritative nameserver to predict what other answers a recursive 79 resolver will soon query for. By providing multiple answers in the 80 response, the authoritative name server operator can assist a caching 81 recursive resolver in pre-populating its cache before a stub resolver 82 or other client asks for the subsequent queries. Apart from 83 decreasing the latency for end users [RFC6555], this also decreases 84 the total number of queries that the recursive resolver needs to send 85 and the authoritative server needs to answer. 87 For example, the domain name administrator of Example Widgets, Inc 88 (example.com) knows that the web page at www.example.com contains 89 various other resources, including some images (served from 90 images.example.com), some Cascading Style Sheets (served from 91 css.example.com) and some JavaScript (served from data.example.com). 92 An application attempting to resolve www.example.com is very likely 93 to be a web browser rendering the page and will likely also need to 94 resolve all of these additional names as well. Providing all of 95 these answers in response to a query for www.example.com allows the 96 recursive resolver to pre-populate its cache and have these answers 97 available immediately when a stub resolver or other DNS client asks 98 for them. What is important to notice here is that the stub resolver 99 does not know what other questions it will need to make until after 100 it has already made the request for www.exmaple.com, received the 101 reply, made the HTTP connection and parsed the HTML. 103 Other examples where this technique may be useful include SMTP (by 104 including mail server addresses, SPF and DKIM records when serving 105 the MX record), SRV (by providing the target information in addition 106 to the SRV response) and TLSA (by providing any TLSA records 107 associated with a name). This same technique can also be used to 108 include both the IPv4 (A) and IPv6 (AAAA) addresses for any singular 109 address query. 111 This technique, described in this document, is purely an optimization 112 and enables a zone publisher to distribute other related answers that 113 the client is likely to need along with an answer to the original 114 request. Users get a better experience, recursive resolvers need to 115 send less queries, authoritative servers have to answer fewer 116 queries, etc. 118 1.1. Requirements notation 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 2. Background 126 The existing DNS specifications [RFC1034] allow for supplemental 127 information to be included in the "additional" section of the DNS 128 response, but in order to defeat cache poisoning attacks most 129 implementations either ignore or don't trust additional records they 130 didn't ask for. For more background, see [Ref.Bellovin] and 131 [RFC2181]. 133 Not trusting the information in the additional section was necessary 134 since there was no way to authenticate it. If a resolver queries for 135 www.example.com and received answers for www.invalid.com as well, it 136 is impossible for a non-validating resolver to tell if these were 137 actually from invalid.com or if an attacker was trying to push bad 138 information for invalid.com into the resolver's cache. In a world of 139 ubiquitous DNSSEC deployment [Ed note: By the time this document is 140 published, there *will* be ubiquitous DNSSEC :-) ], a validating 141 resolver can validate, authenticate and trust the records in the 142 additional information. 144 3. Terminology 146 Additional records Additional records are records that the 147 authoritative nameserver has included in the Additional section. 149 EXTRA Resource Record The EXTRA resource record (defined below) 150 carries a list of additional records to send. 152 Primary query A Primary query (or primary question) is a QNAME that 153 the name server operator would like to return additional answers 154 for. 156 Supporting DNSSEC information Supporting DNSSEC information is the 157 DNSSEC RRSIGs that prove the authenticity of the Additional 158 records. 160 Stub Resolver The term "Stub Resolver" is used in this document to 161 refer to the most common instance of a DNS client sending DNS 162 requests to a Recursive Resolver. However, other DNS clients are 163 not excluded from these usages and where we write "Stub Resolver" 164 you may read it as "Stub Resolver or other DNS client". 166 4. Returning multiple answers 168 The authoritative nameserver should include as many of the instructed 169 additional records identified by the Extra Resource Record and 170 Supporting DNSSEC information as will fit in the response packet. 171 These additional records (and Supporting DNSSEC information) are 172 appended to the additional section of the response. 174 In order to include additional records in a response, these 175 conditions need to be met: 177 1. Additional records MUST only be included when the Name Server is 178 authoritative for the zone, and the records to be returned are 179 DNSSEC signed. 181 2. The supporting DNSSEC information necessary to perform validation 182 on the records MUST be included. 184 3. The Authoritative Name Server SHOULD include as many of the 185 additional records as will fit in the response. Additional 186 records SHOULD be inserted in the order specified in the 187 Additional records list. 189 4. Zone administrators SHOULD only include records identified in the 190 EXTRA Resource Records that they expect a client to need. 192 5. The EXTRA Resource Record 194 To allow a zone content administrator to instruct the name server 195 which additional records to serve when it receives a query to a 196 label, we introduce the EXTRA Resource Record (RR). These additional 197 records are appended to the additional section (note that the EXTRA 198 RR itself is not appended). The EXTRA resource record MAY still be 199 queried for directly (e.g for debugging), in which case the record 200 itself is returned. 202 5.1. File Format 204 The format of the EXTRA RR is: 206 label EXTRA "label,type; label,type; label,type; ..." 208 For example, if the operator of example.com would like to also return 209 A record answers for images.example.com, css.html.example.com and 210 both an A and AAAA for data.example.com when queried for 211 www.example.com, they would create the following record: 213 www.example.com. EXTRA "images,A; css,A; data,A; data,AAAA;" 215 The entries in the EXTRA list are ordered. An authoritative 216 nameserver SHOULD insert the records in the order listed when filling 217 the response packet. This is to allow the operator to express a 218 preference in case all the records will not fit in the response. The 219 TTL of the records added to the Additional section are MUST be the 220 same as if queried directly. 222 In some cases a zone content administrator might not know what all 223 additional records clients need. For example, the owner of 224 www.example.com may have outsourced his DNS operations to a third 225 party, and / or the DNS operator might not interact with the web 226 development team. DNS server operators may use tools to mine their 227 query logs for records to include. For example, if, in a large 228 majority of cases, a recursive server asks for foo.example.com and 229 then very soon after asks for bar.example.com, it may make sense to 230 optimize this by opportunistically returning bar when queried for 231 foo. This functionality could also be included in the authoritative 232 name server software itself. The exact mechanisms and heuristics 233 used for this are not discussed in this document. 235 5.2. Wire Format 237 The wire format of the EXTRA RR is the same as the wire format for a 238 TXT RR: 240 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 241 / TXT-DATA / 242 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 244 Where TXT-DATA is one or more s. 246 The EXTRA RR has RR type TBD [RFC Editor: insert the IANA assigned 247 value and delete this note] 249 6. Signaling support 251 Recursive Resolvers (or other DNS clients) that support EXTRA records 252 MAY signal this by setting the OPT record's EXTRA bit (bit NN [TBD: 253 assigned by IANA] in the EDNS0 extension header to 1). 255 7. Stub-Resolver Considerations 257 No modifications need to be made to stub-resolvers to get the 258 predominate benefit of this protocol, since the majority of the speed 259 gain will take place between the validating recursive resolver and 260 the authoritative name server. However, stub resolvers may choose to 261 support this technique, and / or may query directly for the EXTRA RR 262 if it wants to pre-query for data that will likely be needed in the 263 process of supporting applications. 265 8. Use of Additional information 267 When deciding to use additional records in the additional section, a 268 resolver must follow certain rules: 270 1. Additional records MUST be validated before being used. 272 2. Additional records SHOULD have lower priority in the cache than 273 answers received because they were requested. This is to help 274 evict Additional records from the cache first (to help prevent 275 cache filling attacks). 277 3. Recursive resolvers MAY choose to ignore Additional records for 278 any reason, including CPU or cache space concerns, phase of the 279 moon, etc. It may choose to accept all, some or none of the 280 Additional records. 282 9. IANA Considerations 284 This document contains the following IANA assignment requirements: 286 1. The EXTRA bit discussed in Section 6 needs to be allocated. [ Ed: 287 This section to be completed later ] 289 10. Security Considerations 291 Additional records will make DNS responses even larger than they are 292 currently, leading to larger records that can be used in DNS 293 reflection attacks. One could mitigate this by only serving 294 responses to EXTRA requests over TCP or when using Cookies [RFC5395], 295 although there is no easy way to signal this to a client other than 296 through the use of the truncate bit. 298 A malicious authoritative server could include a large number of 299 extra records (and associated DNSSEC information) and attempt to DoS 300 the recursive by making it do lots of DNSSEC validation. However, 301 this is not considered a realistic threat; CPU for validation is 302 cheap compared to bandwidth. This can be mitigated by allowing the 303 recursive resolver to ignore Additional records whenever it considers 304 itself under attack or its CPU resources are otherwise over- 305 committed. 307 This specification requires that the all of the Additional records 308 are signed, and all necessary DNSSEC information for validation be 309 included to avoid cache poisoning attacks. 311 11. Acknowledgements 313 The authors to thank Mark Andrews, John Dickinson, Kazunori Fujiwara, 314 Bob Harold, John Heidemann, and Tony Finch. The authors apologize in 315 advance for others who contributed, but who we managed to forget. 317 12. Normative References 319 [Ref.Bellovin] 320 Bellovin, S., "Using the Domain Name System for System 321 Break-Ins", 1995, 322 . 324 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 325 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 326 . 328 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 329 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 330 RFC2119, March 1997, 331 . 333 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 334 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 335 . 337 [RFC5395] Eastlake 3rd, D., "Domain Name System (DNS) IANA 338 Considerations", RFC 5395, DOI 10.17487/RFC5395, November 339 2008, . 341 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 342 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 343 2012, . 345 [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) 346 Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, 347 . 349 Appendix A. Changes / Author Notes. 351 [RFC Editor: Please remove this section before publication ] 353 From -04 to -05: 355 o In the deadline rush, Warren forgot to add Tale. Fixed. 357 o Some more text fixups and clarifications. 359 From -03 to -04: 361 o Some additional text explaining how this differs from solutions 362 which include multiple queries (you don't know what to ask until 363 you have received some answers). 365 From -02 to -03: 367 o Sat down and rewrote and cleaned up large sections of text. 369 o Changed name of RR from Additional to EXTRA (the term "Additional" 370 is overloaded in general) 372 o Clarified that stub resolvers and other clients MAY use this 373 specification. 375 o Attempted to clarify that the individual RRs are added to the 376 response, not the EXTRA record itself. The EXTRA RR can be 377 queried directly. 379 From -00 to -01: 381 o Nothing change in the template. 383 Authors' Addresses 385 Warren Kumari 386 Google 387 1600 Amphitheatre Parkway 388 Mountain View, CA 94043 389 US 391 Email: warren@kumari.net 393 Zhiwei Yan 394 CNNIC 395 No.4 South 4th Street, Zhongguancun 396 Beijing 100190 397 P. R. China 399 Email: yanzhiwei@cnnic.cn 401 Wes Hardaker 402 USC/ISI 403 P.O. Box 382 404 Davis, CA 95617 405 US 407 Email: ietf@hardakers.net 409 David C Lawrence 410 Akamai Technologies 411 150 Broadway 412 Cambridge, MA 02142-1054 413 US 415 Email: tale@akamai.com