What Is Negative Caching in DNS?

Here's a scenario that confuses even experienced developers. You're setting up api.example.com. Before adding the record, you run a quick lookup to see if it exists — it doesn't. You create the record, the authoritative server returns it instantly, and the record's TTL is only 60 seconds. Yet your laptop keeps saying the name doesn't exist for the next half hour. The culprit is negative caching: resolvers remember that a name didn't exist, and the timer for that memory has nothing to do with the TTL on the record you just created.

This article explains what negative caching is, the two kinds of negative answer DNS caches, how the negative TTL is calculated from the SOA record, how DNSSEC changes the picture, and how to avoid being bitten by it during deployments. For background on positive caching, see what DNS caching is and how it works.

What Is Negative Caching?

Negative caching is the practice of storing the fact that a DNS lookup returned no data, so the resolver doesn't have to ask the authoritative servers again for every repeated query. It's defined in RFC 2308, which made it mandatory for resolvers after it had been optional in the original DNS specifications.

The motivation is simple: queries for names that don't exist are extremely common. Typos, misconfigured software polling for hostnames that were never created, search-domain expansion, browsers probing for DNS interception, and malware generating random domains all produce a constant stream of lookups that fail. Without negative caching, every one of those would travel all the way to an authoritative server.

The Two Kinds of Negative Answer

RFC 2308 distinguishes two cases, and resolvers cache them separately.

NXDOMAIN: the name doesn't exist

An NXDOMAIN response (RCODE 3, "Name Error") means there are no records of any type at that name. Here's one from the .com registry for an unregistered domain:

dig nonexist-zz9q-test.com A @1.1.1.1

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 19678
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; AUTHORITY SECTION:
com. 900 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1790837174 1800 900 604800 900

The answer section is empty, and the authority section contains the SOA record of the zone that would have held the name. That SOA is what tells the resolver how long to cache the negative result. A resolver caching an NXDOMAIN treats it as covering every record type at that name.

NODATA: the name exists, but not that record type

A NODATA response has status NOERROR but an empty answer section. It means the name exists, but it has no records of the type you asked for:

dig iana.org SRV @8.8.8.8

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9057
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; AUTHORITY SECTION:
iana.org. 1800 IN SOA sns.dns.icann.org. noc.dns.icann.org. 2026092401 7200 3600 1209600 3600

NODATA is cached per name and type. A cached "no SRV records at iana.org" doesn't stop the resolver from answering an A query for the same name.

The post on NXDOMAIN, SERVFAIL, and REFUSED responses covers the full set of response codes; NODATA isn't a separate code, which is why it's easy to miss in logs.

How the Negative TTL Is Calculated

A negative answer has no record of its own, so it has no TTL of its own either. Instead, RFC 2308 says the negative cache time is the lower of two values:

1. The TTL of the SOA record itself.
2. The MINIMUM field of the SOA record — the last of the seven numbers in its data.

Look again at the iana.org response above. The SOA record's TTL is 1800, and the last field in its data is 3600. The negative TTL is therefore 1800 seconds. Authoritative servers apply this rule before responding, so the TTL shown on the SOA in the authority section is already the negative TTL the resolver will use.

In a zone file, the relevant pieces look like this:

$TTL 3600
@   IN  SOA  ns1.example.com. hostmaster.example.com. (
        2026100101 ; serial
        7200       ; refresh
        3600       ; retry
        1209600    ; expire
        900 )      ; minimum — used as the negative caching TTL

The MINIMUM field once meant "the minimum TTL for all records in the zone," but RFC 2308 redefined it as the negative caching TTL. That legacy name is why so many zones still have oddly large values in it — values originally chosen for a different purpose, like 86400, can mean a nonexistent name gets cached as missing for a full day.

You can check any zone's negative TTL with a single command:

dig +noall +answer example.com SOA

Take the smaller of the record's TTL (second column) and the last number on the line. That's how long a "doesn't exist" answer from that zone can be remembered.

Resolver Caps on Negative TTLs

Resolvers apply their own upper limits so a badly configured SOA can't keep a name hidden for days. RFC 2308 suggests that one to three hours works well as a maximum.

In BIND, the cap is max-ncache-ttl, which defaults to three hours:

// named.conf
options {
    max-ncache-ttl 900;   // never cache negative answers longer than 15 minutes
};

In Unbound, the equivalent is cache-max-negative-ttl, which defaults to one hour:

# unbound.conf
server:
  cache-max-negative-ttl: 300

Either setting shortens how long negative answers live on resolvers you run. Lowering them a lot increases traffic to authoritative servers, but on an internal resolver used by developers, a few minutes is a reasonable trade-off.

Client operating systems have caps too. The Windows DNS Client keeps negative entries only briefly by default, controlled by the MaxNegativeCacheTtl registry value under HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters. You can see cached negative entries with PowerShell:

Get-DnsClientCache | Where-Object { $_.Status -ne 0 } |
    Select-Object Entry, Type, Status, TimeToLive

