DNS Negative Caching: NXDOMAIN and NODATA
DNS negative caching is the practice of remembering that a DNS lookup found no answer, so a resolver can return that result without asking an authoritative server again. The two main negative results are NXDOMAIN, meaning the requested name does not exist, and NODATA, meaning the name exists but has no record of the requested type.
This caching improves performance and protects DNS servers from repeated lookups for names that are absent. It also explains a familiar incident: you create a new DNS record, but some clients continue receiving “name not found” for minutes or hours.
The problem negative caching solves
Without negative caching, every request for a nonexistent name would travel through the DNS system again. A typo such as api.exmaple.com, a missing service-discovery record, or a browser repeatedly retrying an unavailable hostname could produce the same expensive chain of queries over and over:
- A client asks its configured recursive resolver.
- The recursive resolver asks other DNS servers, eventually reaching the authoritative server for the domain.
- The authoritative server confirms that no answer exists.
- The resolver returns the negative result to the client.
The next identical request would repeat that work unless the resolver could cache the negative result. DNS therefore treats absence as cacheable information, not just the presence of an address.
NXDOMAIN and NODATA are different
NXDOMAIN is a DNS response code meaning that the queried domain name does not exist. For example, if cache.example.com has never been created, a lookup for its address record might return NXDOMAIN.
NODATA is not a response code. It describes a successful DNS response with no record of the requested type. The name exists, but that particular kind of record does not. For example, example.com might have an A record but no AAAA record. An AAAA lookup can then produce NODATA even though the name itself is valid.
This distinction matters when caching:
| Result | What is absent | What a cached result means |
|---|---|---|
| NXDOMAIN | The name itself | Treat the name as nonexistent |
| NODATA | The requested record type | Treat that type as absent for the name |
A resolver should not turn a cached NODATA result for AAAA into a claim that the whole name is absent. Likewise, NXDOMAIN is broader than “this one record type was missing.”
Where the lifetime comes from
A negative response normally includes an SOA record in its authority section. SOA, or Start of Authority, is the record that describes the authoritative DNS zone, including its primary nameserver, administrative contact, and timing fields.
The SOA supplies the lifetime for the negative answer. Two values are relevant:
- The SOA record’s own TTL, which says how long that SOA record may be cached.
- The SOA record’s MINIMUM field, which in modern DNS is used as the negative-caching TTL: the default number of seconds to remember an NXDOMAIN or NODATA result.
The effective negative-cache lifetime is the smaller of those two values:
effective negative TTL = min(SOA record TTL, SOA.MINIMUM)
The MINIMUM field has historical uses that can make its name confusing. Older DNS conventions used it as a default TTL for records without an explicit TTL. For negative caching, the relevant meaning is the duration attached to the negative response.
For example, an authoritative server might return an SOA with:
SOA TTL 3600 seconds
SOA.MINIMUM 600 seconds
The resolver may cache the negative result for at most 600 seconds. If the values were reversed, the effective lifetime would be 3600 seconds only if the SOA TTL were also at least that long; otherwise the smaller value would win.
As time passes, the resolver decreases the cached entry’s remaining TTL. It does not normally ask the authoritative server again until that lifetime expires. Different recursive resolvers can have different remaining lifetimes because they received the negative response at different times.
Why a new name can still look missing
Suppose a client asks for api.example.com before the name has been created. The authoritative server returns NXDOMAIN, and the recursive resolver caches it for 10 minutes.
An administrator then creates api.example.com and adds an address record. The authoritative server now knows the name exists, but the recursive resolver still has a valid cached statement saying that it does not. Until the negative TTL expires, that resolver can answer subsequent requests from its cache with NXDOMAIN.
The result often looks inconsistent:
- Queries through one resolver fail because it cached the old negative answer.
- Queries through another resolver succeed because it had no earlier lookup, or its cache entry has expired.
- Direct queries to an authoritative nameserver succeed, while ordinary application lookups fail.
There may also be another cache between the application and the recursive resolver. Operating systems, language runtimes, service-discovery libraries, browsers, and local DNS forwarders can retain failures for their own periods. The authoritative change therefore does not instantly erase every previously cached negative answer.
Creating a record changes the authoritative answer; it does not invalidate negative answers already held by recursive resolvers.
What to look for during an incident
Terms such as NXDOMAIN, “name does not exist,” “host not found,” or “no such host” often indicate a negative DNS result. An empty answer with a successful DNS status may instead be NODATA, especially when an application asks for a record type the name does not have.
When investigating, compare the resolver used by the failing client with an authoritative response, and inspect the response’s SOA and remaining TTL. A newly created name may be configured correctly yet remain invisible until the cached NXDOMAIN or NODATA entry expires. After that point, the resolver queries again and can learn the new authoritative answer.