arthrop0d

Brief articles on varied topics.

DNS Negative Caching: NXDOMAIN, NODATA, and SOA TTLs

networking

DNS negative caching is the practice of caching a DNS answer that says something does not exist. It records either NXDOMAIN, meaning the queried domain name does not exist, or NODATA, meaning the name exists but has no record of the requested type.

This avoids repeatedly asking authoritative DNS servers the same question about missing data. It also explains a common incident: you create a DNS record, but some clients continue receiving “not found” answers for minutes afterward.

The problem negative caching solves

Without negative caching, every lookup for a typo, an unconfigured service, or a record type that is not present would travel through a recursive resolver to an authoritative server. Repeated misses would add latency and unnecessary load, especially for names that are requested frequently.

A recursive resolver is the DNS service that looks up answers on a client’s behalf and usually caches the results. An authoritative server is the server responsible for the data in a particular DNS zone, such as example.com.

Positive caching stores answers such as “api.example.com has address 192.0.2.10.” Negative caching stores answers such as “old-api.example.com does not exist.” Both kinds of cached result have an expiration time.

NXDOMAIN and NODATA mean different things

Consider a query for an address record:

api.example.com.  A

There are two important ways for the lookup to find no address record:

NODATA is not usually a literal DNS status code. It is an answer with no record of the requested type, accompanied by information that proves the name exists and that the requested type is absent. NXDOMAIN is an explicit DNS response code.

The distinction matters when someone changes the zone. Creating api.example.com A ... should invalidate a cached NODATA result for an A query once that result expires. A cached NXDOMAIN result says the name itself was absent, so it can prevent lookups for newly created records at that name until its negative cache lifetime ends.

How a resolver caches an absence

A negative response normally includes an SOA record in its authority section. SOA, or Start of Authority, is the DNS record that describes the zone’s authoritative settings. In a negative response, the SOA supplies the information a resolver needs to decide how long the absence may be trusted.

The resolver stores the negative result along with details such as:

For a later matching query, the resolver can answer from this cache instead of contacting the authoritative server again. The client may see an NXDOMAIN or NODATA response that was generated by the recursive resolver, rather than a fresh response from the zone’s authoritative server.

The cached result is not permanent. Its remaining lifetime counts down from the time the resolver received it. A resolver can also impose local limits, such as a maximum negative-cache duration, but it cannot normally make the result valid beyond the authoritative lifetime it was given.

How the SOA controls the lifetime

The negative-cache lifetime is derived from the SOA information returned with the negative response. In the standard procedure described by RFC 2308, it is the lower of these two values:

  1. the SOA record’s own TTL in the response; and
  2. the SOA record’s MINIMUM field.

A TTL, or time to live, is a duration in seconds for which a cached DNS result may be used. The SOA MINIMUM field historically had other meanings, but for negative caching it is used as the zone’s default upper bound for how long an absence may be cached.

For example, suppose a negative response contains an SOA with:

example.com. 300 IN SOA ns1.example.com. hostmaster.example.com. (
                 2025030801 3600 600 86400 900
)

Here the SOA record’s TTL might be 300 seconds, while its final field, 900, is the SOA MINIMUM value. The negative response’s cache lifetime is therefore 300 seconds: the smaller value wins. If the SOA record’s TTL were 1800 seconds instead, the negative lifetime would be 900 seconds.

Zone operators commonly configure this negative TTL deliberately. A short value lets newly created names become visible sooner, at the cost of more authoritative queries. A long value reduces repeated queries, but makes corrections and new deployments wait longer to be observed by cached resolvers.

Why creating the record does not immediately fix it

Suppose a client requests service.example.com A at 12:00. The name has not been created yet, so the resolver receives NXDOMAIN and caches it for 300 seconds. At 12:01, you add the name and its A record to the authoritative zone.

The resolver does not automatically learn about that change. It has a valid cached statement saying the name was absent, with four minutes remaining. Until that timer expires, it can continue returning NXDOMAIN. The new record becomes usable through that resolver only after the negative entry is discarded and the resolver asks again.

The same pattern occurs with NODATA. If the name existed but had no A record when the resolver cached the response, adding an A record does not update the already cached NODATA result.

DNS changes are therefore not simply “propagated” from one central server. Different recursive resolvers may have fetched the old negative answer at different times, so they can stop returning it at different times.

This is why an incident report may show “DNS record created, but clients still get NXDOMAIN.” Checking with an authoritative server can show the new record while checking through a recursive resolver still shows the cached absence. Waiting for the negative TTL—or clearing the relevant cache where that is possible—is usually what resolves the discrepancy.

← All articles