How DNS Propagation Actually Works (And Why the Name Is Misleading)

If you’ve ever changed a DNS record and then refreshed a website only to see the old version, you’ve probably been told to “wait for propagation.” It’s a phrase used constantly in web hosting and support forums, and it’s not quite accurate. Nothing actually spreads or propagates in the way the word suggests. What’s really happening is caching, and once you understand how that caching works, the whole process stops feeling mysterious.

What people mean by “propagation”

When someone says a DNS change is “propagating,” they mean that different computers around the world are still returning the old answer for a domain name, while others have started returning the new one. It looks like the change is spreading outward, but there’s no signal travelling from your registrar to every device on Earth. Instead, thousands of independent DNS resolvers, each with their own cached copy of the old record, are simply waiting for their own copies to expire before they ask again. The “spread” you’re observing is really lots of separate caches expiring on their own separate timers.

TTL is the mechanism that actually controls this

Every DNS record has a Time To Live (TTL), a value in seconds that tells resolvers how long they’re allowed to keep and reuse a cached answer before checking with the authoritative nameserver again. This is defined in RFC 1035, the original DNS specification, which describes the TTL as the time interval a resource record may be cached before “the source of the information should again be consulted.” A later specification, RFC 8767, actually goes the other way for resiliency: it amends the TTL definition so that a resolver MAY keep using a cached record past its TTL expiry – “as though it is unexpired” – specifically when the authoritative source can’t be reached to refresh it, a deliberate exception called “serve-stale” designed to keep DNS working through outages. Outside that exception, the TTL remains the effective ceiling on ordinary cache lifetime. In practice, the TTL is a ceiling on cache lifetime, not a guarantee of exactly how long a record will be cached.

A typical A record with a one-hour TTL looks like this in zone file notation:

www.example.co.uk.  3600  IN  A  203.0.113.10

The “3600” is the TTL in seconds, so one hour. Once you change the IP address in that record, any resolver that already cached the old answer will keep using it until its own local copy of that TTL expires, then it will query again and pick up the new value.

Why it doesn’t happen everywhere at once

A single DNS lookup passes through several layers, and each one can hold its own cache:

• Your browser, which may cache DNS answers for a short period independently of the operating system.
• Your operating system’s stub resolver, which keeps its own local cache.
• Your router or local network resolver, if one is configured.
• Your ISP’s recursive resolver, which is shared by thousands of other customers and caches answers on their behalf too.
• Public recursive resolvers such as those operated by large providers, which many devices and apps query directly regardless of ISP settings.

Each of these caches was populated at a different moment, so each one expires at a different moment. That’s why two people on different networks, or even the same person on wifi versus mobile data, can see different results for the same domain during the transition window. It isn’t a fault, it’s simply that each cache is on its own clock.

Authoritative versus recursive resolvers

It helps to separate two roles in the DNS system. The authoritative nameserver for your domain is the source of truth, it’s where your registrar or DNS host stores the actual records and where changes take effect immediately. A recursive resolver is the intermediary that end users’ devices actually talk to; it looks up the answer on the user’s behalf and then caches it for reuse. When you update a record, the authoritative nameserver is correct the moment you save the change. What takes time is every recursive resolver in the world that already has a cached copy working through its own TTL before it asks the authoritative server again.

How long should you actually expect to wait?

The rule of thumb is straightforward: the maximum time a resolver can serve a stale answer is whatever the old TTL was set to, counted from the last time that resolver refreshed its cache. If your old A record had a TTL of 86400 seconds (24 hours), some resolvers could theoretically serve the old answer for close to a full day after you make the change, even though your new record is live straight away. Once a resolver does refresh, it picks up whatever TTL you’ve set on the new record for future caching.

TTL value	Time in seconds	Typical use
300	5 minutes	Just before or during a planned migration
3600	1 hour	Common default for actively managed records
14400	4 hours	Stable records that rarely change
86400	24 hours	Long-term stable records, reduces query load

RFC 8767 also recommends that resolvers cap how long they’ll cache a record even if a zone specifies something extreme, suggesting an upper bound in the region of 604,800 seconds (one week), so absurdly high TTLs won’t be honoured indefinitely by well-behaved resolvers regardless of what you set.

Lowering your TTL before a migration

If you’re planning to move a website or mail service to a new server, the standard technique is to lower the TTL on the relevant records well in advance, so that when you do make the real change, resolvers only cache the old answer briefly. If that move also means changing hosting type entirely, our guide to shared vs VPS vs dedicated hosting is worth reading first. A practical timeline looks like this:

1. At least 24 to 48 hours before the migration, reduce the TTL on the records you’ll be changing, for example from 86400 down to 300 seconds. This gives existing long-lived cached copies time to expire under the old TTL first.
2. Wait until the old TTL period has fully elapsed, so you can be confident resolvers are now honouring the new, shorter TTL.
3. Make the actual change (new IP address, new mail server, and so on).
4. Once the change is confirmed working everywhere you can test from, raise the TTL back to a normal value such as 3600 or higher, since a permanently low TTL means more DNS queries and more load on your nameservers for no ongoing benefit.

When it isn’t really about TTL at all

Two situations often get lumped in with “propagation delay” but are actually separate:

• Changing nameservers at the registrar. This updates NS (nameserver) records at the domain’s registry, which are themselves cached by resolvers with their own TTL, often set by the registry rather than by you. This can take longer to clear than a typical record change because the NS records sit higher up the resolution chain.
• Negative caching. If a record didn’t exist yet when a resolver last checked, that “no such record” answer can itself be cached for a period, so a newly created record can take a little while to become visible even to a resolver that queries again.

The practical takeaway

“DNS propagation” is a convenient shorthand, but what’s actually happening is that your new record is live immediately at the authoritative nameserver, and the delay you experience is every individual resolver’s cache working through the TTL it captured before your change. If you plan migrations by lowering TTLs in advance and understand that different networks will catch up at different speeds, you can make DNS changes with far less guesswork and a lot less anxious refreshing of your browser.