DNS negative caching: why a deleted record can keep failing

DNS caches absence, not just answers. When a resolver learns that a name does not exist—or that a name exists but lacks a requested record type—it may retain that negative answer for a bounded time. This prevents repeated misses from hammering authoritative servers, but it also explains a classic deployment surprise: you create a record, yet some clients still receive “not found.”

Two different kinds of “no”

NXDOMAIN says the queried name does not exist. NODATA (often represented as NOERROR with no requested records) says the name exists, but not with the requested type. For example, api.example.test A might return NODATA while an AAAA record exists. These distinctions matter: caches and applications can draw different conclusions, especially when discovering aliases or trying another address family.

Where negative TTL comes from

For the traditional DNS response model, RFC 2308 derives the negative-cache lifetime from the zone's SOA record: use the smaller of the SOA RR's TTL and its MINIMUM field. The authoritative server includes the SOA in the negative response so recursive resolvers can cache the denial with that lifetime. The MINIMUM field is therefore no longer simply a universal default TTL for every record; its negative-caching role is the important one here.

client asks resolver: missing.example A?
resolver asks authoritative server
server: NXDOMAIN + SOA (TTL=3600, MINIMUM=300)
resolver caches negative answer for at most 300 seconds
record is created immediately afterward
resolver may still answer NXDOMAIN until cache expires

Resolvers can apply local policy and caps, and DNS implementations differ in details. Treat the SOA-derived value as protocol guidance, not a promise that every cache expires at exactly that second.

Why negative caching exists

Without it, typos, scanners, and service-discovery probes could trigger a fresh recursive lookup on every request. Negative caching reduces traffic and latency for repeated misses. The trade-off is delayed recovery when a name is created or corrected. Lowering the zone's negative TTL helps planned migrations, but changing it immediately before a deployment cannot erase answers already cached elsewhere; existing cache entries keep their prior expiry.

Aliases and address-family gotchas

A negative answer for a name can affect alias processing differently from an absent record type. In particular, NXDOMAIN means there is no name to continue following, while NODATA can mean “try another type” or “the alias target exists but lacks this data,” depending on the query path. When debugging a dual-stack service, test A and AAAA separately; do not summarize both outcomes as “DNS is broken.” Also inspect CNAME chains, because the final target's negative answer may be what the resolver cached.

Reproducible lab: observe a negative response

This uses a reserved example domain and only performs public DNS queries. Install dig (usually included with BIND utilities), then ask a recursive resolver for an intentionally nonexistent name:

dig @1.1.1.1 no-such-host-20261009.example.com A
# Examine status, ANSWER, AUTHORITY, and the SOA TTL/MINIMUM fields.
# Repeat the exact query; compare the returned SOA TTL as it counts down.
dig @1.1.1.1 no-such-host-20261009.example.com A

The domain owner may change zone data, so the exact response can vary. To inspect your own zone safely, query a name you control that is currently absent, then compare the recursive answer with a direct authoritative query:

dig +short NS example.org
dig @<authoritative-name-server> absent-label.example.org A +norecurse
dig @1.1.1.1 absent-label.example.org A

Substitute a zone you administer; do not infer production behavior from the example domain. Compare the SOA authority section, remaining TTL, resolver identity, and response code.

Incident workflow

Query the exact FQDN and record type from the affected host; capture status, answer, authority section, and resolver address.
Query an authoritative server directly with recursion disabled. If authority is correct but recursive output differs, suspect cache or delegation propagation.
Check whether the result is NXDOMAIN or NODATA; verify A and AAAA independently and follow any CNAME target.
Read the SOA values in the negative response and compare with the resolver's remaining TTL; account for resolver-specific minimums and maximums.
Check split-horizon DNS, search suffix expansion, DNSSEC validation failures, and application-level caches before flushing anything.
For planned changes, lower relevant TTLs well before the migration, wait out old values, then make the change and verify from multiple resolvers.

Flushing a local cache can help one machine, but it does not clear recursive caches, browser caches, or caches inside an application. Prefer evidence that identifies which layer returned the denial.