RFC 9077

NSEC and NSEC3: TTLs and Aggressive Use

📅 published July 2021, from ietf

RFC 9077: NSEC and NSEC3: TTLs and Aggressive Use ✨

okay bestie, let's get into this one 💖 it's RFC 9077, written by P. van Dijk from PowerDNS and published in July 2021 by the Internet Engineering Task Force (IETF) 🌸. It's a Standards Track document, which means it's an actual Internet Standard and not just a suggestion. It updates RFC 4034, RFC 4035, RFC 5155, and RFC 8198 🎀. The ISSN is 2070-1721 ⭐. Its official number is 9077, which is the only number that matters for citing it 💅.

Abstract

okay so the main drama here is that some older documents were worded in a way that makes aggressive use of NSEC and NSEC3 records able to deny that names exist for way longer than anyone meant them to 😭. A denial is supposed to be short-lived, and it's giving "lingering ex" energy. This document changes how the NSEC and NSEC3 TTL is defined to fix that 🦋. It updates RFCs 4034, 4035, 5155, and 8198 💜.

Status of This Memo

this is an Internet Standards Track document 🌈.

it's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community ✨. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 💅. if you want more info about Internet Standards, check out Section 2 of RFC 7841 🍓.

all the current status info, any errata, and how to send feedback can be found at https://www.rfc-editor.org/info/rfc9077 🧚.

okay the legal bit, but make it cute 🎀. the copyright is (c) 2021 IETF Trust and the persons identified as the document authors, and all rights are reserved 💜.

this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can read at https://trustee.ietf.org/license-info as they were on the publication date ⭐. please actually read them, because they explain your rights and restrictions for this document 🙈. any Code Components pulled out of this document have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License 🫶.

Table of Contents

   1.  Introduction
   2.  Conventions and Definitions
   3.  NSEC and NSEC3 TTL Changes
     3.1.  Updates to RFC 4034
     3.2.  Updates to RFC 4035
     3.3.  Updates to RFC 5155
     3.4.  Updates to RFC 8198
   4.  Zone Operator Considerations
     4.1.  A Note on Wildcards
   5.  Security Considerations
   6.  IANA Considerations
   7.  Normative References
   Acknowledgements
   Author's Address

1. Introduction ✨

okay so [RFC2308] defines the TTL of the Start of Authority (SOA) record that has to show up in negative answers (NXDOMAIN or NODATA) 🌸. here's what it says:

The TTL of this record is set from the minimum of the MINIMUM field of the SOA record and the TTL of the SOA itself, and indicates how long a resolver may cache the negative answer.

so if the SOA's TTL in the zone is lower than the SOA MINIMUM value (the last number in the SOA record), the authoritative server sends that lower value as the TTL of the returned SOA record 🦋. the resolver always uses the TTL of the returned SOA record when it sets the negative TTL in its cache 💅.

but here's the plot twist 😭. [RFC4034], Section 4 has this unfortunate text:

The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL field. This is in the spirit of negative caching ([RFC2308]).

even though it cites RFC 2308, this text can give NSEC records a way higher TTL than the right negative TTL for a zone 💀. [RFC5155] has equivalent text 🙈.

[RFC8198], Section 5.4 tries to fix it 🎀:

Section 5 of [RFC2308] also states that a negative cache entry TTL is taken from the minimum of the SOA.MINIMUM field and SOA's TTL. This can be less than the TTL of an NSEC or NSEC3 record, since their TTL is equal to the SOA.MINIMUM field (see [RFC4035], Section 2.3 and [RFC5155], Section 3). A resolver that supports aggressive use of NSEC and NSEC3 SHOULD reduce the TTL of NSEC and NSEC3 records to match the SOA.MINIMUM field in the authority section of a negative response, if SOA.MINIMUM is smaller.

but wait, the NSEC and NSEC3 RRs should, according to [RFC4034] and [RFC5155], already be at the MINIMUM field value of the SOA 🤔. so the advice from [RFC8198] wouldn't actually change the TTL used for NSEC and NSEC3 RRs for authoritative servers that follow the RFCs 🙃.

