DNS propagation explained: why changes take time

You update a DNS record, refresh your site, and… nothing changes. Or it works for you but a colleague still sees the old version. This is DNS propagation, and it's one of the most misunderstood parts of running anything online. Here's what's really going on.

Propagation isn't really "spreading"

The word makes it sound like your change slowly travels across the internet. It doesn't. Your authoritative record updates instantly. What takes time is the *old answer expiring* from caches all over the world. Until each cache's timer runs out, it keeps serving the stale value.

The role of TTL

Every DNS record has a TTL — time to live — measured in seconds. It tells resolvers how long they may cache an answer before checking again.

Type: A
Name: @
Value: 203.0.113.10
TTL: 3600

A TTL of 3600 means resolvers can hold that answer for an hour. If you change the record, resolvers that cached it will keep serving the old IP for up to an hour before they ask again. Higher TTLs mean longer waits; lower TTLs mean faster changes but slightly more lookup traffic.

Why different people see different things

Because caches expire independently, a change can be visible in one city and not another for a while. Your ISP's resolver might have refreshed already while someone else's still holds the old value for another 40 minutes. This is completely normal and resolves itself as timers expire.

How long does it take?

• Record changes (A, CNAME, TXT): usually minutes to a couple of hours, governed by the record's TTL.
• Nameserver changes: slower, because they're cached higher up. Allow up to 24–48 hours.

The often-quoted "48 hours" is a worst case, not a typical one. Most changes settle well within a few hours.

How to check progress

Use dig to ask a specific resolver what it currently returns:

dig example.com +short
dig @1.1.1.1 example.com +short

Querying different public resolvers (like 1.1.1.1 and 8.8.8.8) shows you whether the change has reached them yet. Online "DNS checker" tools do the same across many locations at once.

The pro move: lower TTL in advance

If you know you're migrating servers next week, plan ahead. A day or two before the change, drop the record's TTL to something small like 300 (five minutes). Wait for the old high TTL to expire so the low one takes hold. Now when you make the actual switch, it propagates in minutes instead of hours. Raise the TTL back afterward.

Clearing your own cache

Sometimes it's *your* machine caching the old answer, not the wider internet. Flush your local DNS cache:

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux (systemd)
sudo resolvectl flush-caches

And remember your browser caches too — a hard refresh or a private window rules that out.

Don't panic, don't double-change

The biggest mistake is assuming a change failed and editing the record again mid-propagation, which just resets the clock and adds confusion. Make the change once, verify with dig, and give it time.

When you manage a domain and server together in Nxeon, cutovers are simpler: lower the TTL ahead of time, flip the A record when you're ready, and watch it resolve — all from one dashboard.