idnits 2.17.1 draft-bortzmeyer-dnsop-nxdomain-cut-02.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 abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- 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 RFC2308, 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 (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 (November 29, 2015) is 3071 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 20 ** Downref: Normative reference to an Informational draft: draft-ietf-dnsop-dns-terminology (ref. 'I-D.ietf-dnsop-dns-terminology') -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) == Outdated reference: A later version (-09) exists of draft-ietf-dnsop-qname-minimisation-07 == Outdated reference: A later version (-03) exists of draft-fujiwara-dnsop-nsec-aggressiveuse-02 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Domain Name System Operations (dnsop) Working Group S. Bortzmeyer 3 Internet-Draft AFNIC 4 Updates: 1034,2308 (if approved) S. Huque 5 Intended status: Standards Track Verisign labs 6 Expires: June 1, 2016 November 29, 2015 8 NXDOMAIN really means there is nothing underneath 9 draft-bortzmeyer-dnsop-nxdomain-cut-02 11 Abstract 13 This document states clearly that when a DNS resolver receives a 14 response with response code NXDOMAIN, it means that the name in the 15 question section AND ALL THE NAMES UNDER IT do not exist. 17 REMOVE BEFORE PUBLICATION: this document should be discussed in the 18 IETF DNSOP (DNS Operations) group, through its mailing list. The 19 source of the document, as well as a list of open issues, is 20 currently kept at Github [1]. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on June 1, 2016. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction and background . . . . . . . . . . . . . . . . . 2 57 1.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 58 2. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Possible issues . . . . . . . . . . . . . . . . . . . . . . . 4 61 5. Future work . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 6 65 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 10.2. Informative References . . . . . . . . . . . . . . . . . 8 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction and background 73 The DNS protocol [RFC1035] defines response code 3 as "Name Error", 74 or "NXDOMAIN", i.e. the queried domain name does not exist in the 75 DNS. Since domain names are represented as a tree of labels 76 ([RFC1034], Section 3.1), non-existence of a node implies non- 77 existence of the entire sub-tree rooted at this node. 79 The DNS iterative resolution algorithm precisely interprets the 80 NXDOMAIN signal in this manner. If it encounters an NXDOMAIN 81 response code from an authoritative server, it immediately stops 82 iteration and returns the NXDOMAIN response to the querier. 84 However, in virtually all existing resolvers, a cached NXDOMAIN is 85 not considered "proof" that there can be no child domains underneath. 86 This is due to an ambiguity in [RFC1034] that failed to distinguish 87 ENT (empty nonterminal domain names, 88 [I-D.ietf-dnsop-dns-terminology]) from nonexistent names. For 89 DNSSEC, the IETF had to distinguish this case ([RFC4035], section 90 3.1.3.2), but the implication on non-DNSSEC resolvers wasn't fully 91 realized. 93 This document specifies that an NXDOMAIN response for a domain name 94 means that no child domains underneath the queried name exist either. 95 And furthermore, that DNS resolvers should interpret cached NXDOMAIN 96 responses in this manner. Since the domain names are organized in a 97 tree, it is a simple consequence of the tree structure: non-existence 98 of a node implies non-existence of the entire sub-tree rooted at this 99 node. 101 1.1. Requirements Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC2119]. 107 2. Rules 109 When searching downward in its cache, an iterative caching DNS 110 resolver SHOULD stop searching if it encounters a cached NXDOMAIN. 111 The response to the triggering query should be NXDOMAIN. 113 TODO The next paragraph is challenged because too implementation- 114 oriented. Should we just keep the first paragraph? My concern is 115 that some resolvers may have an implementation of the cache made of a 116 tree plus a hashed index and therefore won't "search downward" if 117 they have a cached answer. 119 When an iterative caching DNS resolver stores an NXDOMAIN in its 120 cache, all names and RRsets at or below that node SHOULD be deleted 121 since they will have become unreachable. "Deleted" means that 122 subsequent requests for these names will yield NXDOMAIN. [TODO: 123 currently under discussion, some people find it dangerous. MAY 124 instead of SHOULD? Only if the NXDOMAIN is DNSSEC-validated? 125 Perhaps the resolver could be configured to not "bulk delete" TLDs 126 (or root). See Section 7.] [TODO: currently under discussion, some 127 people find it costly for the resolver. A large purge also causes 128 the resolver to do a lot of (possibly CPU intensive) work, and could 129 also affect the traffic levels between a recursive and 130 authoritatives. Perhaps a cache may want to limit the number of 131 nodes/records that it deletes per NXDOMAIN response.] 133 By implication, a stream of queries foo.example, then 134 bar.foo.example, where foo.example does not exist would normally 135 cause both queries to be forwarded to example's nameservers. 136 Following this recommended practice of "NXDOMAIN cut", the second 137 query and indeed any other query for names at or below foo.example 138 would not be forwarded. 140 These rules replace the second paragraph of section 5 of [RFC2308]. 141 Otherwise, [RFC2308] applies unchanged, and the fact that a subtree 142 does not exist is not forever: the NXDOMAIN is cached only for the 143 duration of the "negative TTL" (section 3 of xref 144 target="RFC2308"/>). 146 Validating resolvers need to select the necessary NSEC or NSEC3 147 records and include them in the AUTHORITY section of the response to 148 provide authenticated denial of existence for names underneath the 149 NXDOMAIN boundary. 151 Warning: because of [RFC6604], the name whose existence is denied by 152 the NXDOMAIN is not always the QNAME. If there is a chain of CNAME 153 (or DNAME), the name which does not exist is the last of the chain. 154 TODO: find a dedicated terminology such as "NXDOMAINed name" or 155 "denied domain" instead of "QNAME". 157 3. Benefits 159 The main benefit is a better efficiency of the caches. In the 160 example above, we send only one query instead of two, the second one 161 being answered from the cache. 163 The correct behavior (in [RFC1034] and made clearer in this document) 164 is specially useful when combined with QNAME minimisation 165 [I-D.ietf-dnsop-qname-minimisation] since it will allow to stop 166 searching as soon as a NXDOMAIN is encountered. 168 NXDOMAIN cut may also help mitigate certain types of random QNAME 169 attacks [joost-dnsterror] [balakrichenan-dafa888], where there is a 170 fixed suffix which does not exist. In these attacks against the 171 authoritative name server, queries are sent to resolvers for a QNAME 172 composed of a fixed suffix ("dafa888.wf" in one of the articles 173 above), which is typically nonexistent, and a random prefix, 174 different for each request. A resolver receiving these requests have 175 to forward them to the authoritative servers. With NXDOMAIN cut, we 176 would just have to send to the resolver a query for the fixed suffix, 177 the resolver would get a NXDOMAIN and then would stop forwarding the 178 queries. (It would be better if the SOA record in the NXDOMAIN 179 response were sufficient to find the non-existing domain but this is 180 more delicate, see Section 5.) 182 Since the principles set in this document are so great, why are the 183 rules of Section 2 SHOULD and not MUST? This is because some 184 resolver may have a cache which is NOT organized as a tree (but, for 185 instance, as a dictionary) and therefore have a good reason to ignore 186 this. 188 4. Possible issues 190 Let's assume the TLD example exists but foobar.example is not 191 delegated (so the example's name servers will reply NXDOMAIN for a 192 query about anything.foobar.example). A system administrator decides 193 to name the internal machines of his organization under 194 office.foobar.example and use a trick of his resolver to forward 195 requests about this zone to his local authoritative name servers. 196 NXDOMAIN cut would create problems here, since, depending on the 197 order of requests to the resolver, it may have cached the NXDOMAIN 198 from example and therefore "deleted" everything under. This document 199 assumes that such setup is rare and does not need to be supported. 201 Another issue that may happen: today, we see broken authoritative 202 name servers which reply to ENT ([I-D.ietf-dnsop-dns-terminology], 203 section 6) with NXDOMAIN instead of the normal NODATA 204 ([I-D.ietf-dnsop-dns-terminology], section 3). 206 RFC-EDITOR: REMOVE THE PARAGRAPH BEFORE PUBLICATION. An example 207 today is mta2._domainkey.cbs.nl (which exists) where querying 208 _domainkey.cbs.nl yields NXDOMAIN. Another example is www.upenn.edu, 209 redirected to www.upenn.edu-dscg.edgesuite.net while a query for edu- 210 dscg.edgesuite.net returns NXDOMAIN. 212 Such name servers are definitely broken and have always been. They 213 MUST be fixed. Given the advantages of NXDOMAIN cuts, there is 214 little reason to support this behavior. 216 5. Future work 218 TODO: drop this section entirely? Or just downgrade it to an 219 appendix "why can't we just use the owner name of the returned SOA"? 221 In this document, we deduce the non-existence of a domain only for 222 NXDOMAIN answers where the QNAME was this exact domain. If a 223 resolver sends a query to the name servers of the TLD example, and 224 asks the MX record for www.foobar.example, and receives a NXDOMAIN, 225 it can only register the fact that www.foobar.example (and everything 226 underneath) does not exist. Even if the accompanying SOA record is 227 for example only, one cannot infer that foobar.example is 228 nonexistent. The accompanying SOA indicates the apex of the zone, 229 not the closest existing domain name. 231 RFC-EDITOR: REMOVE BEFORE PUBLICATION: to use a real example today, 232 ask the authoritative name servers of the TLD fr about 233 anything.which.does.not.exist.gouv.fr. The SOA will indicate fr (the 234 apex) even while gouv.fr does exist (there is no zone cut between 235 gouv.fr and fr). 237 In the future, deducing the non-existence of a node from the SOA in 238 the NXDOMAIN reply may certainly help with random qnames attacks but 239 this is out-of-scope for this document. It would require to address 240 the problems mentioned in the previous paragraph. A possible 241 solution would be, when receiving a NXDOMAIN with a SOA which is more 242 than one label up in the tree, to send requests for the domains which 243 are between the QNAME and the owner name of the SOA. (A resolver 244 which does DNSSEC validation or QNAME minimisation will need to do 245 it, anyway.) 247 TODO a mention of [I-D.fujiwara-dnsop-nsec-aggressiveuse]? Unlike 248 NXDOMAIN cut, it requires DNSSEC but it is more powerful since it can 249 synthetize NXDOMAINs. 251 6. IANA Considerations 253 This document has no actions for IANA. 255 7. Security Considerations 257 The technique described here may help against a denial-of-service 258 attack named "random qnames" and described in Section 3. Apart from 259 that, it is believed to have no security consequences. 261 If a resolver does not validate the answers with DNSSEC, it can of 262 course be poisoned with a false NXDOMAIN, thus "deleting" a part of 263 the domain name tree. This denial-of-service attack is already 264 possible with the rules of this document (but "NXDOMAIN cut" may 265 increase its effects). The only solution is to use DNSSEC. 267 8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 269 This section records the status of known implementations of the 270 protocol defined by this specification at the time of posting of this 271 Internet-Draft, and is based on a proposal described in [RFC6982]. 272 The description of implementations in this section is intended to 273 assist the IETF in its decision processes in progressing drafts to 274 RFCs. Please note that the listing of any individual implementation 275 here does not imply endorsement by the IETF. Furthermore, no effort 276 has been spent to verify the information presented here that was 277 supplied by IETF contributors. This is not intended as, and must not 278 be construed to be, a catalog of available implementations or their 279 features. Readers are advised to note that other implementations may 280 exist. 282 According to [RFC6982], "this will allow reviewers and working groups 283 to assign due consideration to documents that have the benefit of 284 running code, which may serve as evidence of valuable experimentation 285 and feedback that have made the implemented protocols more mature. 286 It is up to the individual working groups to use this information as 287 they see fit". 289 As of today, all existing DNS resolvers are conservative: they 290 consider a NXDOMAIN as only significant for the name itself, not for 291 the names under. All current recursive servers will upstream a query 292 for out-of-cache sub.example.com even if their cache contains an 293 NXDOMAIN for example.com. 295 9. Acknowledgments 297 The text of this document was mostly copied from 298 [I-D.vixie-dnsext-resimprove], section 3. Thanks to its authors, 299 Paul Vixie, Rodney Joffe and Frederico Neves. 301 Thanks to Duane Wessels, Tony Finch and Jinmei Tatuya for fact 302 checking and explanations. 304 10. References 306 10.1. Normative References 308 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 309 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 310 . 312 [RFC1035] Mockapetris, P., "Domain names - implementation and 313 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 314 November 1987, . 316 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 317 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 318 RFC2119, March 1997, 319 . 321 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 322 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, 323 . 325 [RFC6604] Eastlake 3rd, D., "xNAME RCODE and Status Bits 326 Clarification", RFC 6604, DOI 10.17487/RFC6604, April 327 2012, . 329 [I-D.ietf-dnsop-dns-terminology] 330 Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 331 Terminology", draft-ietf-dnsop-dns-terminology-05 (work in 332 progress), September 2015. 334 10.2. Informative References 336 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 337 Rose, "Protocol Modifications for the DNS Security 338 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 339 . 341 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 342 Code: The Implementation Status Section", RFC 6982, DOI 343 10.17487/RFC6982, July 2013, 344 . 346 [I-D.vixie-dnsext-resimprove] 347 Vixie, P., Joffe, R., and F. Neves, "Improvements to DNS 348 Resolvers for Resiliency, Robustness, and Responsiveness", 349 draft-vixie-dnsext-resimprove-00 (work in progress), June 350 2010. 352 [I-D.ietf-dnsop-qname-minimisation] 353 Bortzmeyer, S., "DNS query name minimisation to improve 354 privacy", draft-ietf-dnsop-qname-minimisation-07 (work in 355 progress), October 2015. 357 [I-D.fujiwara-dnsop-nsec-aggressiveuse] 358 Fujiwara, K. and A. Kato, "Aggressive use of NSEC/NSEC3", 359 draft-fujiwara-dnsop-nsec-aggressiveuse-02 (work in 360 progress), October 2015. 362 [joost-dnsterror] 363 Joost, M., "About DNS Attacks and ICMP Destination 364 Unreachable Reports", December 2014, 365 . 367 [balakrichenan-dafa888] 368 Balakrichenan, S., "Disturbance in the DNS - "Random 369 qnames", the dafa888 DoS attack"", October 2014, 370 . 373 Authors' Addresses 374 Stephane Bortzmeyer 375 AFNIC 376 1, rue Stephenson 377 Montigny-le-Bretonneux 78180 378 France 380 Phone: +33 1 39 30 83 46 381 Email: bortzmeyer+ietf@nic.fr 382 URI: http://www.afnic.fr/ 384 Shumon Huque 385 Verisign labs 386 12061 Bluemont Way 387 Reston 20190 388 USA 390 Email: shuque@verisign.com 391 URI: http://www.verisignlabs.com/