RFC 3845

DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format 🎀

okay bestie, this is RFC 3845 📜 and it's a Standards Track doc, so it's the real deal, not a "maybe someday" thing 👑 It came out in August 2004 🌸, edited by J. Schlyter, Ed. 💅 It updates RFC 3755 and RFC 2535 ✨ and doesn't obsolete anything. The whole point is fixing how DNSSEC's NSEC record packs its type list 🦋

Status of this Memo ✨

so this doc is an Internet standards track protocol for the Internet community 🌈 It's also asking people to talk about it and suggest improvements 💬 If you want the current official standardization state of this protocol, check the "Internet Official Protocol Standards" (STD 1) 📖 And the distribution of this memo is unlimited 🥰

Copyright Notice 🌸

Copyright (C) The Internet Society (2004).

Abstract 💖

this doc redefines the wire format of the "Type Bit Map" field in the DNS NextSECure (NSEC) resource record RDATA format 🔥 The goal is to cover the full resource record (RR) type space, so every type fits 🙌

Table of Contents 📚

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
2.  The NSEC Resource Record . . . . . . . . . . . . . . . . . . .  2
    2.1.  NSEC RDATA Wire Format . . . . . . . . . . . . . . . . .  3
          2.1.1.  The Next Domain Name Field . . . . . . . . . . .  3
          2.1.2.  The List of Type Bit Map(s) Field  . . . . . . .  3
          2.1.3.  Inclusion of Wildcard Names in NSEC RDATA  . . .  4
    2.2.  The NSEC RR Presentation Format  . . . . . . . . . . . .  4
    2.3.  NSEC RR Example  . . . . . . . . . . . . . . . . . . . .  5
3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  5
4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  5
5.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
    5.1.  Normative References . . . . . . . . . . . . . . . . . .  6
    5.2.  Informative References . . . . . . . . . . . . . . . . .  6
6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  6
7.  Author's Address . . . . . . . . . . . . . . . . . . . . . . .  6
8.  Full Copyright Statement . . . . . . . . . . . . . . . . . . .  7

1. Introduction 🦋

okay so the NSEC [5] Resource Record (RR) is how DNS gives authenticated proof that a DNS owner name or type doesn't exist, which is so iconic 💅 It's cousins with the DNS [6][7] stuff, and it's based on the NXT RR from RFC 2535 [2]. It's basically the same except for the name and the typecode 🧚

here's the tea ☕: the NXT RDATA could only carry info about the first 127 types. Not great! RFC 2535 did reserve a bit for an extension mechanism, but nobody ever actually defined it 💀

so to avoid building an extension mechanism into a deployed base of DNSSEC-aware servers and resolvers once those first 127 type codes get used up, this doc redefines the wire format of the "Type Bit Map" field in the NSEC RDATA to cover the full RR type space 🌈

the new type bit map format can cover the full possible range of typecodes 🙌 It's also pretty economical for the common case of a few types on an owner name, and it can represent owner names with all possible types present in packets of approximately 8.5 kilobytes 😳 Plus it's simple to implement 💖 Efficient searching of the type bitmap for certain types is not a requirement, so no stress there ✨

for convenience and completeness, this doc lays out the syntax and semantics of the NSEC RR based on RFC 2535 [2] as updated by RFC 3755 [5]. So no changes there, except for the syntax of the type bit map 🎀

This document updates RFC 2535 [2] and RFC 3755 [5].

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [1] 🔑

2. The NSEC Resource Record 💜

the NSEC resource record lists two things 👑: the owner name of the next RRset in the canonical ordering of the zone, and the set of RR types present at the NSEC RR's owner name. All the NSEC RRs in a zone tell you which RRsets exist, and they form a chain of owner names through the zone 🔗 That info gives you authenticated denial of existence for DNS data, as described in RFC 2535 [2] 🦋

The type value for the NSEC RR is 47.

The NSEC RR RDATA format is class independent and defined for all classes ✨

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

2.1. NSEC RDATA Wire Format 🌸

the RDATA of the NSEC RR looks like this 👇

                     1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                      Next Domain Name                         /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                   List of Type Bit Map(s)                     /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.1.1. The Next Domain Name Field 💖

the Next Domain Name field holds the owner name of the next RR in the canonical ordering of the zone 🧭 For the last NSEC record in the zone, this field is the name of the zone apex, which is the owner name of the zone's SOA RR 👑

