idnits 2.17.00 (12 Aug 2021) /tmp/idnits8766/draft-ietf-dnsop-nsec-ttl-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 : ---------------------------------------------------------------------------- -- 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 (24 January 2021) is 481 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) 24 January 2021 5 Intended status: Standards Track 6 Expires: 28 July 2021 8 NSEC(3) TTLs and NSEC Aggressive Use 9 draft-ietf-dnsop-nsec-ttl-01 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 28 July 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 . . . . . . . . . . . . . . . . . . . 5 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 64 8. Informative References . . . . . . . . . . . . . . . . . . . 6 65 Appendix A. Implementation Status . . . . . . . . . . . . . . . 6 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 3.4. No updates to RFC8198 195 Instead of updating three documents, it would have been preferable to 196 update one. [RFC8198] says: 198 | With DNSSEC and aggressive use of DNSSEC-validated cache, the TTL 199 | of the NSEC/NSEC3 record and the SOA.MINIMUM field are the 200 | authoritative statement of how quickly a name can start working 201 | within a zone. 203 Here, the SOA.MINIMUM field cannot be changed to "the minimum/lesser 204 of the SOA.MINIMUM field and the SOA TTL" because the resolver may 205 not have the SOA RRset in cache. Because of that, this document 206 cannot get away with updating just [RFC8198]. However, if 207 authoritative servers follow the updates from this document, this 208 should not make a difference, as the TTL of the NSEC/NSEC3 record is 209 already set to the minimum value. 211 4. Zone Operator Considerations 213 If signers & DNS servers for a zone cannot immediately be updated to 214 conform to this document, zone operators are encouraged to consider 215 setting their SOA record TTL and the SOA MINIMUM field to the same 216 value. That way, the TTL used for aggressive NSEC use matches the 217 SOA TTL for negative responses. 219 4.1. A Note On Wildcards 221 Validating resolvers consider an expanded wildcard valid for the 222 wildcard's TTL, capped by the TTLs of the NSEC(3) proof that shows 223 that the wildcard expansion is legal. Thus, changing the TTL of 224 NSEC(3) records (explicitly, or by implementation of this document, 225 implicitly) might affect (shorten) the lifetime of wildcards. 227 5. Security Considerations 229 An attacker can prevent future records from appearing in a cache by 230 seeding the cache with queries that cause NSEC(3) responses to be 231 cached, for aggressive use purposes. This document reduces the 232 impact of that attack in cases where the NSEC(3) TTL is higher than 233 the zone operator intended. 235 6. IANA Considerations 237 IANA is requested to add a reference to this document in the 238 "Resource Record (RR) TYPEs" subregistry of the "Domain Name System 239 (DNS) Parameters" registry, for the NSEC and NSEC3 types. 241 7. Normative References 243 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 244 Rose, "Protocol Modifications for the DNS Security 245 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 246 . 248 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 249 Requirement Levels", BCP 14, RFC 2119, 250 DOI 10.17487/RFC2119, March 1997, 251 . 253 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 254 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, 255 . 257 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 258 Rose, "Resource Records for the DNS Security Extensions", 259 RFC 4034, DOI 10.17487/RFC4034, March 2005, 260 . 262 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 263 Security (DNSSEC) Hashed Authenticated Denial of 264 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 265 . 267 8. Informative References 269 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of 270 DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, 271 July 2017, . 273 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 274 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 275 May 2017, . 277 Appendix A. Implementation Status 279 [RFC Editor: please remove this section before publication] 280 Implemented in PowerDNS Authoritative Server 4.3.0 281 https://doc.powerdns.com/authoritative/dnssec/ 282 operational.html?highlight=ttl#some-notes-on-ttl-usage 283 (https://doc.powerdns.com/authoritative/dnssec/ 284 operational.html?highlight=ttl#some-notes-on-ttl-usage) . 286 Implemented in BIND 9.16 and up, to be released early 2021 287 https://mailarchive.ietf.org/arch/msg/dnsop/ga41J2PPUbmc21-- 288 dqf3i7_IY6M (https://mailarchive.ietf.org/arch/msg/dnsop/ 289 ga41J2PPUbmc21--dqf3i7_IY6M) https://gitlab.isc.org/isc-projects/ 290 bind9/-/merge_requests/4506 (https://gitlab.isc.org/isc-projects/ 291 bind9/-/merge_requests/4506) . 293 Implemented in Knot DNS 3.1, to be released in 2021 294 https://gitlab.nic.cz/knot/knot-dns/-/merge_requests/1219 295 (https://gitlab.nic.cz/knot/knot-dns/-/merge_requests/1219) . 297 Appendix B. Document history 299 [RFC editor: please remove this section before publication.] 301 From draft-vandijk-dnsop-nsec-ttl-00 to draft-ietf-dnsop-nsec-ttl-00: 303 * document was adopted 305 * various minor editorial changes 307 * now also updates 4035 309 * use .example instead of .com for the example 311 * more words on 8198 313 * a note on wildcards 315 From draft-ietf-dnsop-nsec-ttl-00 to draft-ietf-dnsop-nsec-ttl-01: 317 * various wording improvements 319 * added Implementation note from Knot, expanded the BIND one with 320 the GitLab MR URL 322 * reduced requirement level from MUST to SHOULD, like the original 323 texts 325 Acknowledgements 327 Ralph Dolmans helpfully pointed out that fixing this in RFC8198 is 328 only possible for negative (NXDOMAIN/NODATA) responses, and not for 329 wildcard responses. Warren Kumari gracefully acknowledged that the 330 current behaviour of RFC8198, in context of the NSEC TTL defined in 331 RFC4034, is not the intended behaviour. Matthijs Mekking provided 332 additional text explaining why this document cannot simply update 333 RFC8198. Vladimir Cunat pointed out that the effect on wildcards 334 should be made explicit. Paul Hoffman, Matt Nordhoff, and Josh Soref 335 provided helpful corrections as native speakers. 337 Author's Address 339 Peter van Dijk 340 PowerDNS 341 Den Haag 342 Netherlands 344 Email: peter.van.dijk@powerdns.com