What is negative caching in DNS?

Negative caching in DNS is when a resolver remembers that something doesn't exist. If a resolver asks for new.example.com and the authoritative server replies that there's no such name (NXDOMAIN), or that the name exists but has no record of the requested type (NODATA), the resolver stores that "no" answer and gives it to anyone else who asks, without checking again, until the negative cache time runs out. That time comes from your zone's SOA record: it's the lower of the SOA record's own TTL and the last field in the SOA, often called the minimum or negative TTL.

Negative caching protects authoritative servers from floods of queries for names that don't exist, and it makes failed lookups faster. It's also behind one of the most common DNS surprises: you create a new record, but it doesn't seem to work for a while because someone looked it up before it existed. In this article you'll learn what kinds of negative answers there are, how the cache time is calculated, how to see negative caching with dig, how resolvers cap it, how DNSSEC changes things, and how to avoid getting caught out.

Two Kinds of Negative Answer

A DNS query can come back "empty" in two different ways, and both are cached.

NXDOMAIN: The Name Doesn't Exist

NXDOMAIN (non-existent domain, response code 3) means there are no records of any type at that name. For example, if your zone has no typo.example.com, a query for it returns NXDOMAIN.

$ dig typo.example.com A

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

;; QUESTION SECTION:
;typo.example.com.              IN      A

;; AUTHORITY SECTION:
example.com.            300     IN      SOA     ns1.example.com. hostmaster.example.com. 2026102201 3600 900 1209600 300

NODATA: The Name Exists, but Not That Type

NODATA isn't a separate response code. It's a NOERROR response with an empty answer section. It means the name exists, perhaps with an A record, but there's no record of the type you asked for. A common example is asking for AAAA on a name that only has IPv4:

$ dig www.example.com AAAA

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

;; AUTHORITY SECTION:
example.com.            300     IN      SOA     ns1.example.com. hostmaster.example.com. 2026102201 3600 900 1209600 300

The difference matters when caching. An NXDOMAIN tells the resolver that nothing exists at the name. A NODATA only applies to that one name and type, so a cached NODATA for AAAA doesn't stop the resolver answering A queries for the same name.

	NXDOMAIN	NODATA
Response code	NXDOMAIN (3)	NOERROR (0)
Answer section	Empty	Empty
Meaning	No records of any type at this name	Name exists, but not with this record type
What gets cached	"This name doesn't exist"	"This name has no records of this type"
SOA in authority section	Yes	Yes

How Long Negative Answers Are Cached

Positive answers carry their own TTL. Negative answers have nothing to attach a TTL to, so RFC 2308 says the authoritative server includes the zone's SOA record in the authority section of the response, and the resolver works out the negative TTL from it.

The SOA Minimum Field

Here's a typical SOA record:

example.com.  3600  IN  SOA  ns1.example.com. hostmaster.example.com. (
                2026102201 ; serial
                3600       ; refresh
                900        ; retry
                1209600    ; expire
                300 )      ; minimum (negative caching TTL)

The last field was originally the "minimum TTL" for every record in the zone. RFC 2308 redefined it as the negative caching TTL. The negative answer's cache time is the lower of:

• The TTL of the SOA record itself (3600 here), and
• The minimum field (300 here).

So negative answers from this zone are cached for 300 seconds, or five minutes. That's why the SOA in the dig output above shows a TTL of 300 rather than 3600: the authoritative server has already lowered it to the negative caching time.

Watching the Negative Cache Count Down

If you query a caching resolver twice, you'll see the TTL in the authority section drop between queries, just as positive TTLs do. That tells you the answer is coming from the cache:

$ dig @1.1.1.1 typo.example.com A +noall +authority
example.com.            300     IN      SOA     ns1.example.com. hostmaster.example.com. 2026102201 3600 900 1209600 300

$ sleep 20; dig @1.1.1.1 typo.example.com A +noall +authority
example.com.            280     IN      SOA     ns1.example.com. hostmaster.example.com. 2026102201 3600 900 1209600 300

Public resolvers run many separate caches behind one address, so you may not always hit the same one, but the countdown is usually visible.

You can check what negative TTL your own zone advertises by looking at the SOA directly:

dig example.com SOA +noall +answer

The negative caching time is the smaller of the TTL column and the last number in the record.

Choosing a Value

Negative TTL	Effect
60 to 300 seconds	New records become visible quickly after a failed lookup; slightly more queries for non-existent names
900 to 3600 seconds	A reasonable middle ground for zones that rarely change
More than 3600 seconds	Fewer queries, but new records can be hidden for hours; usually capped by resolvers anyway

For most zones, somewhere between 300 seconds and one hour works well. If you frequently add new hostnames, such as for preview deployments or customer subdomains, lean towards the lower end.

To change it, edit the last field of the SOA. On a managed DNS provider, look for a "negative TTL", "SOA minimum" or "NXDOMAIN TTL" setting; some providers fix it at a set value and don't let you change it.

Resolver Limits on Negative Caching

Resolvers don't always trust the value you set. Most cap the negative cache time to stop a misconfigured zone from causing very long-lived failures:

