idnits 2.17.1 draft-ietf-dnsop-refuse-any-06.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 draft header indicates that this document updates RFC1034, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC1035, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: It is important to note that returning a subset of available RRSets when processing an ANY query is legitimate and consistent with [RFC1035]; it can be argued that ANY does not always mean ALL, as used in section 3.2.3 of [RFC1035]. The main difference here is that the TC bit SHOULD not be set on the response indicating that this is not a complete answer. (Using the creation date from RFC1034, updated by this document, for RFC5378 checks: 1987-11-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 5, 2018) is 2244 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) -- Looks like a reference, but probably isn't: '1' on line 404 -- Obsolete informational reference (is this intentional?): RFC 7719 (Obsoleted by RFC 8499) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Abley 3 Internet-Draft Afilias 4 Updates: 1034, 1035 (if approved) O. Gudmundsson 5 Intended status: Standards Track M. Majkowski 6 Expires: September 6, 2018 Cloudflare Inc. 7 March 5, 2018 9 Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY 10 draft-ietf-dnsop-refuse-any-06 12 Abstract 14 The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". 15 The operator of an authoritative DNS server might choose not to 16 respond to such queries for reasons of local policy, motivated by 17 security, performance or other reasons. 19 The DNS specification does not include specific guidance for the 20 behaviour of DNS servers or clients in this situation. This document 21 aims to provide such guidance. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 6, 2018. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Motivations for Use of ANY Queries . . . . . . . . . . . . . 3 60 3. General Approach . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Behaviour of DNS Responders . . . . . . . . . . . . . . . . . 4 62 4.1. Answer with a Subset of Available RRSets . . . . . . . . 5 63 4.2. Answer with a Synthesised HINFO RRSet . . . . . . . . . . 5 64 4.3. Answer with Best Guess as to Intention . . . . . . . . . 6 65 4.4. Behaviour with TCP Transport . . . . . . . . . . . . . . 6 66 5. Behaviour of DNS Initiators . . . . . . . . . . . . . . . . . 6 67 6. HINFO Considerations . . . . . . . . . . . . . . . . . . . . 6 68 7. Updates to RFC 1034 and RFC 1035 . . . . . . . . . . . . . . 7 69 8. Implementation Experience . . . . . . . . . . . . . . . . . . 7 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 72 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 73 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 75 12.2. Informative References . . . . . . . . . . . . . . . . . 9 76 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 Appendix A. Editorial Notes . . . . . . . . . . . . . . . . . . 9 78 A.1. Change History . . . . . . . . . . . . . . . . . . . . . 9 79 A.1.1. draft-ietf-dnsop-refuse-any-06 . . . . . . . . . . . 9 80 A.1.2. draft-ietf-dnsop-refuse-any-05 . . . . . . . . . . . 9 81 A.1.3. draft-ietf-dnsop-refuse-any-04 . . . . . . . . . . . 9 82 A.1.4. draft-ietf-dnsop-refuse-any-03 . . . . . . . . . . . 10 83 A.1.5. draft-ietf-dnsop-refuse-any-02 . . . . . . . . . . . 10 84 A.1.6. draft-ietf-dnsop-refuse-any-01 . . . . . . . . . . . 10 85 A.1.7. draft-ietf-dnsop-refuse-any-00 . . . . . . . . . . . 10 86 A.1.8. draft-jabley-dnsop-refuse-any-01 . . . . . . . . . . 10 87 A.1.9. draft-jabley-dnsop-refuse-any-00 . . . . . . . . . . 10 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 90 1. Introduction 92 The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". 93 The operator of an authoritative DNS server might choose not to 94 respond to such queries for reasons of local policy, motivated by 95 security, performance or other reasons. 97 The DNS specification [RFC1034] [RFC1035] does not include specific 98 guidance for the behaviour of DNS servers or clients in this 99 situation. This document aims to provide such guidance. 101 1.1. Terminology 103 This document uses terminology specific to the Domain Name System 104 (DNS), descriptions of which can be found in [RFC7719]. 106 In this document, "ANY Query" refers to a DNS meta-query with 107 QTYPE=ANY. An "ANY Response" is a response to such a query. 109 In this document, "conventional ANY response" means an ANY response 110 that is constructed in accordance with the algorithm documented in 111 section 4.3.2 of [RFC1034] and specifically without implementing any 112 of the mechanisms described in this document. 114 In an exchange of DNS messages between two hosts, this document 115 refers to the host sending a DNS request as the initiator, and the 116 host sending a DNS response as the responder. 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 2. Motivations for Use of ANY Queries 124 ANY queries are legitimately used for debugging and checking the 125 state of a DNS server for a particular name. 127 ANY queries are sometimes used as a attempt to reduce the number of 128 queries needed to get information, e.g. to obtain MX, A and AAAA 129 RRSets for a mail domain in a single query. There is no documented 130 guidance available for this use case, however, and some 131 implementations have been observed not to function as perhaps their 132 developers expected. Implementers that assume that an ANY query will 133 ultimately be received by an authoritative server and will fetch all 134 existing RRSets, should include a fallback mechanism to use when that 135 does not happen. 137 ANY queries are frequently used to exploit the amplification 138 potential of DNS servers/resolvers using spoofed source addresses and 139 UDP transport (see [RFC5358]). Having the ability to return small 140 responses to such queries makes DNS servers less attractive 141 amplifiers. 143 ANY queries are sometimes used to help mine authoritative-only DNS 144 servers for zone data, since they are expected to return all RRSets 145 for a particular query name. If a DNS operator prefers to reduce the 146 potential for information leaks, they might choose not to send large 147 ANY responses. 149 Some authoritative-only DNS server implementations require additional 150 processing in order to send a conventional ANY response, and avoiding 151 that processing expense might be desirable. 153 3. General Approach 155 This proposal provides a mechanism for an authority server to signal 156 that conventional ANY queries are not supported for a particular 157 QNAME, and to do so in such a way that is both compatible with and 158 triggers desirable behaviour by unmodified clients (e.g. DNS 159 resolvers). 161 Alternative proposals for dealing with ANY queries have been 162 discussed. One approach proposed using a new RCODE to signal that an 163 authoritative server did not answer ANY queries in the standard way. 164 This approach was found to have an undesirable effect on both 165 resolvers and authoritative-only servers; resolvers receiving an 166 unknown RCODE would re-send the same query to all available 167 authoritative servers, rather than suppress future such ANY queries 168 for the same QNAME. 170 This proposal avoids that outcome by returning a non-empty RRSet in 171 the ANY response, providing resolvers with something to cache and 172 effectively suppressing repeat queries to the same or different 173 authority servers. 175 4. Behaviour of DNS Responders 177 Below are the three different modes of behaviour by DNS responders 178 when processing queries with QNAMEs that exist, QCLASS=IN and 179 QTYPE=ANY. Operators/Implementers are free to choose whichever 180 mechanism best suits their environment. 182 1. A DNS responder can choose to select one or a larger subset of 183 the available RRSets at the QNAME. 185 2. A DNS responder can return a synthesised HINFO resource record. 186 See Section 6 for discussion of the use of HINFO. 188 3. Resolver can try to give out the most likely records the 189 requester wants. This is not always possible and the result 190 might well be a large response. 192 Except as described below in this section, the DNS responder MUST 193 follow the standard algorithms when constructing a response. 195 4.1. Answer with a Subset of Available RRSets 197 A DNS responder which receives an ANY query MAY decline to provide a 198 conventional ANY response, or MAY instead send a response with a 199 single RRSet (or a larger subset of available RRSets) in the answer 200 section. 202 The RRSets returned in the answer section of the response MAY consist 203 of a single RRSet owned by the name specified in the QNAME. Where 204 multiple RRSets exist, the responder SHOULD choose a small subset of 205 those avialable to reduce the amplification potential of the 206 response. 208 If the zone is signed, appropriate RRSIG records MUST be included in 209 the answer. 211 Note that this mechanism does not provide any signalling to indicate 212 to a client that an incomplete subset of the available RRSets has 213 been returned. 215 4.2. Answer with a Synthesised HINFO RRSet 217 If there is no CNAME present at the owner name matching the QNAME, 218 the resource record returned in the response MAY instead be 219 synthesised, in which case a single HINFO resource record SHOULD be 220 returned. The CPU field of the HINFO RDATA SHOULD be set to RFCXXXX 221 [note to RFC Editor, replace with RFC number assigned to this 222 document]. The OS field of the HINFO RDATA SHOULD be set to the null 223 string to minimize the size of the response. 225 The TTL encoded for the synthesised HINFO RR SHOULD be chosen by the 226 operator of the DNS responder to be large enough to suppress frequent 227 subsequent ANY queries from the same initiator with the same QNAME, 228 understanding that a TTL that is too long might make policy changes 229 relating to ANY queries difficult to change in the future. The 230 specific value used is hence a familiar balance when choosing TTL for 231 any RR in any zone, and be specified according to local policy. 233 If the DNS query includes DO=1 and the QNAME corresponds to a zone 234 that is known by the responder to be signed, a valid RRSIG for the 235 RRSets in the answer (or authority if answer is empty) section MUST 236 be returned. In the case of DO=0, the RRSIG SHOULD be omitted. 238 4.3. Answer with Best Guess as to Intention 240 In some cases it is possible to guess what the initiator wants in the 241 answer but not always. Some implementations have implemented the 242 spirit of this document by returning all of CNAME or (MX A and AAAA) 243 RRsets that are present. This is not a guess but a heuristic that 244 seems to work well in practice. The main drawback is the size of the 245 answer. 247 As in the first one if the zone is signed RRSIG MUST be returned if 248 there the DO bit is set on query. 250 4.4. Behaviour with TCP Transport 252 A DNS responder MAY behave differently when processing ANY queries 253 received over different transport, e.g. by providing a conventional 254 ANY response over TCP whilst using one of the other mechanisms 255 specified in this document in the case where a query was received 256 using UDP. 258 Implementers SHOULD provide configuration options to allow operators 259 to specify different behaviour over UDP and TCP. 261 5. Behaviour of DNS Initiators 263 A DNS initiator which sends a query with QTYPE=ANY and receives a 264 response containing an HINFO resource record or a single RRset, as 265 described in Section 4, MAY cache the response in the normal way. 266 Such cached resource records SHOULD be retained in the cache 267 following normal caching semantics, as it would with any other 268 response received from a DNS responder. 270 A DNS initiator MAY suppress queries with QTYPE=ANY in the event that 271 the local cache contains a matching HINFO resource record with 272 RDATA.CPU field, as described in Section 4. A DNS initiator MAY 273 instead respond to such queries with the contents of the local cache 274 in the usual way. 276 6. HINFO Considerations 278 It is possible that the synthesised HINFO RRSet in an ANY response, 279 once cached by the initiator, might suppress subsequent queries from 280 the same initiator with QTYPE=HINFO. Thus the use of HINFO in this 281 proposal would hence have effectively mask the HINFO RRSet present in 282 the zone. 284 Authority-server operators who serve zones that rely upon 285 conventional use of the HINFO RRTYPE SHOULD sensibly choose the 286 "single RRset" method described in this document or select another 287 type. 289 The HINFO RRTYPE is believed to be rarely used in the DNS at the time 290 of writing, based on observations made at recursive servers, 291 authority servers and in passive DNS. 293 7. Updates to RFC 1034 and RFC 1035 295 This document extends the specification for processing ANY queries 296 described in section 4.3.2 of [RFC1034]. 298 It is important to note that returning a subset of available RRSets 299 when processing an ANY query is legitimate and consistent with 300 [RFC1035]; it can be argued that ANY does not always mean ALL, as 301 used in section 3.2.3 of [RFC1035]. The main difference here is that 302 the TC bit SHOULD not be set on the response indicating that this is 303 not a complete answer. 305 This document describes optional behaviour for both DNS initiators 306 and responders, and implementation of the guidance provided by this 307 document is OPTIONAL. 309 RRSIG queries (i.e. queries with QTYPE=RRSIG) are similar to ANY 310 queries in the sense that they have the potential to generate large 311 responses as well as extra work for the responders that process them, 312 e.g. in the case where signatures are generated on-the-fly. RRSIG 313 RRSets are not usually obtained using such explicit queries, but are 314 rather included in the responses for other RRSets that the RRSIGs 315 cover. This document does not specify appropriate behaviour for 316 RRSIG queries, but note that future such advice might well benefit 317 from consistency with and experience of the approaches for ANY 318 queries described here. 320 8. Implementation Experience 322 In October 2015 Cloudflare Authoritative Name server implementation 323 implemented the HINFO response. A few minor problems were reported 324 and have since been resolved. 326 An implementation of the subset-mode response to ANY queries was 327 implemented in NSD 4.1 in 2016. 329 An implementation of a single RRSet response to an ANY query was made 330 for BIND9 by Tony Finch, and that functionality was subsequently made 331 available in production releases starting in BIND 9.11. 333 9. Security Considerations 335 Queries with QTYPE=ANY are frequently observed as part of reflection 336 attacks, since a relatively small query can be used to elicit a large 337 response; this is a desirable characteristic if the goal is to 338 maximize the amplification potential of a DNS server as part of a 339 volumetric attack. The ability of a DNS operator to suppress such 340 responses on a particular server makes that server a less useful 341 amplifier. 343 The optional behaviour described in this document to reduce the size 344 of responses to queries with QTYPE=ANY is compatible with the use of 345 DNSSEC by both initiator and responder. 347 10. IANA Considerations 349 The IANA is requested to update the Resource Record (RR) TYPEs 350 Registry [1] entry as follows: 352 +------+-------+-------------------------------+--------------------+ 353 | Type | Value | Meaning | Reference | 354 +------+-------+-------------------------------+--------------------+ 355 | * | 255 | A request for some or all | [RFC1035][RFC6895] | 356 | | | records the server has | [This Document] | 357 | | | available | | 358 +------+-------+-------------------------------+--------------------+ 360 11. Acknowledgements 362 Evan Hunt and David Lawrence provided valuable observations and 363 concrete suggestions. Jeremy Laidman helped make the document 364 better. Tony Finch realized that this document was valuable and 365 implemented it while under attack. Richard Gibson identified areas 366 where more detail and accuracy was useful. A large number of other 367 people also provided comments and suggestions we thank them all for 368 the feedback. 370 12. References 372 12.1. Normative References 374 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 375 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 376 . 378 [RFC1035] Mockapetris, P., "Domain names - implementation and 379 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 380 November 1987, . 382 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 383 Requirement Levels", BCP 14, RFC 2119, 384 DOI 10.17487/RFC2119, March 1997, 385 . 387 12.2. Informative References 389 [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive 390 Nameservers in Reflector Attacks", BCP 140, RFC 5358, 391 DOI 10.17487/RFC5358, October 2008, 392 . 394 [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA 395 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, 396 April 2013, . 398 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 399 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 400 2015, . 402 12.3. URIs 404 [1] http://www.iana.org/assignments/dns-parameters/dns- 405 parameters.xhtml#dns-parameters-4 407 Appendix A. Editorial Notes 409 This section (and sub-sections) to be removed prior to publication. 411 A.1. Change History 413 A.1.1. draft-ietf-dnsop-refuse-any-06 415 Update RFC 1034 as well as RFC 1035; define the term "conventional 416 ANY response"; soften and qualify ANY does not mean ALL; note that 417 the subset mode response lacks signalling. 419 A.1.2. draft-ietf-dnsop-refuse-any-05 421 Minor editorial changes. Soften advice on RRSIG queries. Version 422 bump. 424 A.1.3. draft-ietf-dnsop-refuse-any-04 426 These are the changes requested during WGLC. The title has been 427 updated for readability The behavior section now contains description 428 of three different approaches in order of preference. Text added on 429 behavior over TCP. The document is clear in how it updates from 430 RFC1035. Minor adjustments for readability and remove redundancy. 432 A.1.4. draft-ietf-dnsop-refuse-any-03 434 Change section name to "Updates to RFC1034", few minor grammar 435 changes suggested by Matthew Pounsett and Tony Finch. 437 Text clarifications, reflecting experience, added implementation 438 experience. 440 A.1.5. draft-ietf-dnsop-refuse-any-02 442 Added suggestion to call out RRSIG is optional when DO=0. 444 Number of text suggestions from Jeremy Laidman. 446 A.1.6. draft-ietf-dnsop-refuse-any-01 448 Add IANA Considerations 450 A.1.7. draft-ietf-dnsop-refuse-any-00 452 Re-submitted with a different name following adoption at the dnsop WG 453 meeting convened at IETF 94. 455 A.1.8. draft-jabley-dnsop-refuse-any-01 457 Make signing of RRSets in answers from signed zones mandatory. 459 Document the option of returning an existing RRSet in place of a 460 synthesised one. 462 A.1.9. draft-jabley-dnsop-refuse-any-00 464 Initial draft circulated for comment. 466 Authors' Addresses 468 Joe Abley 469 Afilias 470 300-184 York Street 471 London, ON N6A 1B5 472 Canada 474 Phone: +1 519 670 9327 475 Email: jabley@afilias.info 476 Olafur Gudmundsson 477 Cloudflare Inc. 479 Email: olafur+ietf@cloudflare.com 481 Marek Majkowski 482 Cloudflare Inc. 484 Email: marek@cloudflare.com