What actually happens when you change an A record, why “48 hours” is a myth, and how to verify DNS changes in real time.
There is no “propagation”, only caches expiring
DNS changes do not push out to the world; nothing is propagating anywhere. When you update an A record, the authoritative nameserver answers with the new value immediately. Everyone else, ISP resolvers, public resolvers like 1.1.1.1, your OS, your browser, keeps serving their cached copy until its TTL (time to live) expires, then re-asks and gets the new answer.
"Propagation delay" is simply the world’s caches expiring at different moments. With a 300-second TTL, effectively everyone converges within five minutes. The mythical "24 to 48 hours" dates from an era of default day-long TTLs and survives because it makes a safe thing to tell customers.
Verify at the source, skip the guesswork
The definitive check queries your zone’s authoritative nameserver directly, bypassing every cache on Earth:
Correct at the authoritative server: your change is live; the world converges within one TTL, done
Wrong there: the change did not save, or you edited the wrong zone, if nameservers point at Cloudflare, records at your registrar are decorative
dig +short NS example.com # find the authoritative servers
dig +short app.example.com @ns1.dns-host.com # ask one directly
Why YOUR machine still shows the old value
The most common "DNS is broken" report is local caching. Your OS resolver, systemd-resolved, and your browser each cache independently, sometimes beyond the TTL. Test against a public resolver to see what the world sees, and flush local caches only if you personally need the new value right now:
dig +short app.example.com @1.1.1.1 # Cloudflare's resolver
dig +short app.example.com @8.8.8.8 # Google's
# flush local (macOS)
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# flush local (Linux with systemd-resolved)
sudo resolvectl flush-caches
Negative caching: the sneaky one
If you query a name before creating its record, resolvers cache the "does not exist" answer (NXDOMAIN) for the zone’s negative TTL, often longer than your record TTL. Practical rule: create the record first, test second. If you tested too early, the fix is patience or querying a resolver you have not poisoned yet.
Practical playbook for changes
Before a planned migration: lower the TTL to 300 a day in advance (the old TTL governs how long the lowering itself takes to be seen)
Make the change, verify against the authoritative server, then against 1.1.1.1
Keep the old server running for at least the old TTL window to catch stragglers
After stabilizing, raise TTL back to 3600 or more for resilience and fewer resolver queries
Top comments (0)