idnits 2.17.1 draft-ietf-dnsop-nsec-ttl-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 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 (13 January 2021) is 1192 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) 13 January 2021 5 Intended status: Standards Track 6 Expires: 17 July 2021 8 NSEC(3) TTLs and NSEC Aggressive Use 9 draft-ietf-dnsop-nsec-ttl-00 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 17 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 . . . . . . . . . . . . . . . . . . . . . . . . 7 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 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, NoData NOERROR) 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 ".example" with a SOA like 130 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 NSEC3s 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 MUST have the same TTL value as the minimum 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 MUST be the same TTL value as the 175 | minimum 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 MUST have the same TTL value as the minimum 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 four documents, it would have been preferable to 196 update it in 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 of the 204 SOA.MINIMUM field and the SOA TTL" because the resolver may not have 205 the SOA RRset in cache. Because of that, this document cannot get 206 away with updating just [RFC8198]. However, if authoritative servers 207 follow the updates from this document, this should not make a 208 difference, as the TTL of the NSEC/NSEC3 record is already set to the 209 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 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 244 Security (DNSSEC) Hashed Authenticated Denial of 245 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 246 . 248 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 249 Rose, "Protocol Modifications for the DNS Security 250 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 251 . 253 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 254 Requirement Levels", BCP 14, RFC 2119, 255 DOI 10.17487/RFC2119, March 1997, 256 . 258 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 259 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, 260 . 262 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 263 Rose, "Resource Records for the DNS Security Extensions", 264 RFC 4034, DOI 10.17487/RFC4034, March 2005, 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) . 291 Appendix B. Document history 293 [RFC editor: please remove this section before publication.] 295 From draft-vandijk-dnsop-nsec-ttl-00 to draft-ietf-dnsop-nsec-ttl-00: 297 * document was adopted 299 * various minor editorial changes 301 * now also updates 4035 303 * use .example instead of .com for the example 305 * more words on 8198 307 * a note on wildcards 309 Acknowledgements 311 Ralph Dolmans helpfully pointed out that fixing this in RFC8198 is 312 only possible for negative (NXDOMAIN/NoData NOERROR) responses, and 313 not for wildcard responses. Warren Kumari gracefully acknowledged 314 that the current behaviour of RFC8198, in context of the NSEC TTL 315 defined in RFC4034, is not the intended behaviour. Matthijs Mekking 316 provided additional text explaining why this document cannot simply 317 update RFC8198. Vladimir Cunat pointed out that the effect wildcards 318 should be made explicit. 320 Author's Address 322 Peter van Dijk 323 PowerDNS 324 Den Haag 325 Netherlands 327 Email: peter.van.dijk@powerdns.com