RFC 4470

Minimally Covering NSEC Records and DNSSEC On-line Signing

📅 published April 2006, from ietf

Minimally Covering NSEC Records and DNSSEC On-line Signing 💖

Okay bestie, first the vibes check 🎀. This is RFC 4470, from the Network Working Group, published in April 2006. It's on the Standards Track 🔥. The authors are S. Weiler from SPARTA, Inc. and J. Ihren from Autonomica AB 👑. The title block says it updates RFC 4035 and RFC 4034, so it's tweaking those two. It doesn't list anything it obsoletes 🫶.

Status of This Memo 📜

So this is an Internet standards track protocol for the whole Internet community 🌐. It's basically asking everyone for discussion and suggestions for improvements 💬. For the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1) 🧚. And distribution of this memo is unlimited, so share away 🦋.

Copyright (C) The Internet Society (2006).

Abstract 🌈

TL;DR 💅: this doc explains how to build DNSSEC NSEC records that cover a smaller range of names than RFC 4034 calls for. Those records get generated and signed on demand, so authoritative name servers can stop people from seeing the whole zone's contents by walking the chain of NSEC records in a signed zone 🙅‍♀️.

Table of Contents 📚

1. Introduction ....................................................1
2. Applicability of This Technique .................................2
3. Minimally Covering NSEC Records .................................2
4. Better Epsilon Functions ........................................4
5. Security Considerations .........................................5
6. Acknowledgements ................................................6
7. Normative References ............................................6

1. Introduction ✨

Okay so with DNSSEC [1] 🔐, an NSEC record lists the next instantiated name in its zone. That proves there are no names in the "span" between the NSEC's owner name and the name in the "next name" field 🧐. In this doc, we say an NSEC record "covers" the names between its owner name and next name 💅.

Like, if you keep asking for NSEC records, you can literally collect every name in the zone. People call that "walking" the zone 🚶‍♀️. Some zone owners have rules saying random clients can't do zone transfers, and this side effect of the NSEC setup totally undermines those rules 😭.

This doc has a fix 🛡️. Build NSEC records that cover fewer names, and then walking takes about as many queries as just asking for every possible name, so it becomes impractical 🙅‍♀️. The catch is that some records need to be made and signed on demand, which needs on-line private keys. If you're thinking about this, you're strongly encouraged to read the risks of on-line signing in Section 5 💀. Seriously, read it bestie.

1.2. Keywords 🎀

Quick keyword check: the words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document get read the way RFC 2119 [4] describes 📖.

2. Applicability of This Technique 🌸

This technique might be a good fit for a zone owner who wants to use DNSSEC 🌸, is worried about their zone contents leaking through zone walking 😬, and is willing to pay the costs of on-line signing 💸.

As Section 5 covers, on-line signing comes with security risks 🚨. Private keys are more likely to get disclosed, and there's a higher risk of a denial of service attack 😱. Again, if you're considering this, go review the risks of on-line signing in Section 5. It's giving serious.

Also, when this doc came out, the DNSEXT working group was actively cooking up a way to stop zone walking without needing on-line signing 🍳 (tentatively called NSEC3). That newer mechanism will probably expose slightly more about the zone than this technique does, like the number of instantiated names 🔢. But it might still be the better pick over this one 👑.

3. Minimally Covering NSEC Records 🦋

So this mechanism changes NSEC records for instantiated names 🛠️. Those can still be generated and signed ahead of time ⏰. It also means generating and signing brand new NSEC records on demand, whenever a name needs to be proven not to exist.

Here's the glow-up 🦋. In the "next name" field of instantiated names' NSEC records, you don't list the next real name in the zone anymore. Instead, you list any name that sorts lexically after the NSEC's owner name and before the next instantiated name in the zone. The ordering function is the one in RFC 4034 [2] Section 6.1. This loosens the rule in Section 4.1.1 of RFC 4034 that the "next name" field has to contain the next owner name in the zone 🙃. It's expected to be fully compatible with all existing DNSSEC validators ✅. These NSEC records come back whenever you're proving something about the owner name itself (e.g., that no resource records of a given type show up there) 💅.

Whenever you need an NSEC record to prove a name doesn't exist 🫥, a brand new one gets produced and signed on the fly ⚡. Its owner name sorts lexically before the QNAME but after any existing name, and its "next name" sorts lexically after the QNAME but before any existing name 🧚.

Okay, this part is important 🔥. The generated NSEC record's type bitmap MUST have the RRSIG and NSEC bits set, and it SHOULD NOT have any other bits set. This loosens the rule in Section 2.3 of RFC4035 that NSEC RRs can't show up at names that didn't exist before the zone was signed 🙈.

The functions that generate the lexically following and proceeding names don't need to be perfect or consistent 🤷‍♀️. But the generated NSEC records must not cover any existing names. Also, this technique works best when the generated NSEC records cover as few names as possible 💖. In this doc, these nearby-name functions are called "epsilon" functions. That's a nod to the math habit of using the Greek letter epsilon for small deviations 🧮.

An NSEC record denying a wildcard's existence can be generated the same way 🃏. And since the NSEC covering a non-existent wildcard is likely to get used for tons of queries 📈, authoritative name servers using these techniques might want to pregenerate or cache that record and its matching RRSIG 🗂️.

Example time 🎀. A query for an A record at the non-instantiated name example.com might give you these two NSEC records. The first denies that example.com exists, and the second denies that a wildcard exists:

exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC )

