Compact Denial of Existence in DNSSEC
updates
Extracted elements (28)
Compact Denial of Existence returns a NODATA response (RCODE NOERROR, empty ANSWER) for nonexistent names rather than NXDOMAIN, claiming the name exists but has no records for the queried type. This requires only one minimally covering NSEC or NSEC3 record instead of up to two (NSEC) or three (NSEC3), reducing response size, online signing work, and enabling zone-content protection.
NSEC is preferred over NSEC3 for Compact Denial of Existence because minimally covering NSEC records already prevent zone enumeration (NSEC3's primary advantage), and NSEC3's Opt-Out feature provides no benefit for online signing since minimally covering NSEC3 records provide no useful Opt-Out span. NSEC3 support is provided only to ease migration from existing NSEC3 online signing implementations.
NXNAME value 128 was chosen from the Meta-TYPEs range because a lower number in this range reduces the size of the Type Bit Maps field, which directly reduces the overall DNS response message size—the primary optimization goal of Compact Denial of Existence.
The NXNAME Meta-TYPE approach was chosen over the ENT-sentinel approach (defining a synthetic type for ENTs rather than for NXDOMAIN) because NXNAME explicitly and conclusively identifies NXDOMAIN responses, distinguishing them from potential ENT responses in other online signing NSEC implementations, even though ENT-sentinel imposes less server work given NXDOMAIN is more common than ENTs.
Address lookup functions may issue extra queries when receiving NODATA instead of NXDOMAIN for a nonexistent name (e.g., a AAAA NODATA response will not suppress subsequent A queries), increasing DNS traffic. Connection functions like Happy Eyeballs that issue back-to-back queries are less affected.
Compact Denial of Existence is incompatible with NXDOMAIN synthesis (RFC 8020) and aggressive use of DNSSEC-validated cache (RFC 8198) for DNSSEC-enabled responses. No online signing scheme employing minimally covering NSEC or NSEC3 records permits such synthesis.
RFC 4034 Section 4.1.2 is updated to add an exception to the rule that pseudo-type bits MUST be clear in NSEC Type Bit Maps: the NXNAME pseudo-type (RFC 9824) is allowed to appear in responses to nonexistent names. No known resolver previously enforced this restriction, so deployment has been unaffected.
RFC 4035 Section 2.3 is updated to add an exception for online signing implementations: dynamically generated NSEC records may be produced for owner names that don't exist or are Empty Non-Terminals (ENTs). The original restriction (NSEC MUST NOT be the only RRset at an owner name) applies only to precomputed-signature implementations.
For a nonexistent name, the NSEC Type Bit Maps field MUST only have bits set for RRSIG, NSEC, and NXNAME. The dynamically constructed NSEC record MUST have corresponding RRSIGs generated.
For NSEC3-based Compact Denial of Existence, NSEC3 parameters SHOULD be set to algorithm 1 (SHA-1), flags field 0, additional hash iteration count 0, and an empty salt ('1 0 0 -' in presentation format).
If a DNS server receives an explicit query for the NXNAME RR type, it MUST return a Format Error (FORMERR). A resolver MUST NOT forward such queries upstream or attempt iterative resolution.
NXNAME is a Meta-TYPE that SHOULD NOT appear anywhere in a DNS message except in the NSEC Type Bit Maps field of a Compact Answer response for a nonexistent name. A server MAY also include Extended DNS Error (EDE) code 30 (Invalid Query Type) when returning FORMERR for an NXNAME query.
The Next Domain Name field in the dynamically constructed NSEC record SHOULD be set to the immediate lexicographic successor of the QNAME, accomplished by prepending a single-label containing a null (zero-value) octet.
A new EDNS0 OPT header flag, Compact Answers OK (CO), is defined at bit 1 (second most significant bit) of the EDNS0 flags field. When set in a query, it signals the resolver will accept a NODATA response with a signed NXNAME together with RCODE NXDOMAIN, enabling signaled response code restoration.
For a nonexistent name, the authoritative server generates a NODATA response (RCODE NOERROR, empty Answer) with a dynamically constructed NSEC record whose owner name matches the QNAME placed in the Authority section. Example: 'a.example.com. 300 IN NSEC \000.a.example.com. RRSIG NSEC NXNAME'.
For NSEC3-based Compact Answers, the NSEC3 record owner name is the NSEC3 hash of the relevant domain encoded in Base32 Extended Hex Alphabet prepended as a single label to the zone name. The Next Hashed Owner Name is computed by adding one to the binary hash value. For nonexistent names, the Type Bit Maps field contains only NXNAME; for ENTs, it is empty.
For unsigned referrals with Compact Denial of Existence, the Next Domain Name field is formed by appending a zero octet to the first label of the owner name (e.g., 'sub.example.com. 300 IN NSEC sub\000.example.com. NS RRSIG NSEC'), rather than using the immediate lexicographic successor, to avoid falling under the delegated subzone.
For wildcard matches, the server provides a dynamically signed response claiming the QNAME exists explicitly, with the RRSIG label count equal to the number of labels in the query name minus the root. This eliminates the need for an NSEC record showing no closer match exists.
NXNAME is a synthetic Meta-TYPE with value 128, allocated in the DNS RR TYPEs registry. It is placed in the NSEC Type Bit Maps field (in addition to RRSIG and NSEC) to signal that the owner name does not exist. For NSEC3, it is the sole entry in the Type Bit Maps field for nonexistent names.
Signaled Response Code Restoration: when the CO flag is set in a query, an authoritative server implementing both Compact Denial of Existence and this scheme will set the CO flag in the response and additionally set RCODE to NXDOMAIN (3) for nonexistent names, while still returning a NODATA body with NXNAME in the NSEC Type Bit Maps.
IANA allocated bit 1 with flag mnemonic 'CO' (Compact Answers OK) in the 'EDNS Header Flags (16 bits)' registry (Domain Name System Parameters), as defined by RFC 9824 Section 5.1.
IANA allocated INFO-CODE 30 with purpose 'Invalid Query Type' in the 'Extended DNS Error Codes' registry (Domain Name System Parameters), applicable to queries for RR types (like NXNAME) that ought not appear in DNS queries.
IANA allocated NXNAME with value 128 in the 'Resource Record (RR) TYPEs' registry (Domain Name System Parameters), in the Meta-TYPEs range, meaning 'NXDOMAIN indicator for Compact Denial of Existence'. The low value minimizes the Type Bit Maps field size.
Because Compact Denial of Existence prevents aggressive negative caching (resolvers cannot synthesize NXDOMAIN from NSEC records), Pseudorandom Subdomain Attacks are more effective: all random-name queries must be forwarded to authoritative servers, making resource exhaustion more likely.
Online signing requires authoritative servers to hold private signing keys and be Internet-reachable, increasing vulnerability to key compromise. Additionally, generating signatures on demand is more computationally intensive than returning precomputed signatures, making servers more vulnerable to computational denial-of-service attacks even though Compact Answers reduces signing operations compared to prior techniques like White Lies.
Security tools that rely on detecting nonexistent domain names by examining the RCODE field will see NOERROR instead of NXDOMAIN, impairing detection. Implementing the optional response code restoration scheme (Section 5.1) helps recover NXDOMAIN visibility. Notably, inferring status from signed NSEC data in the body is more secure than trusting the unprotected DNS header RCODE field.
NSEC record for nonexistent name: owner field equals QNAME; Next Domain Name equals '\000.QNAME' (null-label prepended); Type Bit Maps contains RRSIG, NSEC, NXNAME bits only. Example: 'a.example.com. 300 IN NSEC \000.a.example.com. RRSIG NSEC NXNAME'.
NSEC3 record for nonexistent name: owner is Base32-Extended-Hex-encoded SHA-1 hash of QNAME as a label prepended to zone name; Next Hashed Owner Name is hash+1 (binary increment); Type Bit Maps contains only NXNAME. Example: 'H64KFA4P1ACER2EBPS9QSDK6DNP8B3JQ.example.com. IN NSEC3 1 0 0 - H64KFA4P1ACER2EBPS9QSDK6DNP8B3JR NXNAME'.