Summary

  • NXDOMAIN and NODATA are not two spellings of failure. NXDOMAIN says the effective query name does not exist; NODATA says the name exists, or may exist, but has no record of the requested type. Their cache keys differ because their evidentiary scope differs.
  • RFC 2308 made a negative answer both transferable and mortal. An authoritative SOA supplies the zone context and a lifetime derived from the smaller of the SOA TTL and MINIMUM; a resolver must stop using the denial when that countdown reaches zero.
  • DNSSEC, NXDOMAIN cuts and aggressive negative caching later let one validated denial answer a wider set of questions. That efficiency raises the price of a mistaken scope or excessive lifetime, without turning DNS evidence into legal ownership or permanent truth.

The answer section is empty; reality is not

Imagine asking for the A record of service.example. A reply arrives with no A record. That fact alone proves almost nothing. The name might be missing. The name might have MX and TXT records but no A record. The server might be referring the resolver elsewhere. It might be unreachable, misconfigured or temporarily returning SERVFAIL.

Caching the wrong interpretation changes the namespace seen by clients. If the cache decides that the whole name is absent when only A is missing, a later request for MX may never reach an authority even though mail data exists. If it remembers only that A is missing when the authoritative answer was NXDOMAIN, it wastes work by asking about AAAA, TXT and every other type for a name already known not to exist.

DNS therefore needed two kinds of nothing. NXDOMAIN is the Name Error response. After following any CNAME chain, it applies to the effective query name and class. NODATA has no response code of its own: it must be inferred from NOERROR, the absence of a relevant answer and authority data that distinguish a negative response from a referral. It applies to the effective name, requested type and class.

That difference explains the cache tuples formalised by RFC 2308. NXDOMAIN is stored under <QNAME, QCLASS>; NODATA under <QNAME, QTYPE, QCLASS>. A small change in the key prevents a large change in apparent reality.

CNAMEs move the subject of the denial

The label typed by a user is not always the label denied by an authority. An alias may exist and point through one or more CNAME records to a canonical target that does not. The NXDOMAIN concerns the last target, not the alias that successfully supplied the CNAME.

This was one reason RFC 2308 defined QNAME carefully. A cache that attaches the denial to the convenient first label can make a valid alias disappear or reuse evidence outside its actual subject. Correct negative caching begins with identity: what precise name did the authority deny?

The same care is necessary for NODATA. An empty answer at the end of a chain may show that the canonical target has no requested type. It does not prove that the alias has no records of other types, and it certainly does not prove that every label in the chain is nonexistent.

From optional memory to a portable statement

RFC 1034 described negative caching in 1987, but treated it as optional. Remembering a miss could reduce repeated traffic and response time, especially when search paths or automated software generated the same losing questions. Yet the original design had an important propagation weakness: a server could not safely pass its cached negative response to another resolver with the same useful evidence and remaining lifetime.

Published in March 1998, RFC 2308 repaired that gap and made negative caching non-optional for a resolver that caches anything. An authoritative server reporting NXDOMAIN or NODATA must place the containing zone's SOA record in the authority section. The record identifies the zone that is speaking and carries the timing material needed to reuse the statement.

The negative lifetime is the smaller of the SOA record's TTL and the SOA MINIMUM value. The resolver stores the SOA with the negative result. When it returns the result from cache, the displayed TTL has already lost the time spent there. At zero, the denial must not be used again.

The author line of RFC 2308 records Mark Andrews's CSIRO affiliation. That is historical provenance, not the institutional subject of this article. The shared standard and its later amendments were developed through the IETF documentary process.

Why the clock must travel with “no”

The DNS namespace is a tree, but queries can travel through a graph of forwarders. Misconfigured servers may forward to one another. If a negative answer lacks a portable countdown, each server can receive it, assign a fresh local lifetime and pass it back. A statement meant to expire can circulate indefinitely.

RFC 2308 therefore says that negative answers without an SOA should not be cached. A short lifetime at one server is not a limit if another server restarts it. The SOA is not ornamental metadata; it lets independent caches preserve the decline of the same claim.

This repair also clarified an overloaded field. RFC 1035 had described SOA MINIMUM as a lower bound for exported TTLs. Implementations used it as a minimum, a default and a negative-cache timer. RFC 2308 deprecated the unused universal-minimum meaning, separated zone-file defaults into $TTL, and retained MINIMUM as an input to negative lifetime. Running software had exposed ambiguity that the later standard then narrowed.

Deployments found the distinction before the prose settled

