Why DNS changes take time: propagation and TTL explained

What "propagation" actually is

"Propagation" is a misleading word. Nothing is pushed anywhere. When you change a record at your DNS provider, that change is live on your authoritative name servers immediately. What takes time is the rest of the internet noticing — and it only notices when the copy it already has expires.

Every recursive resolver that looked your name up recently is holding an answer with a countdown attached. Until that countdown reaches zero, the resolver will keep handing out the old value without asking anyone. Your change is not travelling; their copies are expiring.

TTL: the number that decides the wait

TTL (Time To Live) is a number of seconds attached to every DNS record. It is the record owner's instruction to resolvers: you may reuse this answer for this long before asking again.

The crucial detail: the TTL that governs the wait is the old TTL — the one that was published when resolvers cached the answer. Lowering the TTL at the same moment you change the record does nothing for anyone already holding the old copy. They will hold it for the old duration, and only then see both your new record and its new TTL.

Where the caches you cannot see live

A single lookup can pass through four or five independent caches, and each can be stale on its own schedule:

• The application. Many runtimes cache resolved addresses for the life of the process — some JVM configurations cache them forever. Restarting the process is sometimes the only fix.
• The operating system. Windows, macOS and most Linux setups keep a local stub cache.
• The router or local resolver. Home routers and corporate resolvers cache aggressively, occasionally ignoring your TTL entirely.
• The recursive resolver. Your ISP's resolver, or a public one like 1.1.1.1 or 8.8.8.8. This is the one people mean by "propagation", and the one you cannot influence.
• The CDN or proxy in front of your site. Which may itself be resolving your origin name on its own schedule.

You can flush the first three on your own machine. You cannot flush the fourth for anyone else. Any tool claiming to "force propagation" is only clearing its own view.

Planning a cutover

The whole point of understanding TTL is that a planned change costs almost no downtime, while an unplanned one costs a full TTL. The sequence:

1. Well ahead of the change (at least one full current TTL, ideally a day), lower the TTL on the records you are about to change — to 300 seconds, or 60 if the cutover has to be tight.
2. Wait out the old TTL. This is the part people skip. Until the old, longer TTL has fully expired everywhere, some resolvers still hold a copy that says "cache me for an hour".
3. Confirm the low TTL is what resolvers are actually handing out — not just what your provider's panel shows. Compare several resolvers before you commit.
4. Make the change. Now the worst case is your new, short TTL rather than the old long one.
5. Keep the old destination alive for at least one more TTL. Some client somewhere is still holding the old address, and serving them an error is avoidable.
6. Raise the TTL back once the change has settled, so you are not paying for extra lookups indefinitely.

Telling a stale cache from a broken record

The two look identical from a browser and are fixed completely differently. The distinction is whether resolvers disagree:

• Some resolvers show the new value, others the old. That is caching. It resolves itself; the remaining wait is bounded by the old TTL.
• Every resolver shows the old value, and the old TTL has long since passed. That is not caching. The change did not take effect — check that you edited the zone that is actually delegated (the NS records at the registrar decide which provider is authoritative), and that you did not edit a record on a different subdomain.
• Every resolver shows the new value but your browser does not. The stale cache is local. Restart the browser, flush the OS cache, and check whether the application caches resolutions itself.
• Resolvers disagree and keep disagreeing. Your authoritative servers may not be serving the same zone. Compare the SOA serial across them — if the serials differ, a secondary has not picked up the transfer.

The SOA serial is the single most useful signal here: it is a version number for the zone, and every authoritative server that has the current version reports the same one.

Negative caching: the trap after a typo

There is a second timer most people never meet until it bites them. When a name does not exist, that "does not exist" answer is cached too — and its duration comes from the minimum field of the zone's SOA record, not from the TTL of the record you just created.

So if you look up a hostname before creating it, the NXDOMAIN gets cached, and creating the record does not immediately fix it. You wait out the SOA minimum, which is commonly 3600 seconds and sometimes far longer.

The practical rule: create the record first, then look it up. If you have already triggered the negative cache, check the zone's SOA minimum so you know exactly how long to wait rather than guessing — and resist the urge to keep re-querying from the same resolver, which does not shorten anything.

Spotted an error in this guide? Tell us at [email protected] — corrections are made and the updated date above changes with them.