When people say “DNS hasn’t updated yet,” they are usually describing caching.
DNS caching is the reason name resolution scales to internet size. It is 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 would not scale. Even in the early internet, that approach would have collapsed under load.
Instead, DNS relies on recursive resolvers to cache answers and reuse them for many clients. A resolver that has already learned the answer to a question is expected to keep using that answer until it expires.
Caching is not optional. It is a core design feature of DNS, not an optimization layered on later.
What Gets Cached
A recursive resolver does not cache “domains” in a general sense. It caches specific answers to specific questions.
Each cached entry is keyed by:
- Fully qualified domain name
- Record type (A, AAAA, MX, etc.)
- Class (IN in practice)
This means these are distinct cache entries:
example.com Aexample.com AAAAwww.example.com A
Each expires independently.
Resolvers also cache intermediate data learned during resolution, including:
- NS records for delegations
- Glue address records
- Negative answers, such as NXDOMAIN
Caching is therefore layered. A single query may rely on multiple cached components, each with its own expiration timer.
TTL: Time To Live, Not Time To Refresh
Every DNS record has a TTL, or Time To Live. The TTL tells a resolver the maximum amount of time it is allowed to reuse that answer without asking again.
This is a common point of confusion.
TTL does not mean:
- When a resolver must recheck
- When changes will propagate
- When all caches will update
It means only this: a resolver must not use the cached answer after the TTL reaches zero.
A resolver is free to discard a cached record earlier for its own reasons, such as memory pressure or policy. It is not allowed to keep it longer.
In practice, this means TTL is a ceiling, not a promise.
Positive and Negative Caching
Resolvers cache both successful and unsuccessful answers.
Positive caching
When a resolver receives a valid answer, such as an A record, it caches that answer for the duration of the TTL provided by the authoritative server.
example.com. IN A 93.184.216.34 ; TTL 3600
For up to one hour, the resolver may reuse that answer for any client that asks.
Negative caching
When a resolver is told that a name does not exist (NXDOMAIN), it may also cache that result.
The TTL for negative caching comes from the SOA record of the authoritative zone. Modern resolvers use the SOA minimum field specifically for negative caching, as defined in RFC 2308. Older documentation may describe this field differently.
Caching Creates Inconsistent Views
Because every recursive resolver maintains its own cache, different resolvers can legitimately hold different answers at the same time.
This is normal.
Two users querying the same domain may:
- Hit different resolvers
- Have different cache states
- See different results during transitions
This is why DNS changes propagate unevenly. There is no global refresh event. Each resolver updates only when its cached data expires or is evicted.
Authoritative Intent vs Resolver Reality
Authoritative servers publish intent. Recursive resolvers enforce reality.
An authoritative server can publish a new record instantly. That does not invalidate existing cached answers elsewhere. Resolvers that already cached the old answer will continue using it until the TTL expires.
This separation is intentional. DNS trades immediacy for scale and resilience.
Understanding this distinction helps explain why DNS troubleshooting often starts with the 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 is not propagation speed. It is cache expiration. Resolvers that had not cached the old record fetch the new one. Resolvers with a live cache keep using it until the TTL reaches zero.
Caching Is Layered, Not Singular
Caching does not happen in only one place.
A single DNS lookup may involve caches at multiple levels:
- The application
- The operating system stub resolver
- The recursive resolver
- Forwarding resolvers or ISP infrastructure
Each layer may apply its own caching rules. This is why flushing one cache does not guarantee fresh results if another layer still holds data.
Later articles will cover client and OS behavior in more detail, but it is important to recognize that recursive resolver caching is only part of the picture.
Why This Matters Operationally
DNS caching affects:
- Change windows and rollouts
- Incident response timelines
- Failover strategies
- DNS filtering and enforcement behavior
- Troubleshooting methodology
Operators who assume DNS behaves like a real-time configuration system often misdiagnose problems. DNS is a distributed memory system with expiration, not a push-based update mechanism.
Once you internalize that model, many confusing behaviors become predictable.
Summary
DNS caching is what allows the system to scale, but it also introduces delay and inconsistency by design.
Key takeaways:
- Resolvers cache specific answers, not domains
- TTL is a maximum reuse time, not a synchronization guarantee
- Negative answers are cached too
- Different resolvers legitimately see different data
- Authoritative updates do not invalidate existing caches
DNS remembers by default. Forgetting takes time.