idnits 2.17.1 draft-ietf-dnsop-refuse-any-00.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 (November 5, 2015) is 3085 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 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: May 8, 2016 CloudFlare Inc. 7 November 5, 2015 9 Providing Minimal-Sized Responses to DNS Queries with QTYPE=ANY 10 draft-ietf-dnsop-refuse-any-00 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 May 8, 2016. 40 Copyright Notice 42 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. General Approach . . . . . . . . . . . . . . . . . . . . . . . 6 61 5. Behaviour of DNS Responders . . . . . . . . . . . . . . . . . 7 62 6. Behaviour of DNS Initiators . . . . . . . . . . . . . . . . . 8 63 7. HINFO Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 8. Changes to RFC 1035 . . . . . . . . . . . . . . . . . . . . . 10 65 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 66 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 67 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 68 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 70 12.2. Informative References . . . . . . . . . . . . . . . . . 14 71 Appendix A. Editorial Notes . . . . . . . . . . . . . . . . . . . 15 72 A.1. Venue . . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 A.2. Change History . . . . . . . . . . . . . . . . . . . . . 15 74 A.2.1. draft-ietf-dnsop-refuse-any-00 . . . . . . . . . . . . 15 75 A.2.2. draft-jabley-dnsop-refuse-any-01 . . . . . . . . . . . 15 76 A.2.3. draft-jabley-dnsop-refuse-any-00 . . . . . . . . . . . 15 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 79 1. Terminology 81 This document uses terminology specific to the Domain Name System 82 (DNS), descriptions of which can be found in 83 [I-D.ietf-dnsop-dns-terminology]. 85 In this document, "ANY Query" refers to a DNS query with QTYPE=ANY. 86 An "ANY Response" is a response to such a query. 88 In an exchange of DNS messages between two hosts, this document 89 refers to the host sending a DNS request as the initiator, and the 90 host sending a DNS response as the responder. 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 2. Introduction 98 The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". 99 The operator of an authoritative DNS server might choose not to 100 respond to such queries for reasons of local policy, motivated by 101 security, performance or other reasons. 103 The DNS specification [RFC1034] [RFC1035] does not include specific 104 guidance for the behaviour of DNS servers or clients in this 105 situation. This document aims to provide such guidance. 107 3. Motivations 109 ANY queries are legitimately used for debugging and checking the 110 state of a DNS server for a particular owner name. ANY queries are 111 sometimes used as a attempt to reduce the number of queries needed to 112 get information, e.g. to obtain MX, A and AAAA RRSets for a mail 113 domain in a single query, although there is no documented guidance 114 available for this use case and some implementations have been 115 observed that appear not to function as perhaps their developers 116 expected. 118 ANY queries are also frequently used to exploit the amplification 119 potential of DNS servers using spoofed source addresses and UDP 120 transport (see [RFC5358]). Having the ability to return small 121 responses to such queries makes DNS servers less attractive 122 amplifiers. 124 ANY queries are sometimes used to help mine authoritative-only DNS 125 servers for zone data, since they return all RRSets for a particular 126 owner name. A DNS zone maintainer might prefer not to send full ANY 127 responses to reduce the potential for such information leaks. 129 Some authoritative-only DNS server implementations require additional 130 processing in order to send a conventional ANY response, and avoiding 131 that processing expense may be desirable. 133 4. General Approach 135 This proposal provides a mechanism for an authority server to signal 136 that conventional ANY queries are not supported for a particular 137 QNAME, and to do so in such a way that is both compatible with and 138 triggers desirable behaviour by unmodified clients (e.g. DNS 139 resolvers). 141 Alternative proposals for dealing with ANY queries have been 142 discussed. One approach proposed using a new RCODE to signal that an 143 authortitaive server did not answer ANY queries in the standard way. 144 This approach was found to have an undesirable effect on both 145 resolvers and authoritative-only servers; resolvers receiving an 146 unknown RCODE caused them to re-send the same query to all available 147 authoritative servers, rather than suppress future such ANY queries 148 for the same QNAME. 150 This proposal avoids that outcome by returning a non-empty RRSet in 151 the ANY response, providing resolvers with something to cache and 152 effectively suppressing repeat queries to the same or different 153 authority servers. 155 This proposal specifies two different modes of behaviour by DNS 156 responders, and operators are free to choose whichever mechanism best 157 suits their environment. 159 1. A DNS responder may choose to search for an owner name that 160 matches the QNAME and, if that name owns multiple RRSets, return 161 just one of them. 163 2. A DNS responder for whom a search for an owner name with an 164 existing resource record is expensive may instead synthesise an 165 HINFO resource record and return that instead. See Section 7 for 166 discussion of the use of HINFO. 168 5. Behaviour of DNS Responders 170 A DNS responder which receives an ANY query MAY decline to provide a 171 conventional response, and MAY instead send a response with a single 172 RRSet in the answer section. 174 The RRSet returned in the answer section of the response MAY be a 175 single RRSet owned by the name specified in the QNAME. Where 176 multiple RRSets exist, the responder MAY choose a small one to reduce 177 its amplification potential. 179 If there is no CNAME present at the owner name matching the QNAME, 180 the resource record returned in the response MAY instead synthesised, 181 in which case a single HINFO resource record should be returned. The 182 CPU field of the HINFO RDATA SHOULD be set to RFCXXXX [note to RFC 183 Editor, replace with RFC number assigned to this document]. The OS 184 field of the HINFO RDATA SHOULD be set to the null string to minimise 185 the size of the response. 187 The TTL encoded for a synthesised RR SHOULD be chosen by the operator 188 of the DNS responder to be large enough to suppress frequent 189 subsequent ANY queries from the same initiator with the same QNAME, 190 understanding that a TTL that is too long might make policy changes 191 relating to ANY queries difficult to change in the future. The 192 specific value used is hence a familiar balance when choosing TTLs 193 for any RR in any zone, and should be specified according to local 194 policy. 196 If the DNS query includes DO=1 and the QNAME corresponds to a zone 197 that is known by the responder to be signed, a valid RRSIG for the 198 RRSets in the answer section MUST be returned. 200 Except as described in this section, the DNS responder MUST follow 201 the standard algorithms when constructing a response. 203 6. Behaviour of DNS Initiators 205 XXX consider whether separate text here is required depending on 206 whether the initiator is a non-caching stub resolver or a caching 207 recursive resolver. 209 A DNS initator which sends a query with QTYPE=ANY and receives a 210 response containing an HINFO, as described in Section 5, MAY cache 211 the HINFO response in the normal way. Such cached HINFO resource 212 records SHOULD be retained in the cache following normal caching 213 semantics, as it would with any other response received from a DNS 214 responder. 216 A DNS initiator MAY suppress queries with QTYPE=ANY in the event that 217 the local cache contains a matching HINFO resource record with 218 RDATA.CPU field, as described in Section 5. 220 7. HINFO Considerations 222 In the case where a zone that contains HINFO RRSets is served from an 223 authority server that does not provide conventional ANY responses, it 224 is possible that the HINFO RRSet in an ANY response, once cached by 225 the initiator, might suppress subsequent queries from the same 226 initiator with QTYPE=HINFO. The use of HINFO in this proposal would 227 hence have effectively masked the HINFO RRSet present in the zone. 229 Authority-server operators who serve zones that rely upon 230 conventional use of the HINFO RRType might sensibly choose not to 231 deploy the mechanism described in this document. 233 The HINFO RRType is believed to be rarely used in the DNS at the time 234 of writing, based on observations made both at recursive servers and 235 authority servers. 237 8. Changes to RFC 1035 239 It is important to note that returning a subset of available RRSets 240 when processing an ANY query is legitimate and consistent with 241 [RFC1035]; ANY does not mean ALL. 243 This document describes optional behaviour for both DNS initators and 244 responders, and implementation of the guidance provided by this 245 document is OPTIONAL. 247 9. Security Considerations 249 Queries with QTYPE=ANY are frequently observed as part of reflection 250 attacks, since a relatively small query can be used to elicit a large 251 response; this is a desirable characteristic if the goal is to 252 maximise the amplification potential of a DNS server as part of a 253 volumetric attack. The ability of a DNS operator to suppress such 254 responses on a particular server makes that server a less useful 255 amplifier. 257 The optional behaviour described in this document to reduce the size 258 of responses to queries with QTYPE=ANY is compatible with the use of 259 DNSSEC by both initiator and responder. 261 10. IANA Considerations 263 This document has no IANA actions. 265 11. Acknowledgements 267 Evan Hunt and David Lawrence provided valuable observations. 269 12. References 271 12.1. Normative References 273 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 274 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 275 . 277 [RFC1035] Mockapetris, P., "Domain names - implementation and 278 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 279 November 1987, . 281 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 282 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 283 RFC2119, March 1997, 284 . 286 12.2. Informative References 288 [I-D.ietf-dnsop-dns-terminology] 289 Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 290 Terminology", draft-ietf-dnsop-dns-terminology-05 (work in 291 progress), September 2015. 293 [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive 294 Nameservers in Reflector Attacks", BCP 140, RFC 5358, 295 DOI 10.17487/RFC5358, October 2008, 296 . 298 Appendix A. Editorial Notes 300 This section (and sub-sections) to be removed prior to publication. 302 A.1. Venue 304 An appropriate forum for discussion of this draft is the dnsop 305 working group. 307 A.2. Change History 309 A.2.1. draft-ietf-dnsop-refuse-any-00 311 Re-submitted with a different name following adoption at the dnsop wg 312 meeting convened at IETF 94. 314 A.2.2. draft-jabley-dnsop-refuse-any-01 316 Make signing of RRSets in answers from signed zones mandatory. 318 Document the option of returning an existing RRSet in place of a 319 synthesised one. 321 A.2.3. draft-jabley-dnsop-refuse-any-00 323 Initial draft circulated for comment. 325 Authors' Addresses 327 Joe Abley 328 Dyn, Inc. 329 103-186 Albert Street 330 London, ON N6A 1M1 331 Canada 333 Phone: +1 519 670 9327 334 Email: jabley@dyn.com 336 Olafur Gudmundsson 337 CloudFlare Inc. 339 Email: olafur@cloudflare.com 341 Marek Majkowski 342 CloudFlare Inc. 344 Email: marek@cloudflare.com