idnits 2.17.00 (12 Aug 2021) /tmp/idnits8371/draft-ietf-dnsop-nsec-ttl-03.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 RFC8198, but the abstract doesn't seem to directly say this. It does mention RFC8198 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 RFC4034, updated by this document, for RFC5378 checks: 2002-02-26) -- 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 (9 February 2021) is 465 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 (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsop P. van Dijk 3 Internet-Draft PowerDNS 4 Updates: 4034, 4035, 5155, 8198 (if approved) 9 February 2021 5 Intended status: Standards Track 6 Expires: 13 August 2021 8 NSEC and NSEC3 TTLs and NSEC Aggressive Use 9 draft-ietf-dnsop-nsec-ttl-03 11 Abstract 13 Due to a combination of unfortunate wording in earlier documents, 14 aggressive use of NSEC and NSEC3 records may deny names far beyond 15 the intended lifetime of a denial. This document changes the 16 definition of the NSEC and NSEC3 TTL to correct that situation. This 17 document updates RFC 4034, RFC 4035, RFC 5155, and RFC 8198. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 13 August 2021. 36 Copyright Notice 38 Copyright (c) 2021 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 54 3. NSEC and NSEC3 TTL changes . . . . . . . . . . . . . . . . . 4 55 3.1. Updates to RFC4034 . . . . . . . . . . . . . . . . . . . 4 56 3.2. Updates to RFC4035 . . . . . . . . . . . . . . . . . . . 4 57 3.3. Updates to RFC5155 . . . . . . . . . . . . . . . . . . . 5 58 3.4. Updates to RFC8198 . . . . . . . . . . . . . . . . . . . 5 59 3.5. A note on incremental signers . . . . . . . . . . . . . . 6 60 4. Zone Operator Considerations . . . . . . . . . . . . . . . . 6 61 4.1. A Note On Wildcards . . . . . . . . . . . . . . . . . . . 6 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 65 8. Informative References . . . . . . . . . . . . . . . . . . . 7 66 Appendix A. Implementation Status . . . . . . . . . . . . . . . 7 67 Appendix B. Document history . . . . . . . . . . . . . . . . . . 8 68 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 71 1. Introduction 73 [RFC editor: please remove this block before publication. 75 Earlier notes on this: 77 * https://indico.dns-oarc.net/event/29/sessions/98/#20181013 78 (https://indico.dns-oarc.net/event/29/sessions/98/#20181013) 80 * https://lists.dns-oarc.net/pipermail/dns-operations/2018-April/ 81 thread.html#17420 (https://lists.dns-oarc.net/pipermail/dns- 82 operations/2018-April/thread.html#17420) 84 * https://lists.dns-oarc.net/pipermail/dns- 85 operations/2018-March/017416.html (https://lists.dns- 86 oarc.net/pipermail/dns-operations/2018-March/017416.html) 88 This document lives on GitHub (https://github.com/PowerDNS/draft- 89 dnsop-nsec-ttl); proposed text and editorial changes are very much 90 welcomed there, but any functional changes should always first be 91 discussed on the IETF DNSOP WG mailing list. 93 ] 95 [RFC2308] defines the TTL of the SOA record that must be returned in 96 negative answers (NXDOMAIN or NODATA): 98 | The TTL of this record is set from the minimum of the MINIMUM 99 | field of the SOA record and the TTL of the SOA itself, and 100 | indicates how long a resolver may cache the negative answer. 102 Thus, if the TTL of the SOA in the zone is lower than the SOA MINIMUM 103 value (the last number in the SOA record), the authoritative server 104 sends that lower value as the TTL of the returned SOA record. The 105 resolver always uses the TTL of the returned SOA record when setting 106 the negative TTL in its cache. 108 However, [RFC4034] section 4 has this unfortunate text: 110 | The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL 111 | field. This is in the spirit of negative caching ([RFC2308]). 113 This text, while referring to RFC2308, can cause NSEC records to have 114 much higher TTLs than the appropriate negative TTL for a zone. 115 [RFC5155] contains equivalent text. 117 [RFC8198] section 5.4 tries to correct this: 119 | Section 5 of [RFC2308] also states that a negative cache entry TTL 120 | is taken from the minimum of the SOA.MINIMUM field and SOA's TTL. 121 | This can be less than the TTL of an NSEC or NSEC3 record, since 122 | their TTL is equal to the SOA.MINIMUM field (see [RFC4035], 123 | Section 2.3 and [RFC5155], Section 3). 124 | 125 | A resolver that supports aggressive use of NSEC and NSEC3 SHOULD 126 | reduce the TTL of NSEC and NSEC3 records to match the SOA.MINIMUM 127 | field in the authority section of a negative response, if 128 | SOA.MINIMUM is smaller. 130 But the NSEC and NSEC3 RRs should, according to RFC4034 and RFC5155, 131 already be at the value of the MINIMUM field in the SOA. Thus, the 132 advice from RFC8198 would not actually change the TTL used for the 133 NSEC and NSEC3 RRs for authoritative servers that follow the RFCs. 135 As a theoretical exercise, consider a TLD named ".example" with a SOA 136 record like this: 138 "example. 900 IN SOA primary.example. hostmaster.example. 1 1800 900 139 604800 86400" 140 The SOA record has a 900 second TTL, and a 86400 MINIMUM TTL. 141 Negative responses from this zone have a 900 second TTL, but the NSEC 142 or NSEC3 records in those negative responses have a 86400 TTL. If a 143 resolver were to use those NSEC or NSEC3 records aggressively, they 144 would be considered valid for a day, instead of the intended 15 145 minutes. 147 2. Conventions and Definitions 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 151 "OPTIONAL" in this document are to be interpreted as described in BCP 152 14 [RFC2119] [RFC8174] when, and only when, they appear in all 153 capitals, as shown here. 155 3. NSEC and NSEC3 TTL changes 157 3.1. Updates to RFC4034 159 Where [RFC4034] says: 161 | The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL 162 | field. This is in the spirit of negative caching ([RFC2308]). 164 This is updated to say: 166 | The TTL of the NSEC RR that is returned MUST be the lesser of the 167 | MINIMUM field of the SOA record and the TTL of the SOA itself. 168 | This matches the definition of the TTL for negative responses in 169 | [RFC2308]. 171 3.2. Updates to RFC4035 173 Where [RFC4035] says: 175 | The TTL value for any NSEC RR SHOULD be the same as the minimum 176 | TTL value field in the zone SOA RR. 178 This is updated to say: 180 | The TTL of the NSEC RR that is returned MUST be the lesser of the 181 | MINIMUM field of the SOA record and the TTL of the SOA itself. 182 | This matches the definition of the TTL for negative responses in 183 | [RFC2308]. 185 3.3. Updates to RFC5155 187 Where [RFC5155] says: 189 | The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL 190 | field. This is in the spirit of negative caching [RFC2308]. 192 This is updated to say: 194 | The TTL of the NSEC3 RR that is returned MUST be the lesser of the 195 | MINIMUM field of the SOA record and the TTL of the SOA itself. 196 | This matches the definition of the TTL for negative responses in 197 | [RFC2308]. 199 Where [RFC5155] says: 201 | o The TTL value for any NSEC3 RR SHOULD be the same as the minimum 202 | TTL value field in the zone SOA RR. 204 This is updated to say: 206 | o The TTL value for each NSEC3 RR MUST be the lesser of the 207 | MINIMUM field of the zone SOA RR and the TTL of the zone SOA RR 208 | itself. 210 3.4. Updates to RFC8198 212 [RFC8198] section 5.4 (Consideration on TTL) is completely replaced 213 by the following text: 215 | The TTL value of negative information is especially important, 216 | because newly added domain names cannot be used while the negative 217 | information is effective. 218 | 219 | Section 5 of [RFC2308] suggests a maximum default negative cache 220 | TTL value of 3 hours (10800). It is RECOMMENDED that validating 221 | resolvers limit the maximum effective TTL value of negative 222 | responses (NSEC/NSEC3 RRs) to this same value. 223 | 224 | A resolver that supports aggressive use of NSEC and NSEC3 MAY 225 | limit the TTL of NSEC and NSEC3 records to the lesser of the 226 | SOA.MINIMUM field and the TTL of the SOA in a response, if 227 | present. It MAY also use a previously cached SOA for a zone to 228 | find these values. 230 (The third paragraph of the original is removed, and the fourth 231 paragraph is updated to allow resolvers to also take the lesser of 232 the SOA TTL and SOA MINIMUM.) 234 3.5. A note on incremental signers 236 Some DNSSEC signer implementations might not (re-)sign whole zones in 237 one go, instead spreading the work of updating inception/expiration 238 times over some period. Such implementations would not be able to 239 update all NSEC or NSEC3 records in the zone instantly either. To 240 aid these implementations, we additionally specify the following: 242 | If an implementation cannot update all NSEC or NSEC3 TTLs after a 243 | SOA change immediately, it MUST still attempt to do so as soon as 244 | possible during the signing process. 246 4. Zone Operator Considerations 248 If signers & DNS servers for a zone cannot immediately be updated to 249 conform to this document, zone operators are encouraged to consider 250 setting their SOA record TTL and the SOA MINIMUM field to the same 251 value. That way, the TTL used for aggressive NSEC and NSEC3 use 252 matches the SOA TTL for negative responses. 254 4.1. A Note On Wildcards 256 Validating resolvers consider an expanded wildcard valid for the 257 wildcard's TTL, capped by the TTLs of the NSEC and NSEC3 proof that 258 shows that the wildcard expansion is legal. Thus, changing the TTL 259 of NSEC or NSEC3 records (explicitly, or by implementation of this 260 document, implicitly) might affect (shorten) the lifetime of 261 wildcards. 263 5. Security Considerations 265 An attacker can prevent future records from appearing in a cache by 266 seeding the cache with queries that cause NSEC or NSEC3 responses to 267 be cached, for aggressive use purposes. This document reduces the 268 impact of that attack in cases where the NSEC or NSEC3 TTL is higher 269 than the zone operator intended. 271 6. IANA Considerations 273 IANA is requested to add a reference to this document in the 274 "Resource Record (RR) TYPEs" subregistry of the "Domain Name System 275 (DNS) Parameters" registry, for the NSEC and NSEC3 types. 277 7. Normative References 279 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 280 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, 281 . 283 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 284 Rose, "Resource Records for the DNS Security Extensions", 285 RFC 4034, DOI 10.17487/RFC4034, March 2005, 286 . 288 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 289 Security (DNSSEC) Hashed Authenticated Denial of 290 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 291 . 293 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of 294 DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, 295 July 2017, . 297 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 298 Rose, "Protocol Modifications for the DNS Security 299 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 300 . 302 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 303 Requirement Levels", BCP 14, RFC 2119, 304 DOI 10.17487/RFC2119, March 1997, 305 . 307 8. Informative References 309 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 310 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 311 May 2017, . 313 Appendix A. Implementation Status 315 [RFC Editor: please remove this section before publication] 317 Implemented in PowerDNS Authoritative Server 4.3.0 318 https://doc.powerdns.com/authoritative/dnssec/ 319 operational.html?highlight=ttl#some-notes-on-ttl-usage 320 (https://doc.powerdns.com/authoritative/dnssec/ 321 operational.html?highlight=ttl#some-notes-on-ttl-usage) . 323 Implemented in BIND 9.16 and up, to be released early 2021 324 https://mailarchive.ietf.org/arch/msg/dnsop/ga41J2PPUbmc21-- 325 dqf3i7_IY6M (https://mailarchive.ietf.org/arch/msg/dnsop/ 326 ga41J2PPUbmc21--dqf3i7_IY6M) https://gitlab.isc.org/isc-projects/ 327 bind9/-/merge_requests/4506 (https://gitlab.isc.org/isc-projects/ 328 bind9/-/merge_requests/4506) . 330 Implemented in Knot DNS 3.1, to be released in 2021 331 https://gitlab.nic.cz/knot/knot-dns/-/merge_requests/1219 332 (https://gitlab.nic.cz/knot/knot-dns/-/merge_requests/1219) . 334 Implemented in ldns, patch under review 335 https://github.com/NLnetLabs/ldns/pull/118 336 (https://github.com/NLnetLabs/ldns/pull/118) 338 Implementation status is tracked at 339 https://trac.ietf.org/trac/dnsop/wiki/draft-ietf-dnsop-nsec-ttl 340 (https://trac.ietf.org/trac/dnsop/wiki/draft-ietf-dnsop-nsec-ttl) 342 Appendix B. Document history 344 [RFC editor: please remove this section before publication.] 346 From draft-vandijk-dnsop-nsec-ttl-00 to draft-ietf-dnsop-nsec-ttl-00: 348 * document was adopted 350 * various minor editorial changes 352 * now also updates 4035 354 * use .example instead of .com for the example 356 * more words on 8198 358 * a note on wildcards 360 From draft-ietf-dnsop-nsec-ttl-00 to draft-ietf-dnsop-nsec-ttl-01: 362 * various wording improvements 364 * added Implementation note from Knot, expanded the BIND one with 365 the GitLab MR URL 367 * reduced requirement level from MUST to SHOULD, like the original 368 texts 370 From draft-ietf-dnsop-nsec-ttl-01 to draft-ietf-dnsop-nsec-ttl-02: 372 * updated the second bit of wrong text in 5155 374 From draft-ietf-dnsop-nsec-ttl-02 to draft-ietf-dnsop-nsec-ttl-03: 376 * document now updates resolver behaviour in 8198 377 * lots of extra text to clarify what behaviour goes where (thanks 378 Paul Hoffman) 380 * replace 'any' with 'each' (thanks Duane) 382 * upgraded requirement level to MUST, plus a note on incremental 383 signers 385 Acknowledgements 387 This document was made possible with the help of the following 388 people: 390 * Ralph Dolmans 392 * Warren Kumari 394 * Matthijs Mekking 396 * Vladimir Cunat 398 * Matt Nordhoff 400 * Josh Soref 402 * Tim Wicinski 404 The author would like to explicitly thank Paul Hoffman for extensive 405 reviews, text contributions, and help in navigating WG comments. 407 Author's Address 409 Peter van Dijk 410 PowerDNS 411 Den Haag 412 Netherlands 414 Email: peter.van.dijk@powerdns.com