Negative DNS Caching: Why Your Fix Still Looks Broken

You create the missing DNS record. The control panel looks correct. Your colleague can reach the service. Your own computer still insists that it does not exist.

The fix may be published while a resolver is faithfully remembering the earlier failure.

Negative DNS caching stores answers about absence: a name does not exist, or a particular record type is unavailable. Remembering that answer saves repeated lookups. It also creates an awkward interval when reality has changed but the cached answer has not. [1]

The useful question is not simply “Has DNS propagated?” It is: which component is answering, what did it cache, and how long is that answer still usable?

DNS Can Remember “Nothing Here”

A resolver can cache an address such as an A record. It can also cache the knowledge that an authoritative lookup found no name or no requested data. Repeated queries can then be answered without asking the authoritative servers again. [1]

Think of a receptionist keeping a note that says “No tenant at this address.” A new tenant moving in does not instantly replace every receptionist’s note.

This differs from receiving an old IP address. Our DNS migration troubleshooting guide covers that broader problem. Here, the remembered answer is absence, and the timer controlling it may have nothing to do with the new address record’s TTL.

NXDOMAIN, NODATA, and SERVFAIL Are Different Clues

A DNS query asks about a name and a record type. The distinction is important when interpreting a response. [12]

Result	What it tells you	Example
NXDOMAIN	The response says the relevant name does not exist.	The name api.example.net is absent.
NODATA	A successful lookup establishes that the requested record type is absent; this is normally NOERROR with suitable negative-answer evidence.	The name has an A record but no AAAA record.
SERVFAIL	Resolution failed; it does not establish that the name is absent.	A resolver cannot complete resolution or validate the required DNSSEC data.

NXDOMAIN concerns the name, so a cached name error can affect queries for different types. NODATA is specific to the requested type: “no AAAA” does not mean “no A.” [1]

An empty answer section alone is not enough to diagnose NODATA. Referrals and alias chains require interpretation too. Follow the CNAME target where applicable, and inspect the response status and authority information.

SERVFAIL belongs to a different category: failure to resolve, rather than a reliable answer about nonexistence. RFC 9520 requires caching of resolution failures, including DNSSEC validation failures, with specified restrictions. These failure entries must be retained for at least one second and no longer than five minutes under that specification. They do not use the ordinary SOA-derived negative-answer timer described next. [2]

Which TTL Controls a Negative Answer?

For conventional authoritative NXDOMAIN and NODATA answers, the zone’s Start of Authority (SOA) record supplies the timing information. The starting negative TTL is the lesser of:

• The SOA record’s own TTL.
• The SOA record’s MINIMUM field.

In simplified form:

Negative TTL = min(SOA record TTL, SOA.MINIMUM)

This is defined by RFC 2308 and explained in DNS-provider documentation, including Amazon Route 53’s SOA guidance. The authoritative negative response carries the resulting TTL on its SOA record. [1, 3]

The MINIMUM field is not the minimum lifetime of every record in a modern zone. Its relevant role here is controlling negative caching.

Resolver policy can also constrain cache retention. BIND, for example, exposes negative-cache retention controls. The SOA-derived calculation is therefore not a promise that every client and resolver will behave identically. [4]

Our TTL explainer covers the broader concept. The crucial point is that a newly created A record’s TTL governs caching of that positive answer, not an earlier cached denial.

A 60-Second Record With a 15-Minute Problem

Suppose the zone’s SOA record has a configured TTL of 3,600 seconds and MINIMUM of 900 seconds. A negative answer initially has a TTL of 900 seconds: 15 minutes.

Assume one resolver caches that answer at 10:00, honors this timer, and receives no replacement data before expiry:

Time	What happens	What this resolver can still remember
10:00	A lookup for api.example.net returns NXDOMAIN.	The negative answer is cached for 900 seconds.
10:02	You publish the missing A record with TTL 60.	The earlier negative entry has about 780 seconds remaining.
10:06	You query through the same cached path.	About 540 seconds remain on the negative entry.
10:15	The original negative entry expires.	A subsequent successful lookup can discover the new A record.

The countdown started when the negative answer was cached, not when you fixed the record. The 60-second positive TTL cannot retroactively shorten the old entry.

These are illustrative times, not a prediction for a particular provider. Other caches can have different histories. A resolver that first asks after publication may return the new record while another still remembers the earlier absence.

Lowering the negative TTL after the original answer was cached does not rewrite that cached copy either.

Diagnose the Answering Layer

The following command patterns use dig, a DNS lookup utility that must be installed separately on some systems. Replace AUTH_IP, RESOLVER_IP, and the example name before running them. The uppercase labels are placeholders for server addresses, not literal servers to contact. [5]

First, check the active authoritative servers. Use the servers actually delegated for your zone, rather than relying only on a control-panel screenshot. Query each relevant server and record type:

