Negative Caching and NXDOMAIN: How Resolvers Remember What Does Not Exist

Most people know DNS caches positive answers: look up a hostname once and the resolver remembers the address for the record's TTL. Far less understood is that resolvers also cache the absence of an answer. When you query a name that does not exist, or a name that exists but has no record of the type you asked for, the resolver remembers that failure too, and for a duration you control through the SOA record. This is negative caching, standardized in RFC 2308, and getting it wrong causes two classic headaches: new records that take hours to become visible, and broken lookups that linger long after you fixed them. This guide explains NXDOMAIN versus NODATA, where the negative TTL comes from, and how to tune it.

Two kinds of "no"

DNS has two distinct negative responses, and confusing them is a common source of debugging frustration.

• NXDOMAIN (name error): the queried name does not exist at all, in any record type. For example, querying typo.example.com when no such label was ever published.
• NODATA: the name exists, but there is no record of the type you asked for. The response code is NOERROR with an empty answer section. For example, example.com exists and has A records but you asked for its (nonexistent) SRV record.

You can tell them apart by the header status. NXDOMAIN shows status NXDOMAIN; NODATA shows status NOERROR with ANSWER: 0 and an SOA in the authority section.

# NXDOMAIN: the name itself does not exist
dig doesnotexist.example.com A

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 7781
;; AUTHORITY SECTION:
example.com.  3600  IN  SOA  ns1.example.com. host.example.com. 2026101401 7200 3600 1209600 3600

# NODATA: the name exists but has no AAAA
dig example.com AAAA

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9120
;; ANSWER: 0
;; AUTHORITY SECTION:
example.com.  3600  IN  SOA  ns1.example.com. host.example.com. 2026101401 7200 3600 1209600 3600

Notice that in both cases the authoritative server returns the zone's SOA record in the authority section. That SOA is not decoration; it carries the instructions for how long the negative answer may be cached.

Where the negative TTL comes from

Before RFC 2308 the SOA minimum field had been overloaded with several meanings over the years. RFC 2308 settled it: the last field of the SOA, the minimum, is the negative caching TTL. The actual time a resolver caches a negative answer is the lesser of two values: the SOA minimum field and the TTL of the SOA record itself. The RFC also caps the practical ceiling at 24 hours (86400 seconds), and values beyond a day have proven problematic in the wild.

Look at a SOA and read it left to right:

example.com.  IN  SOA  ns1.example.com. host.example.com. (
        2026101401  ; serial
        7200        ; refresh
        3600        ; retry
        1209600     ; expire
        3600 )      ; MINIMUM = negative cache TTL (seconds)

Why this bites you during launches

Imagine your SOA minimum is 86400 (one day). Someone (a monitoring tool, a user, a crawler) queries new.example.com before you create it. The world's resolvers now cache NXDOMAIN for that name for up to a day. You then add the record, but visitors whose resolvers cached the negative answer keep getting NXDOMAIN until that cache expires. The record is live, dig against the authoritative server proves it, yet real users cannot reach it. This is negative caching doing exactly what it was designed to do, and it is one of the most common "my DNS change is not propagating" complaints.

The reverse problem is positive: a high negative TTL reduces load because resolvers stop re-asking for names that do not exist (a surprisingly large share of real traffic is typos, stale links, and malware probing random labels). So the field is a tradeoff between launch agility and query efficiency.

Tuning the negative TTL

1. Lower the SOA minimum before a launch. Drop it to 300 to 900 seconds a day or two ahead of creating new names, the same way you lower a record TTL before a migration. This limits how long a premature NXDOMAIN can stick.
2. Raise it for stable zones. Once names are settled, a higher minimum (for example 3600) cuts needless repeat queries for junk names.
3. Never exceed a day. Stay at or below 86400; longer values are capped in practice and make mistakes painful.
4. Remember the cap rule. If your SOA record's own TTL is lower than the minimum field, the lower value wins for negative caching.

# Check the effective negative TTL a resolver will apply
dig nonexistent.example.com @8.8.8.8

;; AUTHORITY SECTION:
example.com.  300  IN  SOA  ns1.example.com. host.example.com. 2026101401 7200 3600 1209600 300
;;                   ^ the 300 here is the min(SOA TTL, SOA minimum) actually served

Negative caching and DNSSEC

In a DNSSEC-signed zone, "this name does not exist" must itself be provable, because an attacker could otherwise forge a denial. Signed zones use NSEC or NSEC3 records to cryptographically prove that no name exists between two sorted names, or that a name has no records of a given type. These authenticated denial records are cached under the same negative TTL rules, so your SOA minimum still governs how long a proven NXDOMAIN lives in resolver caches.

Quick diagnosis checklist

Negative caching is a feature, not a bug: it protects the whole system from drowning in lookups for things that do not exist. The trick is to lower the SOA minimum before you introduce new names and raise it once the zone is stable. When you add records and want to know whether a stale NXDOMAIN has cleared around the world, check the name across many resolvers with the Valla DNS propagation checker, and see the Valla DNS learning hub for companion guides on TTL strategy, SOA tuning, and DNSSEC that all shape how long "no" is remembered.