A DNS cache does not store only successful answers. Recursive resolvers can also retain authoritative responses that say a requested name or record does not exist. This behavior is called negative caching.
Negative caching reduces repeated work. If many clients ask for the same absent name, a resolver can answer from its cache instead of sending the same query through the DNS hierarchy each time.
The trade-off is temporal. If an administrator adds the missing record while a negative answer is still cached, some clients can continue receiving the cached error until its negative cache lifetime expires.
Negative answers represent specific DNS states
Two common negative outcomes have different meanings.
NXDOMAIN says the queried domain name does not exist. A no-data response says the name exists but has no record of the requested type.
For example, a name can have an A record but no AAAA record. A query for its IPv6 address can therefore produce a negative answer without claiming that the name itself is absent.
This distinction matters because caches need to associate a stored negative result with the DNS state that the authoritative response actually reported.
The authority section supplies cache timing data
Authoritative negative responses commonly include the zone’s SOA record in the authority section. DNS standards use SOA data to derive the lifetime for negative caching.
The effective negative TTL is bounded by values carried in that response rather than being an arbitrary permanent decision made by the recursive resolver. Resolver implementations can also apply local limits or policy.
A cached error therefore has an expiration time. Once that entry expires, a later client query can cause the resolver to contact authoritative infrastructure again and discover a record that has since appeared.
A newly created record may remain temporarily invisible
Consider a client that requests api.example.test before the record exists. Its recursive resolver receives an authoritative negative answer and caches it.
An administrator then creates the record a few seconds later.
The authoritative servers can already return the new positive answer, yet the same recursive resolver may still return its cached negative result. Another resolver with no cached error may obtain the new record immediately.
This can produce apparently inconsistent results across networks:
resolver A: cached negative answer
resolver B: fresh positive answer
authoritative server: positive answerThe discrepancy can disappear without any further DNS change when resolver A’s negative cache entry expires.
Repeated retries do not force a recursive refresh
Applications sometimes retry a failed DNS lookup rapidly. Those retries do not necessarily cause new authoritative queries.
If the recursive resolver has a valid negative cache entry, repeated requests can be served from that entry. Increasing the retry rate can therefore add client activity without changing the DNS result.
A direct query to an authoritative server can be useful during diagnosis because it bypasses a recursive resolver’s cached result. It does not, however, clear the recursive cache used by normal clients.
The operational question is not only whether the authoritative zone now contains the record. It is also whether a resolver still holds a valid negative entry from an earlier query.
Negative caching protects DNS infrastructure
Absent names can receive substantial traffic. Typographical errors, stale application configuration, generated hostnames, broken service discovery, and automated scans can all create repeated queries for names that have no answer.
Without negative caching, every repeated request could travel through recursive and authoritative infrastructure. Caching a definitive error suppresses much of that duplicate traffic.
This effect is especially useful when many clients share a recursive resolver. One authoritative negative response can satisfy later requests from a large client population until the cached entry expires.
The mechanism therefore applies the same broad caching principle used for positive DNS data: reuse a valid prior result instead of repeating upstream work.
Resolver caches are not all synchronized
Different recursive resolvers can receive the same negative answer at different times. Their cache entries then expire at different times.
Some resolvers may also impose implementation-specific minimums, maximums, or other cache policies. Local operating-system and application caches can add further layers between a program and the recursive resolver.
As a result, DNS changes are not observed globally at one instant. A record added after earlier negative queries can appear at different times to different clients.
This is a cache-state effect, not evidence that authoritative servers must be returning different zone contents.
Pre-change planning can reduce the delay
For planned DNS work, operators often focus on lowering positive-record TTLs before changing an existing value. Negative caching needs separate consideration when a deployment depends on creating a name that previously did not exist.
If clients query that absent name before creation, they can populate negative caches. The relevant negative lifetime comes from the zone’s negative-answer timing data and resolver policy.
Avoiding premature queries can be useful when a new hostname must become visible promptly. Where that is not possible, deployment checks should account for cached negative responses rather than treating every post-change lookup failure as an authoritative-zone problem.
Negative caching makes absence a temporary reusable result
DNS treats a valid authoritative error as information that can be reused for a bounded period. That saves recursive and authoritative capacity, but it also means absence can persist in caches briefly after the authoritative data changes.
During diagnosis, comparing recursive and authoritative answers can separate stale negative cache state from current zone contents. The expiration of the cached error then determines when that resolver is able to fetch the new state.