DNS propagation, TTLs and why nothing is instant
Why a corrected record still looks wrong for an hour, and how to check properly.
You fixed the record. Some people see the new site; you still see the old one. Nothing is broken.
"Propagation" is really caching
There is no broadcast. When a resolver looks up your record, it caches the answer for the record's TTL. Until that TTL expires, it keeps serving the old answer — to you and anyone else behind that resolver. "Propagation" is just all those caches expiring at different times.
TTL is the lever
TTL 300s (5 min) — changes visible within minutes.
TTL 3600s (1 hour) — up to an hour of staleness.
TTL 86400s (1 day) — up to a day.
Cheap speed before a change: lower the TTL well in advance, make the change, then raise it again.
Check the truth, not your browser
Your browser and OS both cache DNS too. To see what the world sees, query authoritative nameservers directly:
dig example.com A +short # your configured resolver
dig @1.1.1.1 example.com A +short # Cloudflare public resolver
dig @8.8.8.8 example.com A +short # Google public resolver
dig @ns1.yourhost.example example.com A +short # YOUR authoritative server (the source of truth)If the authoritative server has the right answer but a public resolver is stale, you are simply waiting for a cache. If the authoritative server itself is wrong, fix the zone.
Flush your own cache while you wait
# Linux (systemd-resolved)
resolvectl flush-caches
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Windows
ipconfig /flushdnsBrowsers keep their own cache too — a private window or a different browser bypasses it.
"It works for me but not for them" checklist
Query the authoritative nameserver — is the record correct there?
Check both apex and www.
Check the TTL and how long ago you changed the record.
Confirm you edited the zone that is actually live (not an old registrar's copy).
Look for a second, conflicting record of the same type.
Related reading