idnits 2.17.00 (12 Aug 2021) /tmp/idnits7402/draft-ietf-dnsop-nsec-ttl-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 draft header indicates that this document updates RFC5155, but the abstract doesn't seem to directly say this. It does mention RFC5155 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 (29 January 2021) is 476 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 (if approved) 29 January 2021 5 Intended status: Standards Track 6 Expires: 2 August 2021 8 NSEC(3) TTLs and NSEC Aggressive Use 9 draft-ietf-dnsop-nsec-ttl-02 11 Abstract 13 Due to a combination of unfortunate wording in earlier documents, 14 aggressive use of NSEC(3) records may deny names far beyond the 15 intended lifetime of a denial. This document changes the definition 16 of the NSEC(3) TTL to correct that situation. This document updates 17 RFC 4034, RFC 4035, and RFC 5155. 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 2 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(3) TTL changes . . . . . . . . . . . . . . . . . . . . . 4 55 3.1. Updates to RFC4034 . . . . . . . . . . . . . . . . . . . 4 56 3.2. Updates to RFC4035 . . . . . . . . . . . . . . . . . . . 4 57 3.3. Updates to RFC5155 . . . . . . . . . . . . . . . . . . . 4 58 3.4. No updates to RFC8198 . . . . . . . . . . . . . . . . . . 5 59 4. Zone Operator Considerations . . . . . . . . . . . . . . . . 5 60 4.1. A Note On Wildcards . . . . . . . . . . . . . . . . . . . 6 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 64 8. Informative References . . . . . . . . . . . . . . . . . . . 7 65 Appendix A. Implementation Status . . . . . . . . . . . . . . . 7 66 Appendix B. Document history . . . . . . . . . . . . . . . . . . 7 67 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 [RFC editor: please remove this block before publication. 74 Earlier notes on this: 76 * https://indico.dns-oarc.net/event/29/sessions/98/#20181013 77 (https://indico.dns-oarc.net/event/29/sessions/98/#20181013) 79 * https://lists.dns-oarc.net/pipermail/dns-operations/2018-April/ 80 thread.html#17420 (https://lists.dns-oarc.net/pipermail/dns- 81 operations/2018-April/thread.html#17420) 83 * https://lists.dns-oarc.net/pipermail/dns- 84 operations/2018-March/017416.html (https://lists.dns- 85 oarc.net/pipermail/dns-operations/2018-March/017416.html) 87 This document lives on GitHub (https://github.com/PowerDNS/draft- 88 dnsop-nsec-ttl); proposed text and editorial changes are very much 89 welcomed there, but any functional changes should always first be 90 discussed on the IETF DNSOP WG mailing list. 92 ] 94 [RFC2308] defines that the SOA TTL to be used in negative answers 95 (NXDOMAIN or NODATA) is 96 | the minimum of the MINIMUM field of the SOA record and the TTL of 97 | the SOA itself 99 Thus, if the TTL of the SOA in the zone is lower than the SOA MINIMUM 100 value (the last number in a SOA record), the negative TTL for that 101 zone is lower than the SOA MINIMUM value. 103 However, [RFC4034] section 4 has this unfortunate text: 105 | The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL 106 | field. This is in the spirit of negative caching ([RFC2308]). 108 This text, while referring to RFC2308, can cause NSEC records to have 109 much higher TTLs than the appropriate negative TTL for a zone. 110 [RFC5155] contains equivalent text. 112 [RFC8198] section 5.4 tries to correct this: 114 | Section 5 of [RFC2308] also states that a negative cache entry TTL 115 | is taken from the minimum of the SOA.MINIMUM field and SOA's TTL. 116 | This can be less than the TTL of an NSEC or NSEC3 record, since 117 | their TTL is equal to the SOA.MINIMUM field (see [RFC4035], 118 | Section 2.3 and [RFC5155], Section 3). 119 | 120 | A resolver that supports aggressive use of NSEC and NSEC3 SHOULD 121 | reduce the TTL of NSEC and NSEC3 records to match the SOA.MINIMUM 122 | field in the authority section of a negative response, if 123 | SOA.MINIMUM is smaller. 125 But the NSEC(3) RRs should, per RFC4034, already be at the MINIMUM 126 TTL, which means this advice would never actually change the TTL used 127 for the NSEC(3) RRs. 129 As a theoretical exercise, consider a TLD named ".example" with a SOA 130 record like this: 132 "example. 900 IN SOA primary.example. hostmaster.example. 1 1800 900 133 604800 86400" 135 The SOA record has a 900 second TTL, and a 86400 MINIMUM TTL. 136 Negative responses from this zone have a 900 second TTL, but the 137 NSEC(3) records in those negative responses have a 86400 TTL. If a 138 resolver were to use those NSEC(3)s aggressively, they would be 139 considered valid for a day, instead of the intended 15 minutes. 141 2. Conventions and Definitions 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in BCP 146 14 [RFC2119] [RFC8174] when, and only when, they appear in all 147 capitals, as shown here. 149 3. NSEC(3) TTL changes 151 3.1. Updates to RFC4034 153 Where [RFC4034] says: 155 | The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL 156 | field. This is in the spirit of negative caching ([RFC2308]). 158 This is updated to say: 160 | The NSEC RR SHOULD have the same TTL value as the lesser of the 161 | MINIMUM field of the SOA record and the TTL of the SOA itself. 162 | This matches the definition of the TTL for negative responses in 163 | [RFC2308]. 165 3.2. Updates to RFC4035 167 Where [RFC4035] says: 169 | The TTL value for any NSEC RR SHOULD be the same as the minimum 170 | TTL value field in the zone SOA RR. 172 This is updated to say: 174 | The TTL value for any NSEC RR SHOULD be the same TTL value as the 175 | lesser of the MINIMUM field of the SOA record and the TTL of the 176 | SOA itself. This matches the definition of the TTL for negative 177 | responses in [RFC2308]. 179 3.3. Updates to RFC5155 181 Where [RFC5155] says: 183 | The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL 184 | field. This is in the spirit of negative caching [RFC2308]. 186 This is updated to say: 188 | The NSEC3 RR SHOULD have the same TTL value as the lesser of the 189 | MINIMUM field of the SOA record and the TTL of the SOA itself. 190 | This matches the definition of the TTL for negative responses in 191 | [RFC2308]. 193 Where [RFC5155] says: 195 | o The TTL value for any NSEC3 RR SHOULD be the same as the minimum 196 | TTL value field in the zone SOA RR. 198 This is updated to say: 200 | o The TTL value for any NSEC3 RR SHOULD be the same as the lesser 201 | of the MINIMUM field of the zone SOA RR and the TTL of the zone 202 | SOA RR itself. 204 3.4. No updates to RFC8198 206 Instead of updating three documents, it would have been preferable to 207 update one. [RFC8198] says: 209 | With DNSSEC and aggressive use of DNSSEC-validated cache, the TTL 210 | of the NSEC/NSEC3 record and the SOA.MINIMUM field are the 211 | authoritative statement of how quickly a name can start working 212 | within a zone. 214 Here, the SOA.MINIMUM field cannot be changed to "the minimum/lesser 215 of the SOA.MINIMUM field and the SOA TTL" because the resolver may 216 not have the SOA RRset in cache. Because of that, this document 217 cannot get away with updating just [RFC8198]. However, if 218 authoritative servers follow the updates from this document, this 219 should not make a difference, as the TTL of the NSEC/NSEC3 record is 220 already set to the minimum value. 222 4. Zone Operator Considerations 224 If signers & DNS servers for a zone cannot immediately be updated to 225 conform to this document, zone operators are encouraged to consider 226 setting their SOA record TTL and the SOA MINIMUM field to the same 227 value. That way, the TTL used for aggressive NSEC use matches the 228 SOA TTL for negative responses. 230 4.1. A Note On Wildcards 232 Validating resolvers consider an expanded wildcard valid for the 233 wildcard's TTL, capped by the TTLs of the NSEC(3) proof that shows 234 that the wildcard expansion is legal. Thus, changing the TTL of 235 NSEC(3) records (explicitly, or by implementation of this document, 236 implicitly) might affect (shorten) the lifetime of wildcards. 238 5. Security Considerations 240 An attacker can prevent future records from appearing in a cache by 241 seeding the cache with queries that cause NSEC(3) responses to be 242 cached, for aggressive use purposes. This document reduces the 243 impact of that attack in cases where the NSEC(3) TTL is higher than 244 the zone operator intended. 246 6. IANA Considerations 248 IANA is requested to add a reference to this document in the 249 "Resource Record (RR) TYPEs" subregistry of the "Domain Name System 250 (DNS) Parameters" registry, for the NSEC and NSEC3 types. 252 7. Normative References 254 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 255 Rose, "Protocol Modifications for the DNS Security 256 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 257 . 259 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 260 Requirement Levels", BCP 14, RFC 2119, 261 DOI 10.17487/RFC2119, March 1997, 262 . 264 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 265 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, 266 . 268 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 269 Rose, "Resource Records for the DNS Security Extensions", 270 RFC 4034, DOI 10.17487/RFC4034, March 2005, 271 . 273 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 274 Security (DNSSEC) Hashed Authenticated Denial of 275 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 276 . 278 8. Informative References 280 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 281 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 282 May 2017, . 284 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of 285 DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, 286 July 2017, . 288 Appendix A. Implementation Status 290 [RFC Editor: please remove this section before publication] 292 Implemented in PowerDNS Authoritative Server 4.3.0 293 https://doc.powerdns.com/authoritative/dnssec/ 294 operational.html?highlight=ttl#some-notes-on-ttl-usage 295 (https://doc.powerdns.com/authoritative/dnssec/ 296 operational.html?highlight=ttl#some-notes-on-ttl-usage) . 298 Implemented in BIND 9.16 and up, to be released early 2021 299 https://mailarchive.ietf.org/arch/msg/dnsop/ga41J2PPUbmc21-- 300 dqf3i7_IY6M (https://mailarchive.ietf.org/arch/msg/dnsop/ 301 ga41J2PPUbmc21--dqf3i7_IY6M) https://gitlab.isc.org/isc-projects/ 302 bind9/-/merge_requests/4506 (https://gitlab.isc.org/isc-projects/ 303 bind9/-/merge_requests/4506) . 305 Implemented in Knot DNS 3.1, to be released in 2021 306 https://gitlab.nic.cz/knot/knot-dns/-/merge_requests/1219 307 (https://gitlab.nic.cz/knot/knot-dns/-/merge_requests/1219) . 309 Appendix B. Document history 311 [RFC editor: please remove this section before publication.] 313 From draft-vandijk-dnsop-nsec-ttl-00 to draft-ietf-dnsop-nsec-ttl-00: 315 * document was adopted 317 * various minor editorial changes 319 * now also updates 4035 321 * use .example instead of .com for the example 323 * more words on 8198 325 * a note on wildcards 326 From draft-ietf-dnsop-nsec-ttl-00 to draft-ietf-dnsop-nsec-ttl-01: 328 * various wording improvements 330 * added Implementation note from Knot, expanded the BIND one with 331 the GitLab MR URL 333 * reduced requirement level from MUST to SHOULD, like the original 334 texts 336 Acknowledgements 338 Ralph Dolmans helpfully pointed out that fixing this in RFC8198 is 339 only possible for negative (NXDOMAIN/NODATA) responses, and not for 340 wildcard responses. Warren Kumari gracefully acknowledged that the 341 current behaviour of RFC8198, in context of the NSEC TTL defined in 342 RFC4034, is not the intended behaviour. Matthijs Mekking provided 343 additional text explaining why this document cannot simply update 344 RFC8198. Vladimir Cunat pointed out that the effect on wildcards 345 should be made explicit. Paul Hoffman, Matt Nordhoff, and Josh Soref 346 provided helpful corrections as native speakers. 348 Author's Address 350 Peter van Dijk 351 PowerDNS 352 Den Haag 353 Netherlands 355 Email: peter.van.dijk@powerdns.com