idnits 2.17.1 draft-ietf-dnsop-refuse-any-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 : ---------------------------------------------------------------------------- -- 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]; ANY does not mean ALL. 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 RFC1035, 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 2216 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 387 -- Obsolete informational reference (is this intentional?): RFC 7719 (Obsoleted by RFC 8499) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 5 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: 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-05 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 . . . . . . . . . 5 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 1035 . . . . . . . . . . . . . . . . . . . . . 7 69 8. Implementation Experience . . . . . . . . . . . . . . . . . . 7 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 72 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 73 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 75 12.2. Informative References . . . . . . . . . . . . . . . . . 8 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-05 . . . . . . . . . . . 9 80 A.1.2. draft-ietf-dnsop-refuse-any-04 . . . . . . . . . . . 9 81 A.1.3. draft-ietf-dnsop-refuse-any-03 . . . . . . . . . . . 9 82 A.1.4. draft-ietf-dnsop-refuse-any-02 . . . . . . . . . . . 9 83 A.1.5. draft-ietf-dnsop-refuse-any-01 . . . . . . . . . . . 10 84 A.1.6. draft-ietf-dnsop-refuse-any-00 . . . . . . . . . . . 10 85 A.1.7. draft-jabley-dnsop-refuse-any-01 . . . . . . . . . . 10 86 A.1.8. draft-jabley-dnsop-refuse-any-00 . . . . . . . . . . 10 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 89 1. Introduction 91 The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". 92 The operator of an authoritative DNS server might choose not to 93 respond to such queries for reasons of local policy, motivated by 94 security, performance or other reasons. 96 The DNS specification [RFC1034] [RFC1035] does not include specific 97 guidance for the behaviour of DNS servers or clients in this 98 situation. This document aims to provide such guidance. 100 1.1. Terminology 102 This document uses terminology specific to the Domain Name System 103 (DNS), descriptions of which can be found in [RFC7719]. 105 In this document, "ANY Query" refers to a DNS meta-query with 106 QTYPE=ANY. An "ANY Response" is a response to such a query. 108 In an exchange of DNS messages between two hosts, this document 109 refers to the host sending a DNS request as the initiator, and the 110 host sending a DNS response as the responder. 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 2. Motivations for Use of ANY Queries 118 ANY queries are legitimately used for debugging and checking the 119 state of a DNS server for a particular name. 121 ANY queries are sometimes used as a attempt to reduce the number of 122 queries needed to get information, e.g. to obtain MX, A and AAAA 123 RRSets for a mail domain in a single query. There is no documented 124 guidance available for this use case, however, and some 125 implementations have been observed not to function as perhaps their 126 developers expected. Implementers that assume that an ANY query will 127 ultimately be received by an authoritative server and will fetch all 128 existing RRSets, should include a fallback mechanism to use when that 129 does not happen. 131 ANY queries are frequently used to exploit the amplification 132 potential of DNS servers/resolvers using spoofed source addresses and 133 UDP transport (see [RFC5358]). Having the ability to return small 134 responses to such queries makes DNS servers less attractive 135 amplifiers. 137 ANY queries are sometimes used to help mine authoritative-only DNS 138 servers for zone data, since they are expected to return all RRSets 139 for a particular query name. If a DNS operator prefers to reduce the 140 potential for information leaks, they might choose not to send large 141 ANY responses. 143 Some authoritative-only DNS server implementations require additional 144 processing in order to send a conventional ANY response, and avoiding 145 that processing expense might be desirable. 147 3. General Approach 149 This proposal provides a mechanism for an authority server to signal 150 that conventional ANY queries are not supported for a particular 151 QNAME, and to do so in such a way that is both compatible with and 152 triggers desirable behaviour by unmodified clients (e.g. DNS 153 resolvers). 155 Alternative proposals for dealing with ANY queries have been 156 discussed. One approach proposed using a new RCODE to signal that an 157 authoritative server did not answer ANY queries in the standard way. 158 This approach was found to have an undesirable effect on both 159 resolvers and authoritative-only servers; resolvers receiving an 160 unknown RCODE would re-send the same query to all available 161 authoritative servers, rather than suppress future such ANY queries 162 for the same QNAME. 164 This proposal avoids that outcome by returning a non-empty RRSet in 165 the ANY response, providing resolvers with something to cache and 166 effectively suppressing repeat queries to the same or different 167 authority servers. 169 4. Behaviour of DNS Responders 171 Below are the three different modes of behaviour by DNS responders 172 when processing queries with QNAMEs that exist, QCLASS=IN and 173 QTYPE=ANY. Operators/Implementers are free to choose whichever 174 mechanism best suits their environment. 176 1. A DNS responder can choose to select one or a larger subset of 177 the available RRSets at the QNAME. 179 2. A DNS responder can return a synthesised HINFO resource record. 180 See Section 6 for discussion of the use of HINFO. 182 3. Resolver can try to give out the most likely records the 183 requester wants. This is not always possible and the result 184 might well be a large response. 186 Except as described below in this section, the DNS responder MUST 187 follow the standard algorithms when constructing a response. 189 4.1. Answer with a Subset of Available RRSets 191 A DNS responder which receives an ANY query MAY decline to provide a 192 conventional response, or MAY instead send a response with a single 193 RRSet (or a larger subset of available RRSets) in the answer section. 195 The RRSets returned in the answer section of the response MAY consist 196 of a single RRSet owned by the name specified in the QNAME. Where 197 multiple RRSets exist, the responder SHOULD choose a small subset of 198 those avialable to reduce the amplification potential of the 199 response. 201 If the zone is signed, appropriate RRSIG records MUST be included in 202 the answer. 204 4.2. Answer with a Synthesised HINFO RRSet 206 If there is no CNAME present at the owner name matching the QNAME, 207 the resource record returned in the response MAY instead be 208 synthesised, in which case a single HINFO resource record SHOULD be 209 returned. The CPU field of the HINFO RDATA SHOULD be set to RFCXXXX 210 [note to RFC Editor, replace with RFC number assigned to this 211 document]. The OS field of the HINFO RDATA SHOULD be set to the null 212 string to minimize the size of the response. 214 The TTL encoded for the synthesised HINFO RR SHOULD be chosen by the 215 operator of the DNS responder to be large enough to suppress frequent 216 subsequent ANY queries from the same initiator with the same QNAME, 217 understanding that a TTL that is too long might make policy changes 218 relating to ANY queries difficult to change in the future. The 219 specific value used is hence a familiar balance when choosing TTL for 220 any RR in any zone, and be specified according to local policy. 222 If the DNS query includes DO=1 and the QNAME corresponds to a zone 223 that is known by the responder to be signed, a valid RRSIG for the 224 RRSets in the answer (or authority if answer is empty) section MUST 225 be returned. In the case of DO=0, the RRSIG SHOULD be omitted. 227 4.3. Answer with Best Guess as to Intention 229 In some cases it is possible to guess what the initiator wants in the 230 answer but not always. Some implementations have implemented the 231 spirit of this document by returning all of CNAME or (MX A and AAAA) 232 RRsets that are present. This is not a guess but a heuristic that 233 seems to work well in practice. The main drawback is the size of the 234 answer. 236 As in the first one if the zone is signed RRSIG MUST be returned if 237 there the DO bit is set on query. 239 4.4. Behaviour with TCP Transport 241 A DNS responder MAY behave differently when processing ANY queries 242 received over different transport, e.g. by providing a conventional, 243 full response over TCP whilst using one of the other mechanisms 244 specified in this document in the case where a query was received 245 using UDP. 247 Implementers SHOULD provide configuration options to allow operators 248 to specify different behaviour over UDP and TCP. 250 5. Behaviour of DNS Initiators 252 A DNS initiator which sends a query with QTYPE=ANY and receives a 253 response containing an HINFO resource record or a single RRset, as 254 described in Section 4, MAY cache the response in the normal way. 255 Such cached resource records SHOULD be retained in the cache 256 following normal caching semantics, as it would with any other 257 response received from a DNS responder. 259 A DNS initiator MAY suppress queries with QTYPE=ANY in the event that 260 the local cache contains a matching HINFO resource record with 261 RDATA.CPU field, as described in Section 4. A DNS initiator MAY 262 instead respond to such queries with the contents of the local cache 263 in the usual way. 265 6. HINFO Considerations 267 It is possible that the synthesised HINFO RRSet in an ANY response, 268 once cached by the initiator, might suppress subsequent queries from 269 the same initiator with QTYPE=HINFO. Thus the use of HINFO in this 270 proposal would hence have effectively mask the HINFO RRSet present in 271 the zone. 273 Authority-server operators who serve zones that rely upon 274 conventional use of the HINFO RRTYPE SHOULD sensibly choose the 275 "single RRset" method described in this document or select another 276 type. 278 The HINFO RRTYPE is believed to be rarely used in the DNS at the time 279 of writing, based on observations made at recursive servers, 280 authority servers and in passive DNS. 282 7. Updates to RFC 1035 284 It is important to note that returning a subset of available RRSets 285 when processing an ANY query is legitimate and consistent with 286 [RFC1035]; ANY does not mean ALL. The main difference here is that 287 the TC bit SHOULD not be set on the response indicating that this is 288 not a complete answer. 290 This document describes optional behaviour for both DNS initiators 291 and responders, and implementation of the guidance provided by this 292 document is OPTIONAL. 294 RRSIG queries (i.e. queries with QTYPE=RRSIG) are similar to ANY 295 queries in the sense that they have the potential to generate large 296 responses as well as extra work for the responders that process them, 297 e.g. in the case where signatures are generated on-the-fly. RRSIG 298 RRSets are not usually obtained using such explicit queries, but are 299 rather included in the responses for other RRSets that the RRSIGs 300 cover. This document does not specify appropriate behaviour for 301 RRSIG queries, but note that future such advice might well benefit 302 from consistency with and experience of the approaches for ANY 303 queries described here. 305 8. Implementation Experience 307 In October 2015 Cloudflare Authoritative Name server implementation 308 implemented the HINFO response. A few minor problems were reported 309 and have since been resolved. 311 An implementation of the subset-mode response to ANY queries was 312 implemented in NSD 4.1 in 2016. 314 An implementation of a single RRSet response to an ANY query was made 315 for BIND9 by Tony Finch, and that functionality was subsequently made 316 available in production releases starting in BIND 9.11. 318 9. Security Considerations 320 Queries with QTYPE=ANY are frequently observed as part of reflection 321 attacks, since a relatively small query can be used to elicit a large 322 response; this is a desirable characteristic if the goal is to 323 maximize the amplification potential of a DNS server as part of a 324 volumetric attack. The ability of a DNS operator to suppress such 325 responses on a particular server makes that server a less useful 326 amplifier. 328 The optional behaviour described in this document to reduce the size 329 of responses to queries with QTYPE=ANY is compatible with the use of 330 DNSSEC by both initiator and responder. 332 10. IANA Considerations 334 The IANA is requested to update the Resource Record (RR) TYPEs 335 Registry [1] entry as follows: 337 +------+-------+-------------------------------+--------------------+ 338 | Type | Value | Meaning | Reference | 339 +------+-------+-------------------------------+--------------------+ 340 | * | 255 | A request for some or all | [RFC1035][RFC6895] | 341 | | | records the server has | [This Document] | 342 | | | available | | 343 +------+-------+-------------------------------+--------------------+ 345 11. Acknowledgements 347 Evan Hunt and David Lawrence provided valuable observations and 348 concrete suggestions. Jeremy Laidman helped make the document 349 better. Tony Finch realized that this document was valuable and 350 implemented it while under attack. A large number of people have 351 provided comments and suggestions we thank them all for the feedback. 353 12. References 355 12.1. Normative References 357 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 358 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 359 . 361 [RFC1035] Mockapetris, P., "Domain names - implementation and 362 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 363 November 1987, . 365 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 366 Requirement Levels", BCP 14, RFC 2119, 367 DOI 10.17487/RFC2119, March 1997, 368 . 370 12.2. Informative References 372 [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive 373 Nameservers in Reflector Attacks", BCP 140, RFC 5358, 374 DOI 10.17487/RFC5358, October 2008, 375 . 377 [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA 378 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, 379 April 2013, . 381 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 382 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 383 2015, . 385 12.3. URIs 387 [1] http://www.iana.org/assignments/dns-parameters/dns- 388 parameters.xhtml#dns-parameters-4 390 Appendix A. Editorial Notes 392 This section (and sub-sections) to be removed prior to publication. 394 A.1. Change History 396 A.1.1. draft-ietf-dnsop-refuse-any-05 398 Minor editorial changes. Soften advice on RRSIG queries. Version 399 bump. 401 A.1.2. draft-ietf-dnsop-refuse-any-04 403 These are the changes requested during WGLC. The title has been 404 updated for readability The behavior section now contains description 405 of three different approaches in order of preference. Text added on 406 behavior over TCP. The document is clear in how it updates from 407 RFC1035. Minor adjustments for readability and remove redundancy. 409 A.1.3. draft-ietf-dnsop-refuse-any-03 411 Change section name to "Updates to RFC1034", few minor grammar 412 changes suggested by Matthew Pounsett and Tony Finch. 414 Text clarifications, reflecting experience, added implementation 415 experience. 417 A.1.4. draft-ietf-dnsop-refuse-any-02 419 Added suggestion to call out RRSIG is optional when DO=0. 421 Number of text suggestions from Jeremy Laidman. 423 A.1.5. draft-ietf-dnsop-refuse-any-01 425 Add IANA Considerations 427 A.1.6. draft-ietf-dnsop-refuse-any-00 429 Re-submitted with a different name following adoption at the dnsop WG 430 meeting convened at IETF 94. 432 A.1.7. draft-jabley-dnsop-refuse-any-01 434 Make signing of RRSets in answers from signed zones mandatory. 436 Document the option of returning an existing RRSet in place of a 437 synthesised one. 439 A.1.8. draft-jabley-dnsop-refuse-any-00 441 Initial draft circulated for comment. 443 Authors' Addresses 445 Joe Abley 446 Afilias 447 300-184 York Street 448 London, ON N6A 1B5 449 Canada 451 Phone: +1 519 670 9327 452 Email: jabley@afilias.info 454 Olafur Gudmundsson 455 Cloudflare Inc. 457 Email: olafur+ietf@cloudflare.com 459 Marek Majkowski 460 Cloudflare Inc. 462 Email: marek@cloudflare.com