DNS changes are often described casually. Someone updates a record, waits a moment, and expects the internet to follow along. When that does not happen, the usual conclusion is that DNS is slow or broken.
In reality, DNS is doing exactly what it was designed to do. The confusion comes from how change propagates through a distributed, cache-heavy system.
This article explains why “just updating a record” is not as clean as it sounds, and why DNS change management requires different expectations than many other configuration systems.
The mental model most people start with
A common mental model treats DNS like a central database. You change a value, and everyone who looks it up sees the new value.
That model does not match how DNS actually operates.
DNS is a loosely coordinated system made up of authoritative servers, recursive resolvers, intermediate caches, operating system stub resolvers, and sometimes application-level caches. Each layer is allowed to remember answers for a period of time.
Once an answer is cached, no part of the system is obligated to ask again until that cached entry expires.
TTL is a hint, not a global timer
The Time To Live (TTL) value is often described as “how long DNS caches the record.” That description is incomplete.
A TTL is attached to an answer when it leaves the authoritative server. From that point forward, every cache that stores the answer maintains its own countdown. There is no shared clock and no coordination between caches.
If ten recursive resolvers receive the same answer at ten different moments, they will expire that answer at ten different times.
Lowering a TTL does not retroactively affect answers that are already cached. Only future queries will receive the new TTL value.
This is one of the most common sources of surprise during DNS changes.
Caches exist in more places than expected
When a DNS response is cached, it is rarely cached in only one place.
At a minimum, caching usually occurs at the recursive resolver. In many environments, additional caching happens in the operating system stub resolver. Some applications maintain their own DNS caches on top of that.
Browsers, JVMs, container runtimes, and load balancers all have their own DNS caching behaviors. These behaviors vary by implementation and are not always well documented.
This means a DNS change may appear to work from one device while continuing to fail from another, even when both are on the same network.
Authoritative changes are not always atomic
From the operator’s perspective, updating a record often appears instantaneous. The change is saved in a management interface and immediately visible when querying the authoritative server directly.
That does not mean the change is globally visible.
Authoritative name servers may be distributed across multiple nodes or locations. Zone transfers, internal replication, or control plane delays can introduce brief windows where different authoritative servers answer differently. For example, a managed DNS provider using anycast may need a short period to push an update to all nodes, or may batch control plane changes internally. In well-configured setups that use NOTIFY (RFC 1996) and incremental zone transfers (IXFR), this window is typically very short, often measured in seconds rather than minutes.
While these windows are usually short as mentioned, they matter when combined with caching. A resolver that queries one authoritative server may cache an older answer while another resolver caches the new one.
Negative caching complicates recovery
DNS also caches failures. This behavior exists to reduce repeated load on authoritative servers when resolvers ask for names that do not exist.
If a resolver asks for a name that does not exist, that negative answer can be cached. The duration of negative caching is controlled separately from record TTLs and is often derived from the SOA record.
This becomes relevant when records are created shortly after being absent. Even though the record now exists, some resolvers may continue to return a cached “does not exist” response until the negative cache expires.
Change timing matters more than the change itself
Because DNS is cache-driven, the timing of a change often matters more than the content of the change.
Lowering TTLs ahead of a planned migration allows cached answers to expire more quickly once the change is made. Making the same TTL adjustment after the change has already occurred has little immediate effect.
This is why experienced operators treat DNS changes as multi-step processes rather than single actions.
Why DNS feels unpredictable during incidents
During outages or migrations, DNS is often blamed because symptoms appear inconsistent. Some users are affected, others are not. Some regions recover quickly, others lag behind.
This inconsistency is a natural result of independent caches expiring at different times, combined with multiple authoritative servers and resolver paths.
DNS is not converging toward a single state in real time. It is slowly aging out old information while new information spreads.
Summary
DNS change management is less about making the change and more about managing how that change propagates.
Key takeaways:
- DNS is a distributed caching system, not a central database
- TTLs control future caching behavior, not existing cached data
- Caches exist at multiple layers, often outside the operator’s visibility
- Timing and preparation matter more than the specific record update
Understanding these constraints makes DNS behavior feel less mysterious and makes planned changes far more predictable.