Summary

  • RFC 9824 can answer for a nonexistent DNS name with header RCODE NOERROR, an empty Answer section and a signed NSEC or NSEC3 bitmap containing NXNAME. The authenticated assertion is in the body; the header is not cryptographically protected.
  • The optional EDNS Compact Answers OK flag can restore NXDOMAIN, but it is hop by hop. A resolver must retain capability with cached evidence and adapt its downstream presentation without pretending that the proof itself changed.
  • Compact Answers reduce proof size and online-signing work relative to other online denial shapes, but they forfeit aggressive negative synthesis and retain private-key and computational exposure. Validation, presentation, cache behavior, load and application outcome require separate receipts.

The weaker witness won because it had the easier column

The opening is a constructed case, not a reported incident. Its failure is nevertheless ordinary: one schema field called rcode is cheap to collect, while a verified denial proof is harder to represent. Once the easy field becomes the dashboard truth, everything downstream inherits its blind spot.

RFC 9824, Compact Denial of Existence in DNSSEC, describes an alternative way to prove that a queried name does not exist. Conventional DNSSEC denial commonly uses signed NSEC or NSEC3 material to prove both that an exact name is absent and that no wildcard could have synthesized an answer. An online signer may need up to two signed NSEC records or three signed NSEC3 records for that shape.

Compact Denial makes a deliberately different statement. For a nonexistent name that does not match a wildcard, the authoritative server constructs a NODATA-shaped response: NOERROR in the header, an empty Answer section and one signed NSEC or NSEC3 record matching the query name. The record claims, for proof purposes, that the name exists but has no data of the requested type. That narrower form needs one minimally covering denial record.

The RFC Editor record and IETF Datatracker record identify RFC 9824 as a Proposed Standard published in September 2025. It updates RFCs 4034 and 4035. The document history, reference graph and referenced-by graph disclose the specification's public process and dependencies. They do not prove that a named authoritative server, resolver, library or security product implements it.

NXNAME moves the decisive assertion into signed evidence

The compact shape creates an ambiguity that the ordinary header cannot resolve. A truly existing name can lack the requested RR type. An empty non-terminal can exist because it has descendants while having no records at its own node. Those cases can also produce an empty Answer section and sparse type bitmaps.

RFC 9824 therefore defines NXNAME, value 128, as a synthetic Meta-TYPE. In an NSEC Compact Answer for a nonexistent name, the Type Bit Maps field contains RRSIG, NSEC and NXNAME. In the NSEC3 form, NXNAME is the sole entry. An empty non-terminal does not carry that marker. The distinction lives inside the signed denial material rather than in a guess based on emptiness.

The IANA DNS Parameters registry makes NXNAME interoperably nameable. It also records the Compact Answers OK flag and Extended DNS Error 30. Registration supplies common identifiers; it does not say which server emits them, which resolver validates them or which application understands them.

NXNAME is not ordinary zone data. It should appear only in the NSEC or NSEC3 type bitmap of a Compact Answer for a nonexistent name. An explicit query for the NXNAME RR type receives FORMERR; a server may add EDE 30, Invalid Query Type. A resolver must not forward that query or start iterative resolution for it. The EDE specification supplies the wider error-information framework, while RFC 9824 defines this particular allocation and behavior.

That boundary matters operationally. Seeing NXNAME in a signed bitmap is evidence about nonexistence. Sending a query whose QTYPE happens to be NXNAME is a malformed use of a Meta-TYPE. Treating the two as equivalent would turn a proof marker into a lookup object it was never meant to be.

The RCODE can disagree without invalidating the proof

RFC 9824 is unusually explicit about evidence hierarchy: the DNS header is not cryptographically protected, so its response code cannot be authenticated. The signed data in the body provides the more secure basis for inferring the response's status.

That does not make the header irrelevant. RCODE is the presentation surface consumed by many libraries, security tools and applications. A tool that sees only NOERROR may classify a Compact Answer as NODATA. A DNSSEC validator that verifies the RRSIG and recognizes NXNAME may classify the name as nonexistent. Both outputs should be recorded with their observation points. Only the latter carries the signed denial assertion.

RFC 4034 defines DNSSEC resource records, including NSEC and RRSIG. RFC 4035 defines protocol modifications and authenticated denial processing. RFC 9824 updates both to permit the compact online-signing exception. RFC 9364 provides the broader DNSSEC overview, and RFC 9499 supplies current DNS terminology. None of these documents turns an unverified header snapshot into a signed fact.

