idnits 2.17.1 draft-ietf-dnsop-refuse-any-04.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 (February 08, 2017) is 2634 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 368 -- 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 Dyn, Inc. 4 Updates: 1035 (if approved) O. Gudmundsson 5 Intended status: Standards Track M. Majkowski 6 Expires: August 12, 2017 Cloudflare Inc. 7 February 08, 2017 9 Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY 10 draft-ietf-dnsop-refuse-any-04 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 http://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 August 12, 2017. 40 Copyright Notice 42 Copyright (c) 2017 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. General Approach . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Behaviour of DNS Responders . . . . . . . . . . . . . . . . . 4 62 4.1. Select one RRSet mode . . . . . . . . . . . . . . . . . . 4 63 4.2. Synthesised HINFO RRset . . . . . . . . . . . . . . . . . 5 64 4.3. Guess intention . . . . . . . . . . . . . . . . . . . . . 5 65 4.4. Responding to queries over TCP . . . . . . . . . . . . . 5 66 5. Behaviour of DNS Initiators . . . . . . . . . . . . . . . . . 6 67 6. HINFO Considerations . . . . . . . . . . . . . . . . . . . . 6 68 7. Updates to RFC 1035 . . . . . . . . . . . . . . . . . . . . . 6 69 8. Implementation Experience . . . . . . . . . . . . . . . . . . 7 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 73 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 75 12.2. Informative References . . . . . . . . . . . . . . . . . 8 76 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 Appendix A. Editorial Notes . . . . . . . . . . . . . . . . . . 8 78 A.1. Change History . . . . . . . . . . . . . . . . . . . . . 8 79 A.1.1. draft-ietf-dnsop-refuse-any-04 . . . . . . . . . . . 8 80 A.1.2. draft-ietf-dnsop-refuse-any-03 . . . . . . . . . . . 9 81 A.1.3. draft-ietf-dnsop-refuse-any-02 . . . . . . . . . . . 9 82 A.1.4. draft-ietf-dnsop-refuse-any-01 . . . . . . . . . . . 9 83 A.1.5. draft-ietf-dnsop-refuse-any-00 . . . . . . . . . . . 9 84 A.1.6. draft-jabley-dnsop-refuse-any-01 . . . . . . . . . . 9 85 A.1.7. draft-jabley-dnsop-refuse-any-00 . . . . . . . . . . 9 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 88 1. Introduction 90 The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". 91 The operator of an authoritative DNS server might choose not to 92 respond to such queries for reasons of local policy, motivated by 93 security, performance or other reasons. 95 The DNS specification [RFC1034] [RFC1035] does not include specific 96 guidance for the behaviour of DNS servers or clients in this 97 situation. This document aims to provide such guidance. 99 1.1. Terminology 101 This document uses terminology specific to the Domain Name System 102 (DNS), descriptions of which can be found in [RFC7719]. 104 In this document, "ANY Query" refers to a DNS meta-query with 105 QTYPE=ANY. An "ANY Response" is a response to such a query. 107 In an exchange of DNS messages between two hosts, this document 108 refers to the host sending a DNS request as the initiator, and the 109 host sending a DNS response as the responder. 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 2. Motivations 117 ANY queries are legitimately used for debugging and checking the 118 state of a DNS server for a particular name. ANY queries are 119 sometimes used as a attempt to reduce the number of queries needed to 120 get information, e.g. to obtain MX, A and AAAA RRSets for a mail 121 domain in a single query. Although there is no documented guidance 122 available for this use case and some implementations have been 123 observed that appear not to function as perhaps their developers 124 expected. For any developer that assumes that ANY query will be sent 125 to authoritative server to fetch all RRSets, they need to include a 126 fallback when that does not happen. 128 ANY queries are also frequently used to exploit the amplification 129 potential of DNS servers/resolvers using spoofed source addresses and 130 UDP transport (see [RFC5358]). Having the ability to return small 131 responses to such queries makes DNS servers less attractive 132 amplifiers. 134 ANY queries are sometimes used to help mine authoritative-only DNS 135 servers for zone data, since they are expected to return all RRSets 136 for a particular query name. If a DNS operator prefers to reduce the 137 potential for information leaks, they MAY choose to not to send large 138 ANY responses. 140 Some authoritative-only DNS server implementations require additional 141 processing in order to send a conventional ANY response, and avoiding 142 that processing expense might be desirable. 144 3. General Approach 146 This proposal provides a mechanism for an authority server to signal 147 that conventional ANY queries are not supported for a particular 148 QNAME, and to do so in such a way that is both compatible with and 149 triggers desirable behaviour by unmodified clients (e.g. DNS 150 resolvers). 152 Alternative proposals for dealing with ANY queries have been 153 discussed. One approach proposed using a new RCODE to signal that an 154 authoritative server did not answer ANY queries in the standard way. 155 This approach was found to have an undesirable effect on both 156 resolvers and authoritative-only servers; resolvers receiving an 157 unknown RCODE caused them to re-send the same query to all available 158 authoritative servers, rather than suppress future such ANY queries 159 for the same QNAME. 161 This proposal avoids that outcome by returning a non-empty RRSet in 162 the ANY response, providing resolvers with something to cache and 163 effectively suppressing repeat queries to the same or different 164 authority servers. 166 4. Behaviour of DNS Responders 168 Below are the three different modes of behaviour by DNS responders 169 for names that exists that are used, listed in the order of 170 preference. Operators/Implementers are free to choose whichever 171 mechanism best suits their environment. 173 1. A DNS responder can choose to select one or subset of RRSets at 174 the QNAME. 176 2. A DNS responder can return a synthesised HINFO resource record. 177 See Section 6 for discussion of the use of HINFO. 179 3. Resolver can try to give out the most likely records the 180 requester wants. This is not always possible and the likely 181 RRsets may add up to a large answer. 183 Except as described below in this section, the DNS responder MUST 184 follow the standard algorithms when constructing a response. 186 4.1. Select one RRSet mode 188 A DNS responder which receives an ANY query MAY decline to provide a 189 conventional response, or MAY instead send a response with a single 190 RRSet in the answer section. 192 The RRSet returned in the answer section of the response MAY be a 193 single RRSet owned by the name specified in the QNAME. Where 194 multiple RRSets exist, the responder SHOULD choose a small one(s) to 195 reduce its amplification potential. 197 If the zone is signed RRSIG records MUST be included in the answer 199 4.2. Synthesised HINFO RRset 201 If there is no CNAME present at the owner name matching the QNAME, 202 the resource record returned in the response MAY instead be 203 synthesised, in which case a single HINFO resource record SHOULD be 204 returned. The CPU field of the HINFO RDATA SHOULD be set to RFCXXXX 205 [note to RFC Editor, replace with RFC number assigned to this 206 document]. The OS field of the HINFO RDATA SHOULD be set to the null 207 string to minimize the size of the response. 209 The TTL encoded for a synthesised RR SHOULD be chosen by the operator 210 of the DNS responder to be large enough to suppress frequent 211 subsequent ANY queries from the same initiator with the same QNAME, 212 understanding that a TTL that is too long might make policy changes 213 relating to ANY queries difficult to change in the future. The 214 specific value used is hence a familiar balance when choosing TTL for 215 any RR in any zone, and be specified according to local policy. 217 If the DNS query includes DO=1 and the QNAME corresponds to a zone 218 that is known by the responder to be signed, a valid RRSIG for the 219 RRSets in the answer (or authority if answer is empty) section MUST 220 be returned. In the case of DO=0, the RRSIG SHOULD be omitted. 222 4.3. Guess intention 224 In some cases it is possible to guess what the initiator wants in the 225 answer but not always. Some implementations have implemented the 226 spirit of this document by returning all of CNAME or (MX A and AAAA) 227 RRsets that are present. This is not a guess but a heuristic that 228 seems to work well in practice. The main drawback is the size of the 229 answer. 231 As in the first one if the zone is signed RRSIG MUST be returned if 232 there the DO bit is set on query. 234 4.4. Responding to queries over TCP 236 There has been a desire to specify that a ANY query over TCP get full 237 response. This document does not specify that as that is best left 238 to the operator to decide. Implementers SHOULD provide an option for 239 operators to specify behavior over TCP. 241 5. Behaviour of DNS Initiators 243 A DNS initiator which sends a query with QTYPE=ANY and receives a 244 response containing an HINFO resource record or a single RRset, as 245 described in Section 4, MAY cache the response in the normal way. 246 Such cached resource records SHOULD be retained in the cache 247 following normal caching semantics, as it would with any other 248 response received from a DNS responder. 250 A DNS initiator MAY suppress queries with QTYPE=ANY in the event that 251 the local cache contains a matching HINFO resource record with 252 RDATA.CPU field, as described in Section 4. Similarly it is fine to 253 replay back exactly what Authoritative server returned to ANY query. 255 6. HINFO Considerations 257 It is possible that the synthesised HINFO RRSet in an ANY response, 258 once cached by the initiator, might suppress subsequent queries from 259 the same initiator with QTYPE=HINFO. Thus the use of HINFO in this 260 proposal would hence have effectively mask the HINFO RRSet present in 261 the zone. 263 Authority-server operators who serve zones that rely upon 264 conventional use of the HINFO RRTYPE SHOULD sensibly choose the 265 "single RRset" method described in this document or select another 266 type. 268 The HINFO RRTYPE is believed to be rarely used in the DNS at the time 269 of writing, based on observations made at recursive servers, 270 authority servers and in passive DNS. 272 7. Updates to RFC 1035 274 It is important to note that returning a subset of available RRSets 275 when processing an ANY query is legitimate and consistent with 276 [RFC1035]; ANY does not mean ALL. The main difference here is that 277 the TC bit SHOULD not be set on the response indicating that this is 278 not a complete answer. 280 This document describes optional behaviour for both DNS initiators 281 and responders, and implementation of the guidance provided by this 282 document is OPTIONAL. 284 RRSIG queries have the same potential as ANY queries of generating 285 large answers as well as extra work. DNS implementations are free to 286 not return all RRSIG records. In the wild there are implementations 287 that return REFUSE, others return single RRSIG, etc. This document 288 recommends returning a single RRSIG in this case. 290 8. Implementation Experience 292 In October 2015 Cloudflare Authoritative Name server implementation 293 implemented the HINFO response. Few minor problems have been 294 reported and worked out. NSD has for a while implemented a sub-set 295 response. A Bind user implemented this draft suggestion of returning 296 only single RRset during an attack, his code is now in the current 297 release. 299 9. Security Considerations 301 Queries with QTYPE=ANY are frequently observed as part of reflection 302 attacks, since a relatively small query can be used to elicit a large 303 response; this is a desirable characteristic if the goal is to 304 maximize the amplification potential of a DNS server as part of a 305 volumetric attack. The ability of a DNS operator to suppress such 306 responses on a particular server makes that server a less useful 307 amplifier. 309 The optional behaviour described in this document to reduce the size 310 of responses to queries with QTYPE=ANY is compatible with the use of 311 DNSSEC by both initiator and responder. 313 10. IANA Considerations 315 The IANA is requested to update the Resource Record (RR) TYPEs 316 Registry [1] entry as follows: 318 +------+-------+-------------------------------+--------------------+ 319 | Type | Value | Meaning | Reference | 320 +------+-------+-------------------------------+--------------------+ 321 | * | 255 | A request for some or all | [RFC1035][RFC6895] | 322 | | | records the server has | [This Document] | 323 | | | available | | 324 +------+-------+-------------------------------+--------------------+ 326 11. Acknowledgements 328 Evan Hunt and David Lawrence provided valuable observations and 329 concrete suggestions. Jeremy Laidman helped make the document 330 better. Tony Finch realized that this document was valuable and 331 implemented it while under attack. A large number of people have 332 provided comments and suggestions we thank them all for the feedback. 334 12. References 336 12.1. Normative References 338 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 339 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 340 . 342 [RFC1035] Mockapetris, P., "Domain names - implementation and 343 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 344 November 1987, . 346 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 347 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 348 RFC2119, March 1997, 349 . 351 12.2. Informative References 353 [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive 354 Nameservers in Reflector Attacks", BCP 140, RFC 5358, DOI 355 10.17487/RFC5358, October 2008, 356 . 358 [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA 359 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, 360 April 2013, . 362 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 363 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 364 2015, . 366 12.3. URIs 368 [1] http://www.iana.org/assignments/dns-parameters/dns- 369 parameters.xhtml#dns-parameters-4 371 Appendix A. Editorial Notes 373 This section (and sub-sections) to be removed prior to publication. 375 A.1. Change History 377 A.1.1. draft-ietf-dnsop-refuse-any-04 379 These are the changes requested during WGLC. The title has been 380 updated for readability The behavior section now contains description 381 of three different approaches in order of preference. Text added on 382 behavior over TCP. The document is clear in how it updates from 383 RFC1035. Minor adjustments for readability and remove redundancy. 385 A.1.2. draft-ietf-dnsop-refuse-any-03 387 Change section name to "Updates to RFC1034", few minor grammar 388 changes suggested by Matthew Pounsett and Tony Finch. 390 Text clarifications, reflecting experience, added implementation 391 experience. 393 A.1.3. draft-ietf-dnsop-refuse-any-02 395 Added suggestion to call out RRSIG is optional when DO=0. 397 Number of text suggestions from Jeremy Laidman 399 A.1.4. draft-ietf-dnsop-refuse-any-01 401 Add IANA Considerations 403 A.1.5. draft-ietf-dnsop-refuse-any-00 405 Re-submitted with a different name following adoption at the dnsop WG 406 meeting convened at IETF 94. 408 A.1.6. draft-jabley-dnsop-refuse-any-01 410 Make signing of RRSets in answers from signed zones mandatory. 412 Document the option of returning an existing RRSet in place of a 413 synthesised one. 415 A.1.7. draft-jabley-dnsop-refuse-any-00 417 Initial draft circulated for comment. 419 Authors' Addresses 421 Joe Abley 422 Dyn, Inc. 423 103-186 Albert Street 424 London, ON N6A 1M1 425 Canada 427 Phone: +1 519 670 9327 428 Email: jabley@dyn.com 429 Olafur Gudmundsson 430 Cloudflare Inc. 432 Email: olafur+ietf@cloudflare.com 434 Marek Majkowski 435 Cloudflare Inc. 437 Email: marek@cloudflare.com