A sender MUST NOT use DNS name compression on the Next Domain Name field when transmitting an NSEC RR. no compression, bestie 🙅‍♀️

Owner names of RRsets that aren't authoritative for the given zone (like glue records) MUST NOT be listed in the Next Domain Name unless at least one authoritative RRset exists at the same owner name 🚫 That's a hard no, no cap 💀

2.1.2. The List of Type Bit Map(s) Field 🌈

the RR type space is split into 256 window blocks, and each one represents the low-order 8 bits of the 16-bit RR type space 🧩 Every block that has at least one active RR type gets encoded with a single octet window number (from 0 to 255), a single octet bitmap length (from 1 to 32) saying how many octets the block's bitmap uses, and up to 32 octets (256 bits) of bitmap 🎀

window blocks show up in the NSEC RR RDATA in increasing numerical order 📈

"|" denotes concatenation ✨

the layout is Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) + 🦋

Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) +

each bitmap encodes the low-order 8 bits of RR types within the window block, in network bit order 🌐 The first bit is bit 0. For window block 0, bit 1 is RR type 1 (A), bit 2 is RR type 2 (NS), and so on 💅 For window block 1, bit 1 is RR type 257 and bit 2 is RR type 258 🔢 If a bit is set to 1, an RRset of that type is present for the NSEC RR's owner name ✅ If a bit is set to 0, no RRset of that type is present for that owner name ❌

since bit 0 in window block 0 refers to the non-existing RR type 0, it MUST be set to 0 🙈 After verification, the validator MUST ignore the value of bit 0 in window block 0 🫶

bits representing Meta-TYPEs or QTYPEs, as specified in RFC 2929 [3] (section 3.1), or within the range reserved for assignment only to QTYPEs and Meta-TYPEs, MUST be set to 0, since they don't show up in zone data 🧚 If you do run into them, they must be ignored upon reading 🙈

blocks with no types present MUST NOT be included 🚫 Trailing zero octets in the bitmap MUST be omitted ✂️ The length of each block's bitmap is determined by the type code with the largest numerical value within that block, among the set of RR types present at the NSEC RR's owner name 📏 Trailing zero octets that aren't specified MUST be interpreted as zero octets 💖

2.1.3. Inclusion of Wildcard Names in NSEC RDATA 🌟

if a wildcard owner name shows up in a zone, the wildcard label ("*") is treated as a literal symbol 🔣 It's handled the same as any other owner name when generating NSEC RRs 💅 Wildcard owner names appear in the Next Domain Name field without any wildcard expansion 🙌 RFC 2535 [2] describes how wildcards affect authenticated denial of existence 📖

2.2. The NSEC RR Presentation Format 🎀

the presentation format of the RDATA portion goes like this ✨

The Next Domain Name field is represented as a domain name.

The List of Type Bit Map(s) Field is represented as a sequence of RR type mnemonics. When the mnemonic isn't known, the TYPE representation from RFC 3597 [4] (section 5) MUST be used 🧩

8. Full Copyright Statement ✨

Okay bestie, time for the legal bit 💅 The Internet Society owns the copyright here (2004 🦋). This document is subject to the rights, licenses and restrictions in BCP 78, and except as set forth there, the authors keep all their rights 🔐

Also, the doc comes as "AS IS" and the whole disclaimer is in ALL CAPS for a reason 😭 THE CONTRIBUTOR, THE ORGANIZATION HE/S HE 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

So the IETF is not picking a side on whether any Intellectual Property Rights or other rights could apply to the tech in this document 🌸 It also doesn't say whether licenses for those rights exist or are available, and it hasn't done its own search for any such rights either 🙈 If you want the rules on IETF Documents and rights, check out BCP 78 and BCP 79, they're the source of truth ✨

Copies of IPR disclosures sent to the IETF Secretariat live in the IETF online IPR repository at http://www.ietf.org/ipr. That's also where you'd find any assurances of licenses that have been made available, or the results of attempts to get a general license or permission for implementers or users of this specification to use those proprietary rights 🧚

The IETF also invites anyone to point out any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard 💜 Send that info to the IETF at ietf-ipr@ietf.org 🫶

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society 🎀 Honestly, the people keeping the RFC library running deserve all the flowers 🌈