Why DNS Changes Take Time

You update a DNS record, refresh the site, and nothing changes. An hour later it works on your phone but not your laptop. This is DNS propagation, and it is not really propagation at all — it is caching. Understanding it saves a lot of needless panic during a migration.

DNS in one paragraph

DNS turns a name like example.com into an IP address a computer can connect to. When you change where your domain points — a new web host, a new mail provider — you edit a record at your DNS provider. The question is how long until the whole internet sees the new value.

It is caching, not travel

Nothing physically "spreads" across the internet. Instead, every layer between you and the authoritative DNS server caches answers so it does not have to ask again for every request. Your computer caches, your router caches, and crucially your ISP's resolver caches. Each cached answer is kept for a set time.

So when you change a record, the authoritative server updates instantly. But resolvers that already looked up the old value keep serving it from cache until their copy expires. That staggered expiry is what looks like a change slowly rolling out.

The TTL is the clock

Every DNS record has a TTL (Time To Live), measured in seconds, that says how long resolvers may cache it. A TTL of 3600 means "you may reuse this answer for an hour". The TTL, not any physical distance, sets how long old answers linger.

This gives you a simple lever. Before a planned migration:

1. Lower the TTL on the records you are about to change — say from 3600 to 300 — a day or two ahead.
2. Wait for the old, high TTL to expire so everyone picks up the short one.
3. Make the change. Now caches hold it for only five minutes, so the switch is nearly instant.
4. Raise the TTL again afterwards, once you are happy, to reduce lookup load.

Why it is inconsistent across devices

Different networks cache independently, so your phone on mobile data and your laptop on office Wi-Fi are asking different resolvers that cached at different moments. One has expired, the other has not — hence "it works here but not there". This is normal and resolves itself as each cache times out. It is not a sign the change failed.

Checking it properly

The trap is trusting your own machine. Your laptop and even your router hold their own caches, so "it still shows the old value for me" tells you little. The reliable check is to query multiple resolvers in different locations and see what each currently returns. When they all agree on the new value, propagation is effectively complete.

You can also flush local caches to rule out the nearest layer: your browser, your operating system and your router each keep their own, and clearing them removes false alarms close to home.

When to worry

If a record still shows the old value everywhere well past its old TTL, then something is actually wrong — often the change was made at the wrong provider (for example, editing records at your registrar while your nameservers point elsewhere), or a typo in the record itself. At that point, check which nameservers are authoritative for the domain and confirm the record there.

Watching a record resolve across many global locations at once, confirming which nameservers are authoritative, and checking the overall health of a domain's DNS all run from your browser — so during a migration you can see the real, worldwide picture instead of guessing from your own cached view.