as a theoretical exercise (it's giving thought experiment 🧚), picture a top-level domain (TLD) called .example with an SOA record like this:

example.    900 IN  SOA primary.example. dnsadmin.example. (
                                         1 1800 900 604800 86400 )

that SOA has a 900-second TTL and an 86400-second MINIMUM TTL 🌈. negative responses from this zone get a 900-second TTL, but the NSEC or NSEC3 records in those responses get an 86400-second TTL 😱. if a resolver used those NSEC or NSEC3 records aggressively, they'd be treated as valid for a whole day instead of the intended 15 minutes 💅.

2. Conventions and Definitions 🎀

the BCP 14 key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be read as described in BCP 14 [RFC2119] [RFC8174] only when they show up in all capitals, just like they do here 💜. that's the rule, so keep an eye on the caps 👀.

3. NSEC and NSEC3 TTL Changes 🦋

[RFC4034], [RFC4035], and [RFC5155] use the SHOULD requirement level 💖, but they were written before [RFC8198] came out. at that point, [RFC4035] still said:

However, it seems prudent for resolvers to avoid blocking new authoritative data or synthesizing new data on their own.

[RFC8198] updated that text to say:

...DNSSEC-enabled validating resolvers SHOULD use wildcards and NSEC/NSEC3 resource records to generate positive and negative responses until the effective TTLs or signatures for those records expire.

so the correctness of NSEC and NSEC3 records and their TTLs matters way more now 😭. because of that, the updates in this document upgrade the requirement level to MUST 🔥.

3.1. Updates to RFC 4034 🌸

[RFC4034] says:

The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL field. This is in the spirit of negative caching ([RFC2308]).

and that gets updated to say:

The TTL of the NSEC RR that is returned MUST be the lesser of the MINIMUM field of the SOA record and the TTL of the SOA itself. This matches the definition of the TTL for negative responses in [RFC2308]. Because some signers incrementally update the NSEC chain, a transient inconsistency between the observed and expected TTL MAY exist.

3.2. Updates to RFC 4035 🧚

[RFC4035] says:

The TTL value for any NSEC RR SHOULD be the same as the minimum TTL value field in the zone SOA RR.

and this is updated to say:

The TTL of the NSEC RR that is returned MUST be the lesser of the MINIMUM field of the SOA record and the TTL of the SOA itself. This matches the definition of the TTL for negative responses in [RFC2308]. Because some signers incrementally update the NSEC chain, a transient inconsistency between the observed and expected TTL MAY exist.

3.3. Updates to RFC 5155 🍓

[RFC5155] says:

The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL field. This is in the spirit of negative caching [RFC2308].

which gets updated to say:

The TTL of the NSEC3 RR that is returned MUST be the lesser of the MINIMUM field of the SOA record and the TTL of the SOA itself. This matches the definition of the TTL for negative responses in [RFC2308]. Because some signers incrementally update the NSEC3 chain, a transient inconsistency between the observed and expected TTL MAY exist.

also, where [RFC5155] says:

* The TTL value for any NSEC3 RR SHOULD be the same as the minimum TTL value field in the zone SOA RR.

this is updated to say:

* The TTL value for each NSEC3 RR MUST be the lesser of the MINIMUM field of the zone SOA RR and the TTL of the zone SOA RR itself. Because some signers incrementally update the NSEC3 chain, a transient inconsistency between the observed and expected TTL MAY exist.

3.4. Updates to RFC 8198 💜

[RFC8198], Section 5.4 ("Consideration on TTL") gets completely replaced by the following text 🎀:

The TTL value of negative information is especially important, because newly added domain names cannot be used while the negative information is effective. Section 5 of [RFC2308] suggests a maximum default negative cache TTL value of 3 hours (10800). It is RECOMMENDED that validating resolvers limit the maximum effective TTL value of negative responses (NSEC/NSEC3 RRs) to this same value. A resolver that supports aggressive use of NSEC and NSEC3 MAY limit the TTL of NSEC and NSEC3 records to the lesser of the SOA.MINIMUM field and the TTL of the SOA in a response, if present. It MAY also use a previously cached SOA for a zone to find these values.

(The third paragraph of the original is removed, and the fourth paragraph is updated to allow resolvers to also take the lesser of the SOA TTL and SOA MINIMUM.)

4. Zone Operator Considerations 🌈

if the signers and DNS servers for a zone can't be updated right away to match this document, zone operators are encouraged to consider setting their SOA record TTL and the SOA MINIMUM field to the same value 🫶. that way, the TTL used for aggressive NSEC and NSEC3 use matches the SOA TTL for negative responses ✨.

Note that some signers might use the SOA TTL or MINIMUM as a default for other values, such as the TTL for DNSKEY records. Operators should consult documentation before changing values.

so yeah, read your signer's docs before you change anything 🙈.

4.1. A Note on Wildcards 🦋

validating resolvers consider an expanded wildcard valid for the wildcard's TTL, capped by the TTLs of the NSEC or NSEC3 proof that shows the wildcard expansion is legal 💅. so changing the TTL of NSEC or NSEC3 records (explicitly, or implicitly by implementing this document) might affect (shorten) the lifetime of wildcards 😭.

🦋 part 1 ends here 🦋 part 2 (Security Considerations, IANA Considerations, and the references) is coming next bestie ✨

7. Normative References ✨

okay bestie, here's the reading list for this one 📚 these are the documents the spec leans on, and you need them to make sense of it 💅

Acknowledgements

this doc wouldn't exist without these amazing people 🫶 huge thanks to all of them:

  • Ralph Dolmans 🌸
  • Warren Kumari 🦋
  • Matthijs Mekking 💜
  • Vladimir Cunat ✨
  • Matt Nordhoff 🎀
  • Josh Soref 🧚
  • Tim Wicinski 👑

and the author wants to give a MAJOR shoutout to Paul Hoffman 😭💖 for the extensive reviews, text contributions, and help in navigating WG comments. literally the MVP 🏆

Author's Address

Peter van Dijk
PowerDNS
Den Haag
Netherlands

Email: peter.van.dijk@powerdns.com

and that's a wrap on RFC 9077 🦋💅 you did amazing, bestie 🌈

📦 where this page comes from