Explainer · networking

What is DNS propagation? (and why DNS changes take time)

You changed a DNS record, your registrar says it saved, and yet half the internet still sees the old value. That waiting period is what people call “propagation” — but the name is a little misleading. Nothing is being pushed out to anyone. Old cached answers are simply expiring. Here is what is really happening, and how to make changes with the least disruption.

Why “propagation” is the wrong word

The word “propagation” suggests that when you edit a record, the change spreads outward across the internet like a ripple — as if your DNS provider were actively notifying every server in the world. That is not how it works. DNS never pushes changes to anyone. There is no broadcast, no announcement, no update event sent to resolvers.

What actually happens is the opposite of a push: the rest of the internet is holding onto old cached copies of your record, and those copies have to expire before anyone goes back to your authoritative server to ask for the fresh value. “Propagation time” is really just cache-expiry time. Once you internalize that, every confusing thing about DNS changes suddenly makes sense.

If you want the full picture of how a lookup travels from your device to the authoritative server and back, see how DNS works. This article focuses on the one piece that governs timing: caching.

The real mechanism: TTL and resolver caching

Every DNS record carries a number called the TTL — time to live — measured in seconds. The TTL is a promise: it tells any resolver that fetches the record “you may reuse this answer for up to this many seconds before you must ask again.” A TTL of 3600 means one hour; 300 means five minutes; 86400 means a full day.

When someone visits your domain, their recursive resolver (usually run by their ISP, or a public one like 8.8.8.8 or 1.1.1.1) looks up your record, hands back the answer, and keeps a copy in its cache for the duration of the TTL. For that whole window, every other user of that resolver gets the cached answer instantly — the resolver does not bother your authoritative server again.

So the timeline of a change looks like this: the moment you save an edit, your authoritative nameserver updates instantly. But recursive resolvers around the world are still inside their TTL window for the old value, and they keep serving that cached answer until the clock runs out. A resolver that cached the old record one second before your change, with a one-hour TTL, will keep handing out the stale value for almost the full hour. A resolver that had never cached your record gets the new value immediately. That mismatch is the entire phenomenon.

Why it looks inconsistent

During a change you will often see the old value from one place and the new value from another at the same moment. That is expected, not a bug. Several independent caches sit between a visitor and your authoritative server:

The practical playbook: lower the TTL first

Because the delay is entirely about how long old caches live, the single most effective thing you can do is shorten the TTL before you make a change. The sequence:

  1. A day or two before the planned change, lower the TTL. Drop the record's TTL to something small like 300 (five minutes) or even 60. Then wait — you have to wait at least as long as the old, higher TTL for that low value to fully take effect everywhere, because resolvers are still holding the record at its previous longer TTL.
  2. Make the actual change. Now that caches are only holding your record for a few minutes at a time, edit the value. Within roughly one short-TTL window the world starts picking up the new answer.
  3. Confirm it is live, then raise the TTL back up. Once you have verified the new value is being served widely, return the TTL to a normal value (for example 3600 or higher) so you are not hammering your authoritative servers with constant re-lookups. High TTLs are good for stable records — they improve resolution speed and resilience — so only keep them low while you are actively changing things.

This is why experienced admins plan record changes ahead of time rather than flipping them on the spot. You cannot retroactively shorten a TTL that resolvers already cached; the low value only helps if it was in place before the change.

How to check the current state of a change

You do not have to guess whether a change has taken hold. You can inspect it directly:

Why nameserver and registrar changes take longest

Ordinary record edits (A, AAAA, CNAME, TXT, MX) live entirely on your own authoritative nameservers, so their timing is governed by the TTL you control. But changing your nameservers themselves — pointing the domain at a new DNS provider — is different and slower for two reasons.

First, the delegation records that say “this domain's nameservers are X and Y” live at the TLD level (the .com or .orgservers), and those NS records typically carry long TTLs measured in a day or more, which you do not control. Second, the change often has to pass through your registrar and be published to the registry, which adds processing time on top of caching. The result is that nameserver and registrar-level changes are the ones most likely to take the better part of a day — or in some cases up to roughly 24 to 48 hours — to be seen everywhere.

Realistic timeframes (kept approximate)

Anyone promising an exact propagation time is guessing, because it depends on TTLs and on when each resolver last cached your record. As rough guidance:

Treat these as ballpark ranges. The controllable lever is always the TTL — lower it in advance and your realistic worst case shrinks dramatically.

Frequently asked questions

Why does DNS propagation take so long?

Because nothing is actively pushed. Your authoritative nameserver updates the instant you save, but recursive resolvers worldwide have cached the old answer and keep serving it until that cached copy expires. How long that takes is set by the record's TTL. A resolver that cached the old value just before your change can keep serving it for nearly the full TTL. Lowering the TTL a day or two ahead of a change shrinks that window.

How long does DNS propagation actually take?

It depends on the TTL and on how recently each resolver cached the record. Ordinary records with typical TTLs usually reach most of the world within minutes to a few hours. Nameserver and registrar changes are the slowest because they involve long-TTL, TLD-level records plus registrar processing, so allow up to roughly 24 to 48 hours. These are approximate ranges, not guarantees.

Can I speed up DNS propagation?

You cannot force other people's resolvers to drop a cached record early, so there is no button that instantly propagates a change worldwide. What you can do is plan: lower the TTL a day or two before the change so caches expire quickly, make the change, then raise the TTL back once the new value is confirmed live. Locally you can flush your own DNS cache and query public resolvers directly to see the new answer sooner.

Related reading