DNS Negative Caching for NXDOMAIN and NODATA

10 Sep 2026 networking

DNS negative caching stores the fact that a DNS lookup found nothing, so a resolver can answer repeated failed lookups without querying an authoritative DNS server each time. It applies mainly to two responses: NXDOMAIN, meaning the requested domain name does not exist, and NODATA, meaning the name exists but has no record of the requested type.

The problem negative caching solves

Without negative caching, every typo, missing service, or not-yet-created hostname would trigger another recursive DNS lookup. A busy application repeatedly requesting api-new.example.com could cause the same chain of queries to be repeated across recursive resolvers and authoritative servers.

Negative caching remembers the failure for a limited time. During that time, the resolver can immediately return the same negative result. This reduces DNS traffic and latency just as ordinary caching does for successful answers.

You may have encountered the mechanism in an incident where a hostname was created correctly but clients continued to report errors such as:

getaddrinfo: Name or service not known

or:

NXDOMAIN

The hostname may exist at the authoritative server already. A recursive resolver, operating system, or application can still have a cached record saying that it did not exist.

NXDOMAIN and NODATA are different

NXDOMAIN is a DNS response code that says the queried name does not exist. If api-new.example.com returns NXDOMAIN, the response is asserting that the name itself is absent from the DNS namespace.

NODATA is a successful DNS response with no answer record for the requested type. For example, example.com might exist and have an A record, but no AAAA record. A query for its AAAA record can therefore produce NODATA rather than NXDOMAIN.

That distinction matters to the cache key:

• An NXDOMAIN result is about the name's existence.
• A NODATA result is about a particular name and record type, such as AAAA or MX.

A cached NODATA result for AAAA should not prevent a later lookup for an A record. Conversely, an NXDOMAIN result says more broadly that the queried name was absent when checked.

What the negative response contains

A DNS response normally has an answer section, but a negative response has no requested record there. Instead, an authoritative negative response generally includes an SOA record in its authority section. SOA means Start of Authority: it identifies the DNS zone's authoritative information and includes timing fields for zone administration.

For negative caching, the important information is the SOA record and its TTL. The SOA provides evidence that the authoritative server checked the zone and found either the name or the requested record type missing. The resolver stores that negative conclusion along with metadata such as:

• the DNS name and record type involved;
• whether the result was NXDOMAIN or NODATA;
• the DNS class, normally IN for Internet DNS;
• the expiration time for the cached negative result.

The SOA itself is not an answer for the missing hostname. It supplies the authority and the lifetime rules for remembering the absence.

How the TTL controls later lookups

A TTL, or time to live, is a countdown in seconds that tells a cache how long information may be reused. Negative responses do not have an answer record whose TTL could be used, so DNS negative caching derives the lifetime from the SOA information.

Under the rules defined for DNS negative caching, the usable negative TTL is normally the smaller of:

1. the SOA record's own TTL; and
2. the SOA record's MINIMUM field.

Resolvers can also apply their own configured upper limits. The resulting value is the maximum time the resolver should treat the negative result as valid.

Suppose an authoritative server returns NXDOMAIN with an effective negative TTL of 300 seconds. A recursive resolver stores that result and starts counting down from the moment it caches the response:

1. A client asks for api-new.example.com.
2. The resolver queries an authoritative server and receives NXDOMAIN.
3. The resolver stores the negative result for up to 300 seconds.
4. Another client asks for the same name during that period.
5. The resolver returns NXDOMAIN from its cache without asking the authoritative server.
6. After the countdown reaches zero, the resolver discards the negative entry and can query again.

The TTL is not measured from when the hostname is created, and it is not automatically restarted by the authoritative server. It is measured from when each caching resolver received and stored the negative response. A downstream operating-system or application cache may then impose another, usually shorter, caching period.

Why a new hostname can appear to be missing

Consider this sequence:

• At 10:00, someone tests payments.example.com before its DNS record has been published.
• The recursive resolver receives NXDOMAIN and caches it for one hour.
• At 10:05, the A or CNAME record is added at the authoritative DNS provider.
• At 10:06, clients using that same recursive resolver ask for the hostname.

The resolver still has a valid cached statement that the name did not exist. It does not recheck the authoritative server merely because the zone has changed. Those clients continue to receive NXDOMAIN until the negative entry expires, or until an administrator clears the relevant caches.

Other resolvers may see the new record immediately if they did not make the earlier failed query. This is why DNS changes can appear inconsistent across networks: the authoritative data may be correct, while different recursive resolvers hold different cached histories.

The practical lesson is to publish a hostname before clients are likely to query it, and to choose negative-cache lifetimes with care. A long negative TTL reduces repeated failed traffic, but it also extends the period during which a mistaken lookup or premature deployment can hide a newly created name.