idnits 2.17.1 draft-ietf-dnsop-nxdomain-cut-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 abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 4 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 directly say this. It does mention RFC1034 though, so this could be OK. -- The draft header indicates that this document updates RFC2308, but the abstract doesn't seem to directly say this. It does mention RFC2308 though, so this could be OK. 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 (December 27, 2015) is 3043 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 349 -- Looks like a reference, but probably isn't: '2' on line 351 -- Looks like a reference, but probably isn't: '3' on line 353 -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) -- Obsolete informational reference (is this intentional?): RFC 7719 (Obsoleted by RFC 8499) == Outdated reference: A later version (-09) exists of draft-ietf-dnsop-qname-minimisation-08 == Outdated reference: A later version (-03) exists of draft-fujiwara-dnsop-nsec-aggressiveuse-02 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 9 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 29, 2016 December 27, 2015 8 NXDOMAIN really means there is nothing underneath 9 draft-ietf-dnsop-nxdomain-cut-00 11 Abstract 13 This document states clearly that when a DNS resolver receives a 14 response with response code of NXDOMAIN, it means that the domain 15 name which is thus denied 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 This documents clarifies RFC 1034 and modifies a bit RFC 2308 so it 23 updates both of them. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on June 29, 2016. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction and background . . . . . . . . . . . . . . . . . 2 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Possible issues . . . . . . . . . . . . . . . . . . . . . . . 5 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 66 7. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 5 67 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 70 9.2. Informative References . . . . . . . . . . . . . . . . . 7 71 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 Appendix A. Why can't we just use the owner name of the returned 73 SOA? . . . . . . . . . . . . . . . . . . . . . . . . 8 74 Appendix B. Related approaches . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 77 1. Introduction and background 79 The DNS protocol [RFC1035] defines response code 3 as "Name Error", 80 or "NXDOMAIN", i.e. the queried domain name does not exist in the 81 DNS. Since domain names are represented as a tree of labels 82 ([RFC1034], Section 3.1), non-existence of a node implies non- 83 existence of the entire sub-tree rooted at this node. 85 The DNS iterative resolution algorithm precisely interprets the 86 NXDOMAIN signal in this manner. If it encounters an NXDOMAIN 87 response code from an authoritative server, it immediately stops 88 iteration and returns the NXDOMAIN response to the querier. 90 However, in virtually all existing resolvers, a cached NXDOMAIN is 91 not considered "proof" that there can be no child domains underneath. 92 This is due to an ambiguity in [RFC1034] that failed to distinguish 93 Empty Non-Terminal names (ENT) ([RFC7719]) from nonexistent names. 94 For DNSSEC, the IETF had to distinguish this case ([RFC4035], section 95 3.1.3.2), but the implication on non-DNSSEC resolvers wasn't fully 96 realized. 98 This document specifies that an NXDOMAIN response for a domain name 99 means that no child domains underneath the queried name exist either. 100 And furthermore, that DNS resolvers should interpret cached NXDOMAIN 101 responses in this manner. Since the domain names are organized in a 102 tree, it is a simple consequence of the tree structure: non-existence 103 of a node implies non-existence of the entire sub-tree rooted at this 104 node. 106 1.1. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 "Denied name": the domain name whose existence has been denied by a 113 response of rcode NXDOMAIN. In most cases, it is the QNAME but, 114 because of [RFC6604], it is not always the case. 116 2. Rules 118 When searching downward in its cache, an iterative caching DNS 119 resolver SHOULD stop searching if it encounters a cached NXDOMAIN. 120 The response to the triggering query should be NXDOMAIN. 122 When an iterative caching DNS resolver stores an NXDOMAIN in its 123 cache, all names and RRsets at or below that node SHOULD be 124 considered to be unreachable, and subsequent queries for such names 125 SHOULD elicit an NXDOMAIN response. A resolver, depending on its 126 implementation, MAY prune the subtree of positive cache entries at 127 that node, or delete all individual cache entries for names below 128 that node. [TODO: currently under discussion, some people find it 129 dangerous. Only if the NXDOMAIN is DNSSEC-validated? Perhaps the 130 resolver could be configured to not "bulk delete" TLDs (or root). 131 See Section 6.] 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 [RFC2308]). 145 If the cached NXDOMAIN response is from a DNSSEC signed zone, then it 146 will have accompanying NSEC or NSEC3 records that authenticate the 147 non-existence of the name. For a descendant name of the original 148 NXDOMAIN name, the same set of NSEC or NSEC3 records proves the non- 149 existence of the descendant name. The iterative, caching resolver 150 MUST return these NSEC or NSEC3 records in the response to the 151 triggering query. 153 Warning: if there is a chain of CNAME (or DNAME), the name which does 154 not exist is the last of the chain ([RFC6604]) and not the QNAME. 155 The NXDOMAIN stored in the cache is for the denied name, not always 156 for the QNAME. 158 3. Benefits 160 The main benefit is a better efficiency of the caches. In the 161 example above, we send only one query instead of two, the second one 162 being answered from the cache. 164 The correct behavior (in [RFC1034] and made clearer in this document) 165 is specially useful when combined with QNAME minimisation 166 [I-D.ietf-dnsop-qname-minimisation] since it will allow a resolver to 167 stop searching as soon as an NXDOMAIN is encountered. 169 NXDOMAIN cut may also help mitigate certain types of random QNAME 170 attacks [joost-dnsterror] [balakrichenan-dafa888], where there is a 171 fixed suffix which does not exist. In these attacks against the 172 authoritative name server, queries are sent to resolvers for a QNAME 173 composed of a fixed suffix ("dafa888.wf" in one of the articles 174 above), which is typically nonexistent, and a random prefix, 175 different for each request. A resolver receiving these requests have 176 to forward them to the authoritative servers. With NXDOMAIN cut, we 177 would just have to send to the resolver a query for the fixed suffix, 178 the resolver would get a NXDOMAIN and then would stop forwarding the 179 queries. (It would be better if the SOA record in the NXDOMAIN 180 response were sufficient to find the non-existing domain but it is 181 not the case, see Appendix A.) 183 Since the principles set in this document are so great, why are the 184 rules of Section 2 SHOULD and not MUST? This is because some 185 resolver may have a cache which is NOT organized as a tree (but, for 186 instance, as a dictionary) and therefore have a good reason to ignore 187 this. 189 4. Possible issues 191 Let's assume the TLD example exists but foobar.example is not 192 delegated (so the example's name servers will reply NXDOMAIN for a 193 query about anything.foobar.example). A system administrator decides 194 to name the internal machines of his organization under 195 office.foobar.example and use a trick of his resolver to forward 196 requests about this zone to his local authoritative name servers. 197 NXDOMAIN cut would create problems here, since, depending on the 198 order of requests to the resolver, it may have cached the NXDOMAIN 199 from example and therefore "deleted" everything under. This document 200 assumes that such setup is rare and does not need to be supported. 202 Another issue that may happen: today, we see broken authoritative 203 name servers which reply to ENT ([RFC7719], section 6) with NXDOMAIN 204 instead of the normal NODATA ([RFC7719], 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 wrong and have always been. Given 213 the advantages of NXDOMAIN cuts, there is little reason to support 214 this behavior. 216 5. IANA Considerations 218 This document has no actions for IANA. 220 6. Security Considerations 222 The technique described here may help against a denial-of-service 223 attack named "random qnames" and described in Section 3. Apart from 224 that, it is believed to have no security consequences. 226 If a resolver does not validate the answers with DNSSEC, it can of 227 course be poisoned with a false NXDOMAIN, thus "deleting" a part of 228 the domain name tree. This denial-of-service attack is already 229 possible without the rules of this document (but "NXDOMAIN cut" may 230 increase its effects). The only solution is to use DNSSEC. 232 7. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 234 This section records the status of known implementations of the 235 protocol defined by this specification at the time of posting of this 236 Internet-Draft, and is based on a proposal described in [RFC6982]. 238 The description of implementations in this section is intended to 239 assist the IETF in its decision processes in progressing drafts to 240 RFCs. Please note that the listing of any individual implementation 241 here does not imply endorsement by the IETF. Furthermore, no effort 242 has been spent to verify the information presented here that was 243 supplied by IETF contributors. This is not intended as, and must not 244 be construed to be, a catalog of available implementations or their 245 features. Readers are advised to note that other implementations may 246 exist. 248 According to [RFC6982], "this will allow reviewers and working groups 249 to assign due consideration to documents that have the benefit of 250 running code, which may serve as evidence of valuable experimentation 251 and feedback that have made the implemented protocols more mature. 252 It is up to the individual working groups to use this information as 253 they see fit". 255 As of today, practically all existing DNS resolvers are conservative: 256 they consider a NXDOMAIN as only significant for the name itself, not 257 for the names under. Almost all the current recursive servers will 258 send upstream a query for out-of-cache sub.example.com even if their 259 cache contains an NXDOMAIN for example.com. 261 There are a few exceptions. The Unbound resolver has a configuration 262 parameter called "harden-below-nxdomain" [2], which if set to "yes" 263 turns on NXDOMAIN cut behavior ("only DNSSEC-secure nxdomains are 264 used", see Section 6). The PowerDNS recursor has optional partial 265 support for NXDOMAIN cut, for the root domain only, with its "root- 266 nx-trust" setting, described as [3] "If set, an NXDOMAIN from the 267 root-servers will serve as a blanket NXDOMAIN for the entire TLD the 268 query belonged to. The effect of this is far fewer queries to the 269 root-servers.". 271 8. Acknowledgments 273 The main idea is in this document is taken from 274 [I-D.vixie-dnsext-resimprove], section 3, "Stopping Downward Cache 275 Search on NXDOMAIN". Thanks to its authors, Paul Vixie, Rodney 276 Joffe, and Frederico Neves. Additionally Tony Finch, John Levine, 277 Jinmei Tatuya, and Duane Wessels provided valuable feedback and 278 suggestions. 280 9. References 281 9.1. Normative References 283 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 284 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 285 . 287 [RFC1035] Mockapetris, P., "Domain names - implementation and 288 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 289 November 1987, . 291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 292 Requirement Levels", BCP 14, RFC 2119, 293 DOI 10.17487/RFC2119, March 1997, 294 . 296 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 297 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, 298 . 300 [RFC6604] Eastlake 3rd, D., "xNAME RCODE and Status Bits 301 Clarification", RFC 6604, DOI 10.17487/RFC6604, April 302 2012, . 304 9.2. Informative References 306 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 307 Rose, "Protocol Modifications for the DNS Security 308 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 309 . 311 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 312 Code: The Implementation Status Section", RFC 6982, 313 DOI 10.17487/RFC6982, July 2013, 314 . 316 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 317 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 318 2015, . 320 [I-D.vixie-dnsext-resimprove] 321 Vixie, P., Joffe, R., and F. Neves, "Improvements to DNS 322 Resolvers for Resiliency, Robustness, and Responsiveness", 323 draft-vixie-dnsext-resimprove-00 (work in progress), June 324 2010. 326 [I-D.ietf-dnsop-qname-minimisation] 327 Bortzmeyer, S., "DNS query name minimisation to improve 328 privacy", draft-ietf-dnsop-qname-minimisation-08 (work in 329 progress), November 2015. 331 [I-D.fujiwara-dnsop-nsec-aggressiveuse] 332 Fujiwara, K. and A. Kato, "Aggressive use of NSEC/NSEC3", 333 draft-fujiwara-dnsop-nsec-aggressiveuse-02 (work in 334 progress), October 2015. 336 [joost-dnsterror] 337 Joost, M., "About DNS Attacks and ICMP Destination 338 Unreachable Reports", December 2014, 339 . 341 [balakrichenan-dafa888] 342 Balakrichenan, S., "Disturbance in the DNS - "Random 343 qnames", the dafa888 DoS attack"", October 2014, 344 . 347 9.3. URIs 349 [1] https://github.com/bortzmeyer/ietf-dnsop-nxdomain 351 [2] https://www.unbound.net/documentation/unbound.conf.html 353 [3] https://doc.powerdns.com/md/recursor/settings/#root-nx-trust 355 Appendix A. Why can't we just use the owner name of the returned SOA? 357 In this document, we deduce the non-existence of a domain only for 358 NXDOMAIN answers where the denied name was this exact domain. If a 359 resolver sends a query to the name servers of the TLD example, and 360 asks the MX record for www.foobar.example, and receives a NXDOMAIN, 361 it can only register the fact that www.foobar.example (and everything 362 underneath) does not exist. Even if the accompanying SOA record is 363 for example only, one cannot infer that foobar.example is 364 nonexistent. The accompanying SOA indicates the apex of the zone, 365 not the closest existing domain name. 367 RFC-EDITOR: REMOVE BEFORE PUBLICATION: to use a real example today, 368 ask the authoritative name servers of the TLD fr about 369 anything.which.does.not.exist.gouv.fr. The SOA will indicate fr (the 370 apex) even while gouv.fr does exist (there is no zone cut between 371 gouv.fr and fr). 373 Deducing the non-existence of a node from the SOA in the NXDOMAIN 374 reply may certainly help with random qnames attacks but this is out- 375 of-scope for this document. It would require to address the problems 376 mentioned in the first paragraph of this section. A possible 377 solution would be, when receiving a NXDOMAIN with a SOA which is more 378 than one label up in the tree, to send requests for the domains which 379 are between the QNAME and the owner name of the SOA. (A resolver 380 which does DNSSEC validation or QNAME minimisation will need to do 381 it, anyway.) 383 Appendix B. Related approaches 385 The document [I-D.fujiwara-dnsop-nsec-aggressiveuse] describes 386 another way to address some of the same concerns (decreasing the 387 traffic for non-existing domain names). Unlike NXDOMAIN cut, it 388 requires DNSSEC but it is more powerful since it can synthetize 389 NXDOMAINs for domains that were not queried. 391 Authors' Addresses 393 Stephane Bortzmeyer 394 AFNIC 395 1, rue Stephenson 396 Montigny-le-Bretonneux 78180 397 France 399 Phone: +33 1 39 30 83 46 400 Email: bortzmeyer+ietf@nic.fr 401 URI: http://www.afnic.fr/ 403 Shumon Huque 404 Verisign labs 405 12061 Bluemont Way 406 Reston 20190 407 USA 409 Email: shuque@verisign.com 410 URI: http://www.verisignlabs.com/