DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
updated by
- rfc-6840 — Clarifications and Implementation Notes for DNS Security (DNSSEC)
- rfc-6944 — Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status
- rfc-9077 — NSEC and NSEC3: TTLs and Aggressive Use
- rfc-9157 — Revised IANA Considerations for DNSSEC
- rfc-9276 — Guidance for NSEC3 Parameter Settings
- rfc-9905 — Deprecating the Use of SHA-1 in DNSSEC Signature Algorithms
Extracted elements (31)
New DNSKEY algorithm identifiers (6: DSA-NSEC3-SHA1, 7: RSASHA1-NSEC3-SHA1) are introduced as aliases for existing algorithms solely to signal NSEC3 use to resolvers. NSEC3-unaware resolvers seeing these unknown algorithm IDs will treat the zone as insecure rather than attempting—and failing—to validate NSEC3 denial-of-existence proofs.
NSEC RRs enable zone enumeration because the ordered chain of NSEC records lists all names in a zone, making it trivial to walk the zone by querying non-existent names. Enumerated zones expose e-mail addresses for spam and registrant data, rendering zone-data-protection policies unenforceable. NSEC3 addresses this by replacing owner names in the chain with cryptographic hashes.
NSEC3 is not generally backwards-compatible with RFC 4033/4034/4035. NSEC3-unaware resolvers that encounter the new algorithm identifiers (6 or 7) will treat responses from NSEC3-signed zones as insecure per RFC 4035 Section 5.2, rather than erroneously marking them bogus.
A validator MUST ignore NSEC3 RRs with unknown hash types and MUST ignore NSEC3 RRs with a Flags field value other than zero or one. Responses containing only such NSEC3 RRs will generally be treated as bogus.
Dynamic update processing for NSEC3 zones MUST account for empty non-terminals: when removing a name, NSEC3 RRs for empty non-terminals it created MUST be removed; when adding a name requiring a new NSEC3 RR, NSEC3 RRs for any newly-created empty non-terminals MUST also be added.
Each authoritative owner name in the zone MUST have a corresponding NSEC3 RR. Each empty non-terminal MUST also have an NSEC3 RR unless it is derived solely from an insecure delegation covered by an Opt-Out NSEC3 RR. Unsigned delegations MAY have an NSEC3 RR, but if not, an Opt-Out NSEC3 RR covering the next closer name MUST exist.
For Name Error (NXDOMAIN) responses, a closest encloser proof for QNAME and an NSEC3 RR covering the wildcard at the closest encloser MUST be included in the response, proving both that QNAME does not exist and that no matching wildcard exists.
For No Data responses where QTYPE is not DS, the server MUST include the NSEC3 RR that matches QNAME, and that NSEC3 RR MUST NOT have the bits for QTYPE or CNAME set in its Type Bit Maps field.
If a runtime hash collision occurs (hash of a non-existing QNAME collides with an existing NSEC3 owner name), the server MUST return a response with RCODE=2 (SERVFAIL), as it cannot construct a valid denial-of-existence proof.
If an NSEC3PARAM RR is present at the zone apex with a Flags field value of zero, then the zone MUST contain a complete set of NSEC3 RRs using the same hash algorithm, iterations, and salt at every hashed owner name in the zone.
It is strongly RECOMMENDED that Opt-Out be used sparingly. Zone signing tools SHOULD NOT default to using Opt-Out, because Opt-Out allows a malicious entity to insert or delete unsigned delegation RRs undetectably.
The AD bit MUST NOT be set when returning a response containing a closest encloser proof in which the NSEC3 RR covering the 'next closer' name has the Opt-Out bit set, because names in the Opt-Out span may be insecure delegations whose existence cannot be cryptographically verified.
When returning responses containing multiple NSEC3 RRs, all NSEC3 RRs MUST use the same hash algorithm, iteration, and salt values. The Flags field value MUST be either zero or one.
When specifying a new hash algorithm for use with NSEC3, a transition mechanism MUST also be defined, as this document itself does not define a safe algorithm-transition mechanism.
Zone owners MUST NOT use an iteration count higher than the table values: 150 for 1024-bit keys, 500 for 2048-bit keys, 2500 for 4096-bit keys. These limits balance dictionary-attack resistance against signing, serving, and validation cost.
Zones signed according to this specification MUST only use algorithm identifiers 6 (DSA-NSEC3-SHA1) or 7 (RSASHA1-NSEC3-SHA1) for their DNSKEY RRs. Security-aware resolvers that know this spec MUST treat these identifiers as equivalent to the algorithms they alias.
Hash calculation uses the iterated function IH: IH(salt, x, 0) = H(x || salt); IH(salt, x, k) = H(IH(salt, x, k-1) || salt) for k > 0. The owner name is hashed in canonical wire-format form (fully expanded, fully qualified, lowercase), with wildcards left unexpanded. The method is based on PKCS#5 (RFC 2898).
The Closest Encloser Proof consists of up to two NSEC3 RRs: one that matches the closest (provable) encloser of QNAME, and one that covers the 'next closer' name. Together they prove that the closest encloser exists and that QNAME (and all intermediate ancestors) does not.
The NSEC3 RR (type 50) provides authenticated denial of existence by storing a hashed owner name chain. Its RDATA contains Hash Algorithm (1 octet), Flags (1 octet, Opt-Out in LSB), Iterations (16-bit unsigned), Salt Length (1 octet), Salt (variable), Hash Length (1 octet), Next Hashed Owner Name (variable binary), and Type Bit Maps. The owner name is the base32 encoding of the hash prepended as a single label to the zone name.
The NSEC3PARAM RR (type 51) is placed at the zone apex and contains Hash Algorithm, Flags, Iterations, and Salt—the parameters authoritative servers need to compute hashed owner names for negative responses. It is not used by validators or resolvers. If its Flags field is non-zero the RR MUST be ignored.
The Opt-Out flag (LSB of the Flags field) allows an NSEC3 RR to cover zero or more insecure delegations without requiring individual NSEC3 RRs for each unsigned delegation. An Opt-Out NSEC3 RR neither asserts nor denies the existence of insecure delegations within its span, enabling efficient signing of large delegation-centric zones.
This document assigns two new DNS RR types in the IANA 'DOMAIN NAME SYSTEM PARAMETERS' registry: NSEC3 = type 50 (Section 3) and NSEC3PARAM = type 51 (Section 4). It also registers DNSKEY algorithm aliases DSA-NSEC3-SHA1 (6) and RSASHA1-NSEC3-SHA1 (7).
This document creates the 'DNSSEC NSEC3 Flags' registry (8 one-bit flags). Bit 7 (LSB) is the Opt-Out flag; bits 0–6 are available for assignment via IETF Standards Action. Also creates the 'DNSSEC NSEC3PARAM Flags' registry where bit 7 is reserved and must be zero.
This document creates the 'DNSSEC NSEC3 Hash Algorithms' IANA registry. Initial values: 0 = Reserved, 1 = SHA-1, 2–255 = Available for assignment. New assignments require IETF Standards Action.
A zone containing even one signed NSEC3 RR with a high iteration value is vulnerable to a downgrade attack: an attacker replaces normal NSEC3 RRs in a response with the high-iteration RR, forcing validators to treat the response as insecure. High iteration counts also enable denial-of-service against servers that must compute multiple hashes per negative response.
NSEC3 zones remain susceptible to offline dictionary attacks: an attacker retrieves all NSEC3 RRs and hashes all likely names to enumerate the zone. The iteration count makes this more expensive. Pre-calculated dictionary attacks are mitigated by changing the salt regularly; the salt SHOULD be at least 64 bits long and unpredictable.
Walking the NSEC3 RR chain still reveals the total number of RRs in the zone (including empty non-terminals) and the RR types present, providing partial zone content information even without full name enumeration.
With Opt-Out, a malicious entity can undetectably insert or delete unsigned delegation NS RRs (and any RRs in a subzone under attacker control), as the existence or nonexistence of insecure delegations within an Opt-Out span cannot be cryptographically proven.
NSEC3 RDATA wire format: Hash Alg. (8 bits), Flags (8 bits, bit 7 = Opt-Out), Iterations (16-bit big-endian unsigned), Salt Length (8-bit unsigned), Salt (Salt Length octets, omitted if zero), Hash Length (8-bit unsigned), Next Hashed Owner Name (Hash Length octets, unmodified binary hash, no base32, no zone suffix), Type Bit Maps (variable).
NSEC3PARAM RDATA wire format: Hash Alg. (8 bits), Flags (8 bits), Iterations (16-bit big-endian unsigned), Salt Length (8-bit unsigned), Salt (Salt Length octets, omitted if zero). The Flags field Opt-Out bit is not used and MUST be zero.
Type Bit Maps encoding (shared with NSEC per RFC 4034): the 16-bit RR type space is divided into 256 window blocks; each present block is encoded as Window Block # (1 octet), Bitmap Length (1 octet, 1–32), and Bitmap (up to 32 octets). Blocks with no types present MUST NOT be included; trailing zero octets MUST be omitted.