A useful receipt therefore records at least the query name and type, DO state, received RCODE, proof type, NXNAME presence, RRSIG/key identifiers, validation result, validator build, time and evidence fingerprint. It must not copy private signing keys. If a normalized field says only “nonexistent,” the receipt should still preserve whether that conclusion came from a header, signed denial, local synthesis or application inference.

Restoring NXDOMAIN is a hop-by-hop presentation contract

RFC 9824 says implementations should try to preserve NXDOMAIN where possible. For DNSSEC-enabled exchanges it defines an optional but recommended scheme using the EDNS Compact Answers OK, or CO, flag. A resolver that sets CO says it will accept a Compact Answer with signed NXNAME and a restored NXDOMAIN RCODE. An authoritative server implementing the scheme can set CO in the response and emit NXDOMAIN for the nonexistent name.

RFC 6891 matters because EDNS signaling is hop by hop. The capability is not a durable end-to-end promise. A resolver caching an NXNAME answer must retain whether the upstream response carried CO. When responding to a downstream DNSSEC-enabled querier that did not set CO, it resets the RCODE to NOERROR for that NXNAME response.

The signed proof has not changed between those two presentations. Local compatibility policy has. A cache model that stores the RRsets but discards the associated CO state can no longer reproduce the intended downstream behavior. A telemetry model that records only the emitted RCODE cannot say whether the resolver validated NXNAME, restored a code for a capable peer or merely repeated an upstream header.

This is where a minimum specification earns its value. The common contract needs the proof marker, capability bit and transition rules. It does not need to dictate every operator's rollout, tool migration or application policy. Local owners still decide whether to enable Compact Answers, how long to retain capability state, which downstream populations receive restored codes and what rollback evidence is sufficient.

Smaller proofs move costs rather than abolishing them

Compact Answers use one minimally covering NSEC or NSEC3 proof. RFC 4470 is the predecessor for minimally covering NSEC and online signing; RFC 5155 defines NSEC3. RFC 9824 says the compact technique reduces response size and online cryptographic work relative to the larger online denial shapes, while also preventing useful zone walking from the minimally covering records.

Those benefits do not mean “less DNS work” everywhere. Compact Answers cannot support the NXDOMAIN and wildcard synthesis described by RFC 8020 and RFC 8198. A resolver cannot generalize one compact proof across a wider name range in the same way. Pseudorandom-subdomain queries may therefore continue upstream to the authority rather than being answered from aggressive negative cache state.

The authoritative side also remains an online signer. Its Internet-reachable infrastructure needs access to private signing capability, and each generated proof consumes computation. RFC 9824 reduces signing operations compared with other online techniques; it does not make online signing equivalent to serving precomputed signatures. The specification explicitly notes the continuing computational-denial-of-service exposure and leaves conventional online signing or precomputed signatures available when the compact design's motivations do not justify its costs.

Leadership should demand a two-sided capacity ledger: authoritative signature rate and latency, queue depth, key boundary and CPU saturation on one side; cache hit shape, repeated type queries, upstream query amplification and application latency on the other. A claimed response-size saving is not enough if the resolver loses synthesis and moves more work onto the signer.

Applications see consequences, not protocol intentions

An address lookup illustrates the final gap. A library receiving NODATA for an AAAA query may ask for A at the same name. An NXDOMAIN response could suppress that second query. Compact Answers can therefore change query sequences even when the signed conclusion is unambiguous to a capable validator.

The application may never inspect NSEC. A local stub may not request DNSSEC records. A security product may read RCODE but ignore signed type bitmaps. A recursive service may understand NXNAME but adapt its downstream response to a peer without CO. The standard defines how these pieces can interoperate; only observations can show which path a particular request took.

Running-code primacy means following the executed chain: authoritative response generated, signature verified, NXNAME interpreted, cache state written, downstream capability evaluated, RCODE emitted, library queries issued and application result observed. Reality-layer discipline prevents a valid signature from being promoted into proof that the application behaved as intended. It also prevents a NOERROR header from overruling signed denial merely because it is easier to graph.

Sources

  1. IETF Datatracker: RFC 9824
  2. IETF Datatracker history: RFC 9824
  3. IETF Datatracker referenced-by graph: RFC 9824
  4. IETF Datatracker references: RFC 9824
  5. Heng Lu: Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  6. Heng Lu: On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  7. Heng Lu: Running-Code Primacy
  8. IANA DNS Parameters
  9. RFC 9824 errata
  10. RFC Editor information: RFC 9824
  11. RFC 4034
  12. RFC 4035
  13. RFC 4470
  14. RFC 5155
  15. RFC 6891
  16. RFC 8020
  17. RFC 8198
  18. RFC 8914
  19. RFC 9364
  20. RFC 9499
  21. RFC 9824