Resolver	Setting	Default cap
BIND	max-ncache-ttl	10800 seconds (3 hours)
Unbound	cache-max-negative-ttl	3600 seconds (1 hour)
Public resolvers	Not configurable by you	Varies by provider

You can adjust these on your own resolvers. In BIND's named.conf:

options {
    max-ncache-ttl 900;
};

In Unbound's unbound.conf:

server:
    cache-max-negative-ttl: 900

Lowering the cap on an internal resolver can be useful in environments where new names appear all the time, such as development networks.

Operating System and Browser Caches

Negative answers can also be cached closer to the user. Operating system resolvers, such as Windows' DNS Client service, macOS's mDNSResponder and Linux's systemd-resolved, may cache negative answers for their own periods, which can differ from the zone's setting. Browsers have short-lived internal DNS caches too. When troubleshooting, flush these as well as checking the resolver.

Caching Failures: SERVFAIL

A third kind of "no" is a failure rather than a negative answer. When a resolver can't get a usable answer at all, for example because every authoritative server timed out or DNSSEC validation failed, it returns SERVFAIL.

Resolvers cache failures briefly, so they don't hammer unreachable servers. RFC 2308 allowed this for up to five minutes, and RFC 9520, published in 2023, now requires resolvers to cache resolution failures, also for no more than five minutes. In practice, after fixing a broken delegation or DNSSEC problem, you may need to wait a few minutes for resolvers to try again.

Negative Caching and DNSSEC

With DNSSEC, negative answers are signed too. The authoritative server includes NSEC or NSEC3 records that prove, cryptographically, that a name or type doesn't exist. These proofs describe ranges: an NSEC record says, in effect, "there are no names between alpha.example.com and delta.example.com".

RFC 8198 introduced aggressive use of DNSSEC-validated cache. A validating resolver that has cached such a range can answer NXDOMAIN for any name in it without asking the authoritative server at all. That's very efficient against floods of random non-existent names, a common pattern in some DDoS attacks.

In Unbound, it's enabled with:

server:
    aggressive-nsec: yes

Recent BIND versions support the same behaviour through the synth-from-dnssec option; check the default for your version. One consequence is that an NSEC range can be cached for its own TTL, so adding a name inside a cached range is subject to the same delay as any other negative answer.

The Classic Negative Caching Trap

Negative caching causes a familiar problem:

1. You plan to add shop.example.com.
2. Before creating it, you, a colleague or an automated checker looks it up, perhaps to see whether it already exists.
3. The resolver caches the NXDOMAIN.
4. You create the record.
5. You look it up again, and still get NXDOMAIN, because the resolver is serving its cached "no" answer.

The record is fine, and the authoritative server returns it. The resolver simply hasn't forgotten yet. Confirm by asking an authoritative nameserver directly, which never uses a cache:

# Find the zone's nameservers
dig example.com NS +short

# Ask one of them directly
dig @ns1.example.com shop.example.com A +short

If the authoritative server returns the new address and your normal resolver doesn't, negative caching is the cause.

How to Avoid It

• Don't look up names before they exist, especially through the resolver your users or certificate tools will use.
• Create records before you need them. Add DNS records for a launch well ahead of time.
• Keep the SOA minimum modest, such as 300 to 900 seconds, if you add names often.
• Watch out for ACME and certificate tools. Issuing a certificate right after creating a record can fail if the CA's resolver cached an earlier negative answer. Waiting for the negative TTL and retrying usually fixes it.

Clearing a Negative Cache Entry

If you run the resolver, you can flush specific names. In BIND:

sudo rndc flushname shop.example.com

In Unbound, flush the name, or all cached negative answers:

sudo unbound-control flush shop.example.com
sudo unbound-control flush_negative

On a local machine, flush the operating system cache. On Windows:

Clear-DnsClientCache

On macOS:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

On Linux with systemd-resolved:

resolvectl flush-caches

Some public resolvers, including Google Public DNS and Cloudflare's 1.1.1.1, provide web pages where you can request a cache purge for a specific name. Otherwise, the only option is to wait for the negative TTL to expire.

Why Negative Caching Is Worth It

It's easy to see negative caching as an annoyance, but DNS would struggle without it. A huge share of DNS queries are for names that don't exist: typos, old links, software probing for optional records, malware generating random domains, and attackers sending random-subdomain floods. Without negative caching, every one of those queries would reach authoritative servers, including the root and TLD servers. Caching the "no" answers keeps that load manageable and makes failed lookups return quickly for users.

---

FAQ: Negative Caching in DNS

---

Conclusion

Negative caching means resolvers remember "no" answers, both NXDOMAIN for names that don't exist and NODATA for missing record types. The cache time comes from your zone's SOA record, using the lower of its TTL and its minimum field, and resolvers usually apply their own cap on top. It keeps enormous volumes of pointless queries away from authoritative servers and makes failed lookups fast.

The main thing to remember is that a name looked up before it exists can stay "missing" for a while after you create it. Keep the SOA minimum modest, create records ahead of time, and when a new name doesn't resolve, check an authoritative nameserver directly before assuming something is broken. In most cases, the record is fine and the cache just needs a few minutes to catch up.