RFC 2308 includes a retrospective implementation history rather than a heroic inventor story. It records CHIVES work in the late 1980s, when repeated search-path misses and expensive DNS errors made negative caching operationally useful. It also records BIND work in the early 1990s that distinguished name error from NOERROR_NODATA, initially used a fixed short lifetime and later retained the SOA needed to return evidence with the cached result.

Those accounts show why RFC 2181's RRset precision and RFC 2308's tuples mattered. Implementers did not merely discover a faster cache. They discovered that “no answer” had to be represented as a typed, scoped claim.

The historical appendix is not a deployment census. It cannot tell us what proportion of the Internet used each behaviour on a given date. It does show the direction of correction: from an empty reply, to a remembered condition, to a portable result whose subject, type and lifetime other resolvers could inspect.

The creation delay hidden inside efficiency

A correct negative answer can become wrong because the zone changes. If an operator creates a name while recursive resolvers still hold NXDOMAIN, those clients will continue to see no name. If an operator adds an AAAA record after NODATA for AAAA has been cached, the name remains visible but IPv6 reachability may lag behind the authoritative change.

The TTL is therefore a trade, not a confidence score. Longer negative lifetimes reduce repeated queries and authoritative load. They also extend the interval during which creation or repair can remain invisible. RFC 2308 notes that resolvers may cap published values and describes one-to-three-hour defaults as workable while warning that values over a day had proved troublesome.

There is no global expiry instant. Resolvers receive answers at different times and may impose different caps. A zone can be correct now while clients continue to observe a bounded older denial. Rollout planning must account for what was cached before the change, not only what the authority serves afterward.

Failures must stay outside the claim. Timeout, an unreachable server and SERVFAIL are not nonexistence. RFC 2308 gives some failure conditions separate, tightly limited optional caching treatment. An application that converts temporary inability to answer into NXDOMAIN can turn recoverable outage into a durable decision, such as rejecting mail or abandoning service discovery.

When one denial began answering many questions

DNSSEC added cryptographic evidence of absence. RFC 4034 defines NSEC records that link names in canonical order and list the record types present at an owner; RFC 4035 defines how validators use those records to prove NXDOMAIN or NODATA.

The distinction survives the signature. A gap between owner names can prove that a name is absent. A type bitmap at an existing owner can prove that a requested type is absent. Cryptography authenticates the relevant DNS statement; it does not make the two statements interchangeable.

RFC 5155 introduced NSEC3, including hashed owner names and Opt-Out. Opt-Out is an explicit evidentiary limit: a covering NSEC3 record does not prove every possible name beneath it absent.

RFC 8020 later allowed NXDOMAIN at a node to stop queries below that node within defined boundaries. The rule follows the tree: descendants cannot exist beneath a nonexistent name. It does not apply to NODATA, because a name without one record type can still have other records and descendants.

RFC 8198 lets a validating resolver use cached NSEC or NSEC3 evidence aggressively. One authenticated range can support a synthesized negative response to a question that was never sent upstream. The saving is larger than ordinary exact-query caching—and so is the consequence of stale denial evidence when a new name is introduced inside the range.

Bounded protocol evidence

The negative-answer chain separates authority from execution. A zone operator chooses current contents and timing values. An authoritative server constructs the response. A recursive resolver classifies it, selects the tuple, validates it where applicable, applies local limits and eventually discards it. An application decides what the result means for a user or transaction.

Each role has power, but none owns reality outside its layer. A DNSSEC signature proves origin and integrity under the DNS chain. It does not prove legal entitlement to a name, the nonexistence of an organisation, or the wisdom of a deletion. A cache can amplify a valid denial without gaining authority to make it permanent.

The historical achievement was precise and modest. DNS turned an absence into evidence that could travel: it identified what was missing, who could speak for the relevant zone and how long independent resolvers could reuse the statement. The distinction between NXDOMAIN and NODATA kept that efficiency from erasing data that still existed.

Sources and limits

The original caching and SOA context is documented in RFC 1034 and RFC 1035; RFC 2181 supplies RRset clarification. The negative-response definitions, tuples, SOA lifetime, forwarding-loop warning and implementation history come from RFC 2308.

Authenticated denial is bounded by RFC 4034, RFC 4035 and RFC 5155. The later NXDOMAIN subtree rule is RFC 8020, and validated range synthesis is RFC 8198. Later behaviour is not projected into early resolvers, and the RFC 2308 appendix is treated as retrospective implementation evidence rather than a complete measurement record.