idnits 2.17.1 draft-wkumari-dnsop-cheese-shop-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 24, 2016) is 2984 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-fujiwara-dnsop-nsec-aggressiveuse-02 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Kumari 3 Internet-Draft Google 4 Intended status: Informational G. Huston 5 Expires: August 27, 2016 APNIC 6 February 24, 2016 8 Believing NSEC records in the DNS root. 9 draft-wkumari-dnsop-cheese-shop-01 11 Abstract 13 This document describes a method to generate negative answers from 14 NSEC records for the special case of the DNS root. This improves 15 performance; the resolver can answer immediatly, and does not need to 16 query the root. It also cuts down on the so-called "junk" queries. 18 [ Ed note: Text inside square brackets ([]) is additional background 19 information, answers to frequently asked questions, general musings, 20 etc. They will be removed before publication.] 22 [ This document is being collaborated on in Github at: 23 https://github.com/wkumari/draft-wkumari-dnsop-cheese-shop. The most 24 recent version of the document, open issues, etc should all be 25 available here. The authors (gratefully) accept pull requests ] 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 27, 2016. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Believing NSEC records. . . . . . . . . . . . . . . . . . . . 3 63 2.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 64 3. Generating negatives responses from NSEC . . . . . . . . . . 3 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 70 7.2. Informative References . . . . . . . . . . . . . . . . . 5 71 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 5 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 74 1. Background 76 [ This section may be removed before publication... but I'd prefer 77 not, it provides useful context ] 79 If a DNS resolver queries a root zone authoritative name server with 80 the EDNS0 DNSSEC OK option set, for a name that does not exist in the 81 root zone, it gets back an NXDOMAIN response and an NSEC record, 82 which "proves" that the name does not exist. NSEC proves this by 83 providing names (and signatures) for the names which do exist on 84 either side of the queried name. For example, if a nameserver 85 queries for .belkin, it will get back an NXDOMAIN, and an NSEC record 86 showing that nothing exists between (currently) .beer and .bentley 87 [Ed note: There *probably* should be something between a beer and a 88 bentley. :-P ]. This means that, if the nameserver subsequently 89 (during the TTL of the NSEC record) gets a query for .beeswax 90 (alphabetically between beer and bentley) it need not attempt to 91 resolve this - it has already been given proof that the name does not 92 exist. 94 The title of this draft comes from a famous Monty Python skit - "The 95 Cheese Shop". There are some useful parallels between this problem 96 and the skit - watching the skit is encouraged to understand the 97 problem - https://www.youtube.com/watch?v=cWDdd5KKhts 99 2. Believing NSEC records. 101 This is a simply a refinement of 102 [I-D.fujiwara-dnsop-nsec-aggressiveuse], for a limited use case (the 103 root). Full credit to the authors of the aforementioned draft, and 104 this draft does not replace that draft, nor remove the need for the 105 broader consideration of the use of NSEC records as described in 106 [I-D.fujiwara-dnsop-nsec-aggressiveuse]. 108 The scope of this document is limited to the special case of 109 recursive DNSSEC validating resolvers querying the root zone. This 110 is because the root zone has some well known properties which make it 111 a special case - we know it is DNSSEC signed, and uses NSEC, the 112 majority of the queries are "junk" queries, the rate of change is 113 relatively slow, and there are no odd corner cases such as wildcards. 114 See Section 3 for more discussion. 116 If the (DNSSEC validated) answer to a query to a root server is an 117 NXDOMAIN then the resolver SHOULD cache the NSEC record provided in 118 the response. The resolver SHOULD NOT send further queries for names 119 within the range of the NSEC record for the lifetime of the cached 120 NSEC TTL. Instead, the resolver SHOULD answer these queries directly 121 with NXDOMAIN (and NSEC records if so signalled by EDNS). They 122 SHOULD set the AA bit and AD bits. 124 2.1. Requirements notation 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC2119]. 130 3. Generating negatives responses from NSEC 132 [ This section is mainly for discussion, and is more informal. It 133 should be deleted before publication. ] 135 Section 4.5 of [RFC4035] says: 137 "In theory, a resolver could use wildcards or NSEC RRs to generate 138 positive and negative responses (respectively) until the TTL or 139 signatures on the records in question expire. However, it seems 140 prudent for resolvers to avoid blocking new authoritative data or 141 synthesizing new data on their own. Resolvers that follow this 142 recommendation will have a more consistent view of the namespace." 143 and "The reason for these recommendations is that, between the 144 initial query and the expiration of the data from the cache, the 145 authoritative data might have been changed (for example, via dynamic 146 update)." 148 So, if a resolver generates negative answers from an NSEC record, it 149 will not send any queries for names within that NSEC range (for the 150 TTL). If a new name is added to the zone during this interval the 151 resolver will not know this. 153 For the limited use case of this document (the DNS root) we believe 154 that this is an acceptable trade off - the (current) TTL of the 155 "negative cache" (in the SOA) is the same as the NSEC TTL (1 day). 156 This means that, for a new TLD to begin resolving everywhere will 157 require a minimum of a day - and this is true whether or not this is 158 implemented (if someone had queried for the exact name, there would 159 be a negatively cached answer, this simply expands the range of 160 negative caches). 162 4. IANA Considerations 164 This document contains no IANA considerations. 166 [ We MAY want to add something about setting the NSEC TTL 167 appropriately?! ] 169 5. Security Considerations 171 The impact of resolver caching is that the resolver will not re-query 172 an name server for a cached response until the TTL of the cached 173 response expires. This may lead to cases where the resolver responds 174 with outdated information for a period of time for subsequent queries 175 for the name name. 177 This draft extends the scope of this vulnerability to include queries 178 for all names that fall within the NSEC-defined range. 180 6. Acknowledgements 182 The authors wish to thank some folk, including Stephane Bortzmeyer, 183 Bob Harold, Paul Vixie. 185 7. References 186 7.1. Normative References 188 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 189 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 190 RFC2119, March 1997, 191 . 193 7.2. Informative References 195 [I-D.fujiwara-dnsop-nsec-aggressiveuse] 196 Fujiwara, K. and A. Kato, "Aggressive use of NSEC/NSEC3", 197 draft-fujiwara-dnsop-nsec-aggressiveuse-02 (work in 198 progress), October 2015. 200 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 201 Rose, "Protocol Modifications for the DNS Security 202 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 203 . 205 Appendix A. Changes / Author Notes. 207 [RFC Editor: Please remove this section before publication ] 209 From -00 to -01. 211 o Fairly significant rewrite - no substantive changes, only 212 additional information, explaination and readability. 214 Authors' Addresses 216 Warren Kumari 217 Google 218 1600 Amphitheatre Parkway 219 Mountain View, CA 94043 220 US 222 Email: warren@kumari.net 224 Geoff Huston 225 APNIC 226 6 Cordelia St 227 South Brisbane QLD 4001 228 AUS 230 Email: gih@apnic.net