This lists cache entries that represent failed lookups — names that didn't exist or had no data — along with their remaining time.

Negative Caching and DNSSEC

DNSSEC complicates negative answers, because "nothing here" has to be provable. A signed zone returns NSEC or NSEC3 records that prove a name or type doesn't exist, along with signatures over them. That has two consequences for caching.

Aggressive use of NSEC

An NSEC record says, in effect, "there are no names between alpha.example.com and delta.example.com." Under RFC 8198, a validating resolver that has cached such a record can answer queries for beta.example.com or charlie.example.com with NXDOMAIN directly from cache, without asking the authoritative server at all. This is called aggressive negative caching, and it's especially effective against floods of random-subdomain queries. The negative TTL still applies to the NSEC records themselves.

Compact denial of existence

Some large DNS providers that sign zones on the fly use a technique called compact denial of existence. Instead of NXDOMAIN, they return NODATA with a minimal NSEC record for nonexistent names. Cloudflare-hosted zones behave this way:

dig nothere123.example.com A @1.1.1.1

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61221
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; AUTHORITY SECTION:
example.com. 1800 IN SOA elliott.ns.cloudflare.com. dns.cloudflare.com. 2415949263 10000 2400 604800 1800

The status is NOERROR even though the name was never created. For caching purposes the result is still negative and still lives for the SOA-derived TTL. But if a monitoring tool only alerts on NXDOMAIN, it may silently miss missing records on these providers. Check for an empty answer section, not just the RCODE. For more on how signing works in general, see what DNSSEC is.

Failure Caching Is Different

Negative caching is about authoritative "no" answers. Resolution failures — SERVFAIL, timeouts, unreachable nameservers — are a separate category. RFC 2308 allowed resolvers to cache them for up to five minutes, and RFC 9520 now requires resolvers to cache resolution failures for at least a short time (at least one second, up to five minutes) so that a broken zone doesn't trigger a storm of retries. If you fix a broken delegation and some resolvers still fail for a few minutes, failure caching is the reason.

Real-World Problems Caused by Negative Caching

1. Querying before creating. The classic trap. Checking whether staging.example.com exists, then creating it, means every resolver you queried now has a negative entry. The new record won't appear until that entry expires, however low its own TTL is.
2. Certificate validation timing. ACME clients that create a TXT record and then immediately trigger validation can fail if a resolver cached the absence of that TXT record during a previous attempt. Waiting out the negative TTL, or using a fresh record name, solves it. The DNS-01 challenge post covers this workflow.
3. Service discovery in containers. Short-lived services that register DNS names after clients start looking for them can be invisible for the negative TTL, which in some internal DNS setups is surprisingly long.
4. Huge SOA MINIMUM values. Zones with a MINIMUM of 86400 can cause a day of "doesn't exist" for any record created after someone looked it up. Resolver caps soften this, but don't rely on them.

If a new record isn't resolving, why is my domain not resolving after a DNS change walks through the full diagnostic path, of which negative caching is one branch.

Best Practices

• Set the SOA MINIMUM deliberately. 300 to 3600 seconds suits most zones. Lower values mean new records appear faster; higher values reduce query load for typo traffic.
• Create records before anyone queries them. In deployment pipelines, add the DNS record as one of the first steps, before any health checks or clients try to resolve it.
• Test against the authoritative server. dig +norecurse newname.example.com @ns1.example.com bypasses every cache, so you can confirm the record exists even while resolvers still have a negative entry.
• Flush what you can. Local OS and browser caches can be cleared; see how to flush the DNS cache. Public resolvers can't be flushed from your side, so you'll need to wait out the negative TTL.

---

Negative Caching FAQ

Conclusion

Negative caching is DNS remembering what isn't there. It saves authoritative servers from an enormous volume of repeated failing queries, but it also creates one of the most confusing delays in DNS operations: a brand new record that stays invisible because someone looked it up too early. The duration comes from your zone's SOA record — the lower of its TTL and its MINIMUM field — not from the record you just created.

Once you know that, the fixes are straightforward. Set a sensible SOA MINIMUM, create records before anything tries to resolve them, verify new names against your authoritative server directly, and remember that a NOERROR with an empty answer is just as negative as an NXDOMAIN.

Here are some useful references for going deeper on negative caching:

1. RFC 2308: Negative Caching of DNS Queries (DNS NCACHE) — the specification for NXDOMAIN and NODATA caching and the SOA MINIMUM redefinition.
2. RFC 8198: Aggressive Use of DNSSEC-Validated Cache — how validating resolvers synthesize negative answers from cached NSEC records.
3. RFC 9520: Negative Caching of DNS Resolution Failures — requirements for caching SERVFAIL and timeout conditions.
4. BIND 9 Documentation: BIND 9 Administrator Reference Manual — reference for max-ncache-ttl and related cache options.
5. NLnet Labs: Unbound Documentation — reference for cache-max-negative-ttl and other Unbound cache settings.