idnits 2.17.1 draft-ietf-dnsop-refuse-any-01.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 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 (April 06, 2016) is 2935 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 322 -- Obsolete informational reference (is this intentional?): RFC 7719 (Obsoleted by RFC 8499) Summary: 0 errors (**), 0 flaws (~~), 2 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: October 8, 2016 CloudFlare Inc. 7 April 06, 2016 9 Providing Minimal-Sized Responses to DNS Queries with QTYPE=ANY 10 draft-ietf-dnsop-refuse-any-01 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 October 8, 2016. 40 Copyright Notice 42 Copyright (c) 2016 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. General Approach . . . . . . . . . . . . . . . . . . . . . . 3 61 5. Behaviour of DNS Responders . . . . . . . . . . . . . . . . . 4 62 6. Behaviour of DNS Initiators . . . . . . . . . . . . . . . . . 5 63 7. HINFO Considerations . . . . . . . . . . . . . . . . . . . . 5 64 8. Changes to RFC 1035 . . . . . . . . . . . . . . . . . . . . . 6 65 9. Implementation experience . . . . . . . . . . . . . . . . . . 6 66 10. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 69 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 13.1. Normative References . . . . . . . . . . . . . . . . . . 7 71 13.2. Informative References . . . . . . . . . . . . . . . . . 7 72 13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 Appendix A. Editorial Notes . . . . . . . . . . . . . . . . . . 8 74 A.1. Change History . . . . . . . . . . . . . . . . . . . . . 8 75 A.1.1. draft-ietf-dnsop-refuse-any-03 . . . . . . . . . . . 8 76 A.1.2. draft-ietf-dnsop-refuse-any-02 . . . . . . . . . . . 8 77 A.1.3. draft-ietf-dnsop-refuse-any-01 . . . . . . . . . . . 8 78 A.1.4. draft-ietf-dnsop-refuse-any-00 . . . . . . . . . . . 8 79 A.1.5. draft-jabley-dnsop-refuse-any-01 . . . . . . . . . . 8 80 A.1.6. draft-jabley-dnsop-refuse-any-00 . . . . . . . . . . 8 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 83 1. Terminology 85 This document uses terminology specific to the Domain Name System 86 (DNS), descriptions of which can be found in [RFC7719]. 88 In this document, "ANY Query" refers to a DNS meta-query with 89 QTYPE=ANY. An "ANY Response" is a response to such a query. 91 In an exchange of DNS messages between two hosts, this document 92 refers to the host sending a DNS request as the initiator, and the 93 host sending a DNS response as the responder. 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 2. Introduction 101 The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". 102 The operator of an authoritative DNS server might choose not to 103 respond to such queries for reasons of local policy, motivated by 104 security, performance or other reasons. 106 The DNS specification [RFC1034] [RFC1035] does not include specific 107 guidance for the behaviour of DNS servers or clients in this 108 situation. This document aims to provide such guidance. 110 3. Motivations 112 ANY queries are legitimately used for debugging and checking the 113 state of a DNS server for a particular name. ANY queries are 114 sometimes used as a attempt to reduce the number of queries needed to 115 get information, e.g. to obtain MX, A and AAAA RRSets for a mail 116 domain in a single query. Although there is no documented guidance 117 available for this use case and some implementations have been 118 observed that appear not to function as perhaps their developers 119 expected. For any developer that assumes that ANY query will be sent 120 to authoritative server to fetch all RRSets, they need to include a 121 fallback when that does not happen. 123 ANY queries are also frequently used to exploit the amplification 124 potential of DNS servers/resolvers using spoofed source addresses and 125 UDP transport (see [RFC5358]). Having the ability to return small 126 responses to such queries makes DNS servers less attractive 127 amplifiers. 129 ANY queries are sometimes used to help mine authoritative-only DNS 130 servers for zone data, since they are expected to return all RRSets 131 for a particular query name. A DNS operator MAY prefer not to send 132 large ANY responses to reduce the potential for information leaks. 134 Some authoritative-only DNS server implementations require additional 135 processing in order to send a conventional ANY response, and avoiding 136 that processing expense might be desirable. 138 4. General Approach 140 This proposal provides a mechanism for an authority server to signal 141 that conventional ANY queries are not supported for a particular 142 QNAME, and to do so in such a way that is both compatible with and 143 triggers desirable behaviour by unmodified clients (e.g. DNS 144 resolvers). 146 Alternative proposals for dealing with ANY queries have been 147 discussed. One approach proposed using a new RCODE to signal that an 148 authoritative server did not answer ANY queries in the standard way. 149 This approach was found to have an undesirable effect on both 150 resolvers and authoritative-only servers; resolvers receiving an 151 unknown RCODE caused them to re-send the same query to all available 152 authoritative servers, rather than suppress future such ANY queries 153 for the same QNAME. 155 This proposal avoids that outcome by returning a non-empty RRSet in 156 the ANY response, providing resolvers with something to cache and 157 effectively suppressing repeat queries to the same or different 158 authority servers. 160 This proposal specifies two different modes of behaviour by DNS 161 responders, for names that exists. Operators/Implementers are free 162 to choose whichever mechanism best suits their environment. 164 1. A DNS responder can choose to select one or subset of RRSets at 165 the QNAME. 167 2. A DNS responder can return instead synthesised HINFO resource 168 record. See Section 7 for discussion of the use of HINFO. 170 5. Behaviour of DNS Responders 172 A DNS responder which receives an ANY query MAY decline to provide a 173 conventional response, and MAY instead send a response with a single 174 RRSet in the answer section. 176 The RRSet returned in the answer section of the response MAY be a 177 single RRSet owned by the name specified in the QNAME. Where 178 multiple RRSets exist, the responder SHOULD choose a small one(s) to 179 reduce its amplification potential. 181 If there is no CNAME present at the owner name matching the QNAME, 182 the resource record returned in the response MAY instead be 183 synthesised, in which case a single HINFO resource record SHOULD be 184 returned. The CPU field of the HINFO RDATA SHOULD be set to RFCXXXX 185 [note to RFC Editor, replace with RFC number assigned to this 186 document]. The OS field of the HINFO RDATA SHOULD be set to the null 187 string to minimize the size of the response. 189 The TTL encoded for a synthesised RR SHOULD be chosen by the operator 190 of the DNS responder to be large enough to suppress frequent 191 subsequent ANY queries from the same initiator with the same QNAME, 192 understanding that a TTL that is too long might make policy changes 193 relating to ANY queries difficult to change in the future. The 194 specific value used is hence a familiar balance when choosing TTL for 195 any RR in any zone, and be specified according to local policy. 197 If the DNS query includes DO=1 and the QNAME corresponds to a zone 198 that is known by the responder to be signed, a valid RRSIG for the 199 RRSets in the answer (or authority if answer is empty) section MUST 200 be returned. In case DO=0 RRSIG SHOULD be omitted. 202 Except as described in this section, the DNS responder MUST follow 203 the standard algorithms when constructing a response. 205 6. Behaviour of DNS Initiators 207 A DNS initiator which sends a query with QTYPE=ANY and receives a 208 response containing an HINFO, as described in Section 5, MAY cache 209 the HINFO response in the normal way. Such cached HINFO resource 210 records SHOULD be retained in the cache following normal caching 211 semantics, as it would with any other response received from a DNS 212 responder. 214 A DNS initiator MAY suppress queries with QTYPE=ANY in the event that 215 the local cache contains a matching HINFO resource record with 216 RDATA.CPU field, as described in Section 5. 218 7. HINFO Considerations 220 In the case where a zone that contains HINFO RRSets is served from an 221 authority server that does not provide conventional ANY responses, it 222 is possible that the HINFO RRSet in an ANY response, once cached by 223 the initiator, might suppress subsequent queries from the same 224 initiator with QTYPE=HINFO. The use of HINFO in this proposal would 225 hence have effectively mask the HINFO RRSet present in the zone. 227 Authority-server operators who serve zones that rely upon 228 conventional use of the HINFO RRTYPE MAY sensibly choose not to 229 deploy the mechanism described in this document or select other type. 231 The HINFO RRTYPE is believed to be rarely used in the DNS at the time 232 of writing, based on observations made both at recursive servers and 233 authority servers. 235 8. Changes to RFC 1035 237 It is important to note that returning a subset of available RRSets 238 when processing an ANY query is legitimate and consistent with 239 [RFC1035]; ANY does not mean ALL. 241 This document describes optional behaviour for both DNS initiators 242 and responders, and implementation of the guidance provided by this 243 document is OPTIONAL. 245 9. Implementation experience 247 In October 2015 CloudFlare Authoritative Nameserver implementation 248 implemented the HINFO response. Few minor problems have been 249 reported and worked out. NSD has for a while implemented a sub-set 250 response. A Bind user implemented this draft suggestion of returning 251 only single RRset during an attack. 253 10. Security Considerations 255 Queries with QTYPE=ANY are frequently observed as part of reflection 256 attacks, since a relatively small query can be used to elicit a large 257 response; this is a desirable characteristic if the goal is to 258 maximize the amplification potential of a DNS server as part of a 259 volumetric attack. The ability of a DNS operator to suppress such 260 responses on a particular server makes that server a less useful 261 amplifier. 263 The optional behaviour described in this document to reduce the size 264 of responses to queries with QTYPE=ANY is compatible with the use of 265 DNSSEC by both initiator and responder. 267 11. IANA Considerations 269 The IANA is requested to update the Resource Record (RR) TYPEs 270 Registry [1] entry as follows: 272 +------+-------+-------------------------------+--------------------+ 273 | Type | Value | Meaning | Reference | 274 +------+-------+-------------------------------+--------------------+ 275 | * | 255 | A request for some or all | [RFC1035][RFC6895] | 276 | | | records the server has | [This Document] | 277 | | | available | | 278 +------+-------+-------------------------------+--------------------+ 280 12. Acknowledgements 282 Evan Hunt and David Lawrence provided valuable observations and 283 concrete suggestions. Jeremy Laidman helped make the document 284 better. Tony Finch realized that this document was valuable and 285 implemented it while under attack. A large number of people have 286 provided comments and suggestions we thank them all for the feedback. 288 13. References 290 13.1. Normative References 292 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 293 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 294 . 296 [RFC1035] Mockapetris, P., "Domain names - implementation and 297 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 298 November 1987, . 300 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 301 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 302 RFC2119, March 1997, 303 . 305 13.2. Informative References 307 [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive 308 Nameservers in Reflector Attacks", BCP 140, RFC 5358, DOI 309 10.17487/RFC5358, October 2008, 310 . 312 [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA 313 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, 314 April 2013, . 316 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 317 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 318 2015, . 320 13.3. URIs 322 [1] http://www.iana.org/assignments/dns-parameters/dns- 323 parameters.xhtml#dns-parameters-4 325 Appendix A. Editorial Notes 327 This section (and sub-sections) to be removed prior to publication. 329 A.1. Change History 331 A.1.1. draft-ietf-dnsop-refuse-any-03 333 Text clarifications, reflecting experience, added implementation 334 experience. 336 A.1.2. draft-ietf-dnsop-refuse-any-02 338 Added suggestion to call out RRSIG is optional when DO=0. 340 Number of text suggestions from Jeremy Laidman 342 A.1.3. draft-ietf-dnsop-refuse-any-01 344 Add IANA Considerations 346 A.1.4. draft-ietf-dnsop-refuse-any-00 348 Re-submitted with a different name following adoption at the dnsop wg 349 meeting convened at IETF 94. 351 A.1.5. draft-jabley-dnsop-refuse-any-01 353 Make signing of RRSets in answers from signed zones mandatory. 355 Document the option of returning an existing RRSet in place of a 356 synthesised one. 358 A.1.6. draft-jabley-dnsop-refuse-any-00 360 Initial draft circulated for comment. 362 Authors' Addresses 364 Joe Abley 365 Dyn, Inc. 366 103-186 Albert Street 367 London, ON N6A 1M1 368 Canada 370 Phone: +1 519 670 9327 371 Email: jabley@dyn.com 372 Olafur Gudmundsson 373 CloudFlare Inc. 375 Email: olafur@cloudflare.com 377 Marek Majkowski 378 CloudFlare Inc. 380 Email: marek@cloudflare.com