DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format
obsoleted by
- rfc-4033 — DNS Security Introduction and Requirements
- rfc-4034 — Resource Records for the DNS Security Extensions
- rfc-4035 — Protocol Modifications for the DNS Security Extensions
updates
Extracted elements (16)
The new Type Bit Map format was chosen to cover the full 16-bit RR type space (65536 types) rather than just the first 127, to avoid needing to develop an extension mechanism into a deployed DNSSEC base once the first 127 type codes are allocated. The format is economical for the common case of few types, can represent all types in ~8.5 KB, and is simple to implement.
The NXT RR's original RDATA format (RFC 2535) could only carry information about the existence of the first 127 types. RFC 2535 reserved a bit for an extension mechanism but never defined it, motivating this redefinition via NSEC rather than extending NXT.
This document updates RFC 2535 and RFC 3755, redefining only the wire format of the Type Bit Map field while preserving all other NSEC RR syntax and semantics as specified in those documents.
A sender MUST NOT use DNS name compression on the Next Domain Name field when transmitting an NSEC RR.
Bit 0 in window block 0 refers to the non-existing RR type 0 and 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 (per RFC 2929 section 3.1), or within the range reserved for QTYPEs and Meta-TYPEs, MUST be set to 0 since they do not appear in zone data. If encountered, they must be ignored upon reading.
Blocks with no types present MUST NOT be included in the Type Bit Map field. Trailing zero octets in the bitmap MUST be omitted; unspecified trailing zero octets MUST be interpreted as zero octets.
Owner names of RRsets that are not authoritative for the given zone (such as glue records) MUST NOT be listed in the Next Domain Name unless at least one authoritative RRset exists at the same owner name.
The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL field, in the spirit of negative caching.
When the RR type mnemonic in the presentation format is not known, the TYPE representation as described in RFC 3597 section 5 MUST be used.
The NSEC RR lists the owner name of the next RRset in canonical zone ordering and the set of RR types present at the NSEC RR's owner name. The type value for the NSEC RR is 47, and the RDATA format is class independent.
The NSEC RR presentation format represents the Next Domain Name as a domain name and the Type Bit Map as a sequence of RR type mnemonics (e.g., 'A MX RRSIG NSEC TYPE1234').
Wildcard owner names appearing in a zone have the wildcard label ('*') treated as a literal symbol for purposes of generating NSEC RRs. Wildcard owner names appear in the Next Domain Name field without wildcard expansion.
The update to the NSEC RDATA format and encoding does not affect the security of the use of NSEC RRs. Security properties remain as defined in RFC 2535.
Each Type Bit Map window block encodes the low-order 8 bits of the 16-bit RR type space. Window blocks are ordered by increasing window number; each bitmap bit in network bit order represents an RR type, with bit 1 of window 0 corresponding to RR type 1 (A).
The NSEC RDATA consists of two variable-length fields: the Next Domain Name (encoded as a domain name) followed by the List of Type Bit Map(s). The Type Bit Map field uses 256 window blocks, each encoded as a 1-octet window number, a 1-octet bitmap length (1–32), and up to 32 octets of bitmap.