\).com 3600 IN NSEC +.com ( RRSIG NSEC )

Before answering a query with these records, an authoritative server MUST test for the existence of names between these endpoints. If the generated NSEC would cover existing names (e.g., exampldd.com or *bizarre.example.com), a better epsilon function may be used. Or the covered name closest to the QNAME could be used as the NSEC owner name or next name, as appropriate. If an existing name is used as the NSEC owner name, that name's real NSEC record MUST be returned. Using the same example, assuming an exampldd.com delegation exists, this record might be returned from the parent:

exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC )

Just like every authoritative record in the zone 🧾, each generated NSEC record MUST have corresponding RRSIGs made using each algorithm (but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as RFC 4035 [3] Section 2.2 describes 🔏. To keep the number of signatures you have to make down 📉, a zone may wish to limit how many algorithms it has in its DNSKEY RRset.

4. Better Epsilon Functions 💅

Section 6.1 of RFC 4034 sets out a strict ordering of DNS names 📏. Working backward from that, it should be possible to define epsilon functions that generate the immediately following and preceding names, respectively 🤓. This doc doesn't define those, though 🙃. Instead, this section presents functions that get reasonably close to the perfect ones. As described above, an authoritative server should still make sure that no generated NSEC covers any existing name 🫡.

To increment a name ➕, add a leading label containing a single null (zero-value) octet.

To decrement a name ➖, decrement the last character of the leftmost label, then fill that label out to 63 octets with octets of value 255. To decrement a null (zero-value) octet, just remove the octet. If that leaves an empty label, remove the label too 🗑️. If you'd rather define it numerically, fill the leftmost label to its maximum length with zeros (numeric, not ASCII zeros) and subtract one 🔢.

In response to a query for the non-existent name foo.example.com, these functions produce NSEC records like this 👀:

fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG )

\)\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG )

The first NSEC RR proves there's no exact match for foo.example.com 🙅‍♀️. The second proves there's no wildcard in example.com 🃏.

Real talk though 💀. Both of these functions are imperfect, since they don't take into account constraints on the number of labels in a name or the total length of a name. As noted in the previous section, this technique doesn't depend on perfect epsilon functions anyway 🫶. It's enough to test whether any instantiated names fall into the span covered by the generated NSEC. If they do, swap those instantiated owner names in for the NSEC owner name or next name, as appropriate ✨.

That's the first half, bestie 🌈 More of the RFC is coming in part 2 🦋

5. Security Considerations 🔐

Okay bestie, this part is serious, so let's get into it. 😤 This approach needs on-demand generation of RRSIG records, and that creates several new vulnerabilities. Yikes 💀

First, on-demand signing means a zone's authoritative servers need access to its private keys. Keeping private keys on well-known, Internet-accessible servers may make them more vulnerable to unintended disclosure. 🙈

Second, generating digital signatures tends to be computationally demanding, so the need for on-demand signing makes authoritative servers vulnerable to a denial of service attack. 📉

Last, if the epsilon functions are predictable, on-demand signing may enable a chosen-plaintext attack on a zone's private keys. Zones using this approach should try to use cryptographic algorithms that resist chosen-plaintext attacks. Also, although DNSSEC has a "mandatory to implement" algorithm, that's a requirement on resolvers and validators. There is no requirement that a zone be signed with any given algorithm. 🔑

The success of using minimally covering NSEC records to prevent zone walking depends a lot on how good the epsilon functions are. An increment function that picks a name that's obviously derived from the next instantiated name could get reverse engineered, and then the whole technique loses its value 😭. An increment function that always returns a name close to the next instantiated name is also a poor choice. The good ones are the functions that produce the immediately following and immediately preceding names, respectively. 💅 Zone admins might want to use less perfect functions that return more human-friendly names than the functions described in Section 4 above, though. Just know the tradeoff. ✨

Another obvious-but-misguided worry is synthesized NSEC records getting replayed. An attacker could replay an old but still validly signed NSEC record after a new name has been added in the span that NSEC covers. That would incorrectly prove there's no record at that name. 👀 This danger exists with DNSSEC as defined in [3]. The techniques described here actually decrease the danger, because the span covered by any NSEC record is smaller than before. 🎉 Choosing better epsilon functions will reduce this danger even further.

6. Acknowledgements 🫶

Many individuals contributed to this design! 🌸 Besides the authors of this document, they include Olaf Kolkman, Ed Lewis, Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis, Jakob Schlyter, Bill Manning, and Joao Damas. Iconic cast. 👑

The editors also want to thank Ed Lewis, Scott Rose, and David Blacka for their careful review of the document. Real ones read the whole thing. 🤍

7. Normative References 📚

  • [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
  • [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
  • [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
  • [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

Authors' Addresses 💌

Samuel Weiler
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, Maryland  21046
US

EMail: weiler@tislabs.com


Johan Ihren
Autonomica AB
Bellmansgatan 30
Stockholm  SE-118 47
Sweden

EMail: johani@autonomica.se

Copyright (C) The Internet Society (2006). 🌈

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🦋

The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on the extent to which any license under such rights might or might not be available. It also doesn't claim to have made any independent effort to identify any such rights. Info on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79. 📖

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users to use these proprietary rights can be found in the IETF's online IPR repository at http://www.ietf.org/ipr. 🔗

The IETF also invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org. 💜

Acknowledgement 🌷

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Thank you, IASA, for keeping the lights on! ✨

📦 where this page comes from