dig @AUTH_IP api.example.net. A +norecurse +noall +comments +answer +authority
dig @AUTH_IP api.example.net. AAAA +norecurse +noall +comments +answer +authority

The trailing dot makes the name absolute. +norecurse clears the recursion-desired bit. Check that you reached a server authoritative for this name, including the expected aa flag and response data. If authoritative servers disagree, publication or zone consistency needs attention before caching becomes the explanation.

Next, ask the recursive resolver used by the failing client:

dig @RESOLVER_IP api.example.net. A +noall +comments +answer +authority

If authoritative answers contain the new A record while this resolver returns NXDOMAIN, a cached negative answer is a strong possibility. It is not the only possibility: DNS views, filtering policies, or a different resolution path can also produce different results.

Read the status and the SOA timer. A shortened, fictional cached response six minutes into our example might include:

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4242
;; AUTHORITY SECTION:
example.net. 540 IN SOA ns1.example.net. hostmaster.example.net. 2026110601 3600 600 604800 900

The 540 immediately after example.net. is the remaining SOA TTL in this response. The final 900 is the SOA MINIMUM field, which has not been counting down. Confusing them can make a normally expiring entry look permanently stuck.

Avoid relying on dig +short alone for this investigation: terse output can hide the status and authority data that distinguish the cases. ISC’s dig documentation describes the display options used here. [5]

Why Flushing Your Computer May Change Nothing

On Windows, these commands inspect and clear the DNS Client resolver cache:

ipconfig /displaydns
ipconfig /flushdns

Run them in an appropriate Command Prompt, with administrator permissions where required. Microsoft explicitly documents clearing negative entries through /flushdns. [6]

That clears a local cache. It does not purge an ISP resolver, a company forwarder, or a public recursive service. If the next lookup asks a resolver that still holds the negative answer, the computer can receive it again immediately.

The application may also use a different path. A browser configured for DNS over HTTPS can use a resolver different from the operating system’s usual choice; Firefox documents its own DoH behavior. VPNs and private DNS arrangements can further change which view is relevant. [7]

Match your test to the failing application’s actual resolver and network context. A successful answer from an unrelated public resolver is useful comparison evidence, not proof that the application is querying it.

“But Nobody Queried This Exact Name Before”

DNS caching can be broader than a notebook of individual questions.

RFC 8020 describes NXDOMAIN cuts: a cached denial of a name’s existence can also establish nonexistence beneath that name. A lookup for a newly created descendant can therefore encounter a previously cached denial at an ancestor. [8]

DNSSEC-validating resolvers can also use cached NSEC or NSEC3 proofs to synthesize answers about covered names or record types. RFC 8198 defines this aggressive use of validated cache; RFC 9077 refines the relevant proof TTL behavior. [9, 10]

These mechanisms reduce repeated queries. They also explain why inventing a fresh label does not guarantee a fresh trip to the authoritative servers.

When the Timer Is Not the Root Cause

If the resolver returns SERVFAIL, stop treating the incident as a missing A record. Investigate authoritative reachability, delegation, alias loops, and DNSSEC validation as appropriate. A repaired underlying problem can still be followed by a short period of cached resolution failure. [2]

Some responses include Extended DNS Errors (EDE), which can add diagnostic detail about validation failures, unreachable authorities, or filtering. EDE supplements the response code; it does not replace its meaning. [11]

If an apparent negative TTL keeps restarting, check whether different cache instances are answering or whether a still-incorrect authoritative server is supplying new denials. If authoritative DNS is correct but the application fails after the relevant resolution path works, investigate its own state and connection behavior.

Publish Before You Probe

For a planned rollout, publish the required records before automated checks or users begin asking for them. Include the actual record types involved: a working website A record does not establish that a verification TXT record or an AAAA record exists.

Review negative-cache settings ahead of changes when you control them, allowing previously cached answers to age out. Choose a balance between recovery time and the query load generated by repeated nonexistent-name requests.

After a fix, compare authoritative data, recursive data, and the application path. There is no single global DNS cache to clear and no universal “wait 48 hours” diagnosis.

Sometimes the fix really is correct. What remains broken-looking is a perfectly functional memory of a world in which the fix had not happened yet.

References and Further Reading

1. RFC 2308: Negative Caching of DNS Queries.
2. RFC 9520: Negative Caching of DNS Resolution Failures.
3. Amazon Route 53: SOA and NS Records.
4. ISC BIND 9: Configuration Reference.
5. ISC BIND 9: dig Manual.
6. Microsoft: ipconfig, including /displaydns and /flushdns.
7. Mozilla: Firefox DNS over HTTPS.
8. RFC 8020: NXDOMAIN—There Really Is Nothing Underneath.
9. RFC 8198: Aggressive Use of DNSSEC-Validated Cache.
10. RFC 9077: NSEC and NSEC3 TTLs and Aggressive Use.
11. RFC 8914: Extended DNS Errors.
12. RFC 9499: DNS Terminology.