DNS changes get described casually. Someone updates a record, waits a moment, and expects the internet to follow along. When it doesn’t, the usual conclusion is that DNS is slow or broken.
DNS is doing exactly what it was designed to do. The confusion comes from how change moves through a distributed, cache-heavy system, and it’s why “just update the record” is never the whole plan.
The mental model most people start with
The intuitive model treats DNS like a central database: change a value, and everyone who looks it up sees the new value.
DNS doesn’t work that way. It’s a loosely coordinated system of authoritative servers, recursive resolvers, intermediate caches, operating system stub resolvers, and sometimes application-level caches, and every layer is allowed to remember answers for a while. Once an answer is cached, nothing in the system is obligated to ask again until that entry expires.
Every cache counts down its own TTL
The Time To Live (TTL) value is usually described as “how long DNS caches the record,” but that leaves out the part that matters. A TTL is attached to an answer as it leaves the authoritative server. From then on, every cache that stores the answer runs its own countdown, with no shared clock and no coordination.
If ten resolvers receive the same answer at ten different moments, they expire it at ten different times. You can watch this happen. Query the same resolver twice in a row and the TTL field in the answer shrinks between asks.
Lowering a TTL does nothing to answers already sitting in caches. Existing copies live out the lifetime they arrived with, and only copies fetched after the change carry the new value. That one fact explains a large share of DNS-change surprise.
Caches sit at several layers
A cached DNS response rarely lives in only one place. The recursive resolver caches, the operating system stub resolver usually caches, and plenty of applications cache on top of that. Browsers, JVMs, container runtimes, and load balancers all bring their own caching behavior, each differently implemented and not always documented.
The practical result is that a DNS change can look complete from one device and broken from another sitting on the same network.
Authoritative changes aren’t always atomic
From the operator’s chair, an update looks instantaneous. It saves in the management interface and often shows up immediately when you query an authoritative server directly. Globally visible is another matter.
Authoritative service is usually spread across nodes and locations, and zone transfers and replication can open brief windows where different authoritative servers answer differently. Well-run setups using NOTIFY (RFC 1996) and incremental zone transfers keep the window to seconds. But even a short window matters when caching is involved. One resolver caches the old answer from a lagging node while another caches the new one, and the two now disagree for a full TTL.
Negative caching complicates recovery
DNS caches failures too. “This name doesn’t exist” is a cacheable answer, with a lifetime controlled separately from record TTLs, derived from the zone’s SOA record.
This bites when a name gets queried shortly before its record is created. The record exists now, but resolvers holding the cached “doesn’t exist” keep saying so until the negative entry expires. Testing a name before you create it can manufacture this problem on the spot.
Change timing matters more than the change itself
Because DNS is cache-driven, when you change something often matters more than what you change.
Lowering TTLs ahead of a planned migration lets cached answers age out quickly once the real change lands. The same TTL adjustment made after the change accomplishes almost nothing in the moment. Experienced operators treat DNS changes as multi-step sequences with waiting built in, not single actions.
Why DNS feels unpredictable during incidents
During outages and migrations, DNS takes the blame because the symptoms refuse to be consistent. Some users are affected and others aren’t. Some regions recover quickly while others lag. Stale answers linger in some caches and not others.
All of it follows from independent caches expiring on independent schedules across multiple authoritative servers and resolver paths. DNS isn’t converging on a new state in real time. It’s aging out the old state while the new one spreads.
Summary
DNS change management is less about making the change and more about managing how it propagates. DNS is a distributed caching system, not a central database. A TTL change reaches only copies cached after it, existing copies live out their remaining time, and caches sit at layers the operator can’t see, let alone flush. Lower the TTL early, wait out the old one, then make the change.
Plan around those constraints and DNS changes become boring, which is exactly what you want them to be.