Learn & Understand

How DNS Really Works, and Why 'Propagation' Is the Wrong Word

The companion calculator estimates how long a DNS change takes to take full effect, based on the old record's TTL. That detail, that the old TTL governs, is a clue to a widely misunderstood truth: DNS changes do not "propagate" or spread across the internet at all. The delay is really about caches expiring. Understanding how DNS resolution actually works, through a chain of servers and caches, reveals why "propagation" is the wrong word and why the practical advice, lower the TTL before a change, works the way it does.

The Resolution Chain

When a browser needs the address behind a domain name, it does not consult one master server. It walks a hierarchy, each step handing off to the next.

The recursive resolver asks the root where to find the top-level domain's servers, asks those where the domain's authoritative server is, and asks that server for the actual record, then returns the answer. This distributed hierarchy is what lets DNS scale to the whole internet without any single server holding everything, and it is deliberately built around caching at each step so the full chain rarely has to be walked.

Caching at Every Layer

The key to DNS performance, and to the "propagation" confusion, is that answers are cached at many points and reused until they expire. Each record carries a TTL specifying how long resolvers may cache it, and during that time, a resolver that has the answer serves it directly without asking the authoritative server again. This caching makes DNS fast and reduces load enormously, but it means that when you change a record, resolvers that have already cached the old value will keep serving it until their cached copy's TTL runs out. Nothing is spreading; old answers are simply lingering in caches until they age out.

Why 'Propagation' Is a Misnomer

The term "DNS propagation" implies a change ripples outward across the internet, taking time to reach distant servers. That mental model is wrong. Authoritative servers update instantly when you change a record. What takes time is the expiry of old, cached copies held by resolvers around the world, each of which keeps serving the stale value until its TTL, set by the previous record, expires. So the delay is governed by the old record's TTL, not the new one, exactly as the calculator computes, because that TTL is what determines how long the outdated cached answers persist. It is cache expiration, not propagation. Reframing it this way makes the behavior predictable rather than mysterious.

Lowering TTL Before a Change

This understanding directly yields the standard trick for fast DNS changes. Because the old TTL controls how long stale answers linger, you lower the TTL well in advance of a planned change, days or at least hours before. Once that shorter TTL has itself been cached everywhere (which takes up to the previous TTL), caches will only hold records briefly, so when you finally make the real change, the old value expires from caches quickly and the new value is picked up almost immediately. After the cutover, you can raise the TTL again for efficiency. This preparation works precisely because the delay is about cache lifetime, lowering the TTL first shrinks the window during which stale answers survive.

Planning DNS Changes Knowingly

Use the calculator to estimate the delay from the old record's TTL, and understand the mechanism behind it: DNS resolves through a caching hierarchy, changes do not propagate but rather wait for cached copies to expire, and the old TTL, not the new one, governs how long that takes. Lower the TTL ahead of a planned change to shrink the delay, then restore it afterward. The calculation estimates the wait; understanding how DNS really works is what lets you plan changes with confidence.