When people say “DNS hasn’t updated yet,” they’re usually describing caching.
DNS caching is the reason name resolution scales to internet size. It’s also the reason DNS changes feel slow, inconsistent, or unpredictable when something goes wrong. To understand real DNS behavior, you need to understand how resolvers remember answers and when they decide to forget them.
Why DNS caches at all
DNS was designed under the assumption that asking authoritative servers for every query wouldn’t scale. Even on the early internet, that approach would have collapsed under load.
So recursive resolvers cache answers and reuse them for many clients. A resolver that has learned the answer to a question keeps serving it until the answer expires. Nothing about this is optional. A resolver that refused to cache would hammer the hierarchy for answers it already had, and the hierarchy was never sized for that.
What gets cached
A recursive resolver doesn’t cache “domains” in a general sense. It caches specific answers to specific questions, each entry keyed by:
- Fully qualified domain name
- Record type (A, AAAA, MX, etc.)
- Class (IN in practice)
example.com A, example.com AAAA, and www.example.com A are three distinct cache entries, each expiring on its own clock.
Resolvers also cache intermediate data learned along the way, like NS records for delegations, glue addresses, and negative answers such as NXDOMAIN. Caching is layered, and a single query may lean on several cached components at once, each with its own timer.
What a TTL actually promises
Every DNS record carries a TTL, or Time To Live, the maximum time a resolver may reuse that answer without asking again.
The name misleads people. A TTL doesn’t say when a resolver must recheck, when a change will propagate, or when all caches will agree. All it says is that the answer can’t be reused after the timer hits zero.
A resolver is free to discard a record early, under memory pressure or by policy, but it isn’t allowed to keep the record longer. A TTL is a ceiling on reuse.
Positive and negative caching
Resolvers cache both successful and unsuccessful answers.
Positive caching
A valid answer is cached for the TTL the authoritative server attached to it:
example.com. IN A 93.184.216.34 ; TTL 3600For up to one hour, the resolver may hand that answer to any client that asks.
Negative caching
“This name doesn’t exist” (NXDOMAIN) is also an answer, and resolvers cache it too. So is NODATA, where the name exists in the class you asked about but holds no record of the type you requested. Neither one hands back the records you wanted, and both are worth remembering so the resolver stops re-asking a question it has already had answered.
The two are stored against different keys. NXDOMAIN applies to the whole name, so it’s cached against the name and class. While that entry is live, the resolver answers later questions about the same name without going upstream, whatever record type they ask for. NODATA applies only to the type in the question, so it’s cached against the name, type, and class. A cached “no MX here” says nothing about the A record.
The lifetime rides along in the SOA record that the authoritative server attaches to a negative answer. That server sets the SOA’s TTL to the lower of two values, the zone’s SOA minimum field and the TTL on the SOA record itself. The result is the normal upper bound on reuse. A resolver may drop the answer sooner or apply a shorter cap of its own.
example.com. 600 IN SOA ns1.example.com. hostmaster.example.com. (
2026081901 ; serial
7200 ; refresh
3600 ; retry
1209600 ; expire
900 ) ; SOA minimumThe minimum field here is 900 seconds, but the SOA record carries a TTL of 600, so the negative answer leaves with 600 seconds on it. The same pair shows up in dig output, where the TTL printed just before IN SOA is the figure a resolver will work from, while the last number inside the record is the minimum field.
Only the smaller of the two has any effect. Dropping the 900 to 700 changes nothing here, because 600 still wins. Ahead of a cutover that creates a name or a record type, lower whichever value is currently setting the ceiling, far enough in advance that answers cached under the old figure have expired.
That field has carried other meanings. RFC 1035 defined it as a floor for the TTLs a zone sends out, and it was later pressed into service as the default TTL for master file records that omitted one. RFC 2308 deprecated the floor reading, introduced $TTL for the default, and left the minimum field feeding negative cache lifetimes.
RFC 2308 also recommends that resolvers cap negative caching locally rather than accepting whatever arrives. It describes one to three hours as a sensible default for that cap and reports that values beyond a day have been found to cause problems.
Caching creates inconsistent views
Every recursive resolver maintains its own cache, so different resolvers can legitimately hold different answers at the same moment, and that’s normal.
Two users querying the same domain may hit different resolvers, with different cache states, and see different results during a transition. This is why DNS changes propagate unevenly. There’s no global refresh event, only millions of independent timers expiring on their own schedules.
Authoritative intent vs resolver reality
Authoritative servers publish intent. Recursive resolvers enforce reality.
An authoritative server can publish a new record instantly. That does nothing to the cached copies of the old answer already sitting in resolvers around the world, which keep serving it until their TTLs run out. DNS trades immediacy for scale and resilience by design.
This is why experienced DNS troubleshooting so often starts with one question: “Which resolver are you using?”
app.example.com from 192.0.2.10 to 192.0.2.20 during an outage. Some users immediately reach the new server. Others continue hitting the old address for up to 30 minutes. The difference isn't propagation speed but cache expiration. Resolvers that hadn't cached the old record fetch the new one, while resolvers with a live cache keep using it until the TTL reaches zero.
Caching happens in layers
A single lookup may be answered from caches at several levels:
- The application
- The operating system stub resolver
- The recursive resolver
- Forwarding resolvers or ISP infrastructure
Each layer applies its own rules, which is why flushing one cache guarantees nothing if another layer still holds the data.
Recursive resolver caching is only part of the picture, and client and OS behavior adds its own layer of surprises.
Why this matters operationally
Caching sets the clock on almost everything operational in DNS. Change windows and rollouts are paced by TTLs. Incident response inherits whatever TTLs were in place before the incident. Failover strategies live or die by how fast caches forget. Filtering and enforcement take effect only as cached answers expire.
Operators who expect DNS to behave like a real-time configuration system misdiagnose all of this. DNS is a distributed memory with expiration. Internalize that model and the confusing behaviors become predictable.
Summary
DNS caching is what allows the system to scale, and it introduces delay and inconsistency by design. A TTL is a maximum reuse time, not a synchronization guarantee, negative answers have a lifetime of their own, and authoritative updates don’t invalidate the caches already holding the old answer.
DNS remembers by default. Forgetting takes time.