DNS propagation: why your new record isn't live yet

You changed an A record an hour ago. Your laptop still loads the old site. A colleague in another city sees the new one. Someone on their phone sees the old one on Wi-Fi and the new one on cellular. Everybody blames "propagation" and waits, and the waiting advice you find online ranges from 15 minutes to 72 hours, which is not advice at all.

Here is the thing: DNS does not propagate. Nothing is pushed anywhere. The word stuck around because the behaviour looks like a slow rollout, but what is actually happening is much simpler and much more predictable once you know where to look.

Why "propagation" is the wrong word

When you edit a record at your DNS host, that change is live at the authoritative nameservers within seconds. There is no queue and no global distribution process. Anyone who asks the authoritative server right now gets the new answer immediately.

The delay comes from caching. Every resolver between a visitor and your authoritative servers keeps a copy of the old answer, and it is allowed to keep serving that copy until the copy expires. Your ISP's resolver has one. Cloudflare and Google have theirs. The visitor's router has one. Their operating system has one. Their browser has one.

So different people see different answers not because the change is spreading, but because each of them is sitting behind a cache that expires at a different moment. There is no wave moving across the world. There are millions of independent countdown timers, all started at different times.

TTL is the whole answer

Every DNS record carries a Time To Live in seconds. That number is a contract: "you may cache this answer for up to this long." It is published with the record itself, so you never have to guess.

TTL value	Worst case wait	Typical use
300	5 minutes	Records you expect to change, or a planned migration
3600	1 hour	A sensible default for most records
14400	4 hours	Common registrar default, slow to change
86400	24 hours	Stable records like MX or NS that rarely move

The key detail almost everyone misses: lowering the TTL does not help after you have made the change. Resolvers that already cached the old record cached the old TTL with it. If the old record said 86400, they are entitled to serve it for 24 more hours regardless of what you set afterwards.

The TTL has to be lowered before the change, and you have to wait out the old TTL for the lower value to take hold. That is the single most useful thing to know about DNS changes, and it is why planned migrations feel effortless and unplanned ones feel like chaos.

How to check what is really happening

Instead of refreshing your browser and hoping, ask the question directly. Three lookups tell you everything.

1. Ask the authoritative nameserver

   Pull the NS records for the domain with the DNS Record Explorer, then resolve the hostname again with one of those nameservers set as the custom server in DNS Lookup. This bypasses every cache in the world. If the authoritative answer is correct, your change is done and everything else is just waiting.

2. Ask a public resolver

   Query 1.1.1.1 and 8.8.8.8 for the same name. These two are what most of the internet effectively sees. If they have the new value, the rollout is well underway.

3. Read the TTL on the answer you get back

   This is the part people skip, and it is the most informative number on the screen. A cached answer's TTL counts down. If a resolver hands you the old record with a TTL of 1180, that resolver will keep serving the old value for another 19 minutes and 40 seconds, and then it will fetch the new one. You now know exactly how long to wait rather than guessing.

# What does the world see right now?
https://netdebug.app/open/dns?target=example.com&server=1.1.1.1

# Full record set with TTLs, so you know how long each answer lives
https://netdebug.app/open/dnsexplorer?target=example.com

# Ask the authoritative nameserver directly and skip every cache
https://netdebug.app/open/dns?target=example.com&server=198.51.100.10

Planning a change so it is fast

If you know a migration is coming, this sequence turns a day of uncertainty into a few minutes of it.

1. Check the current TTL first

   Whatever it is, that is how long you have to wait before step two takes effect. If it is 86400, plan a day ahead.

2. Lower the TTL to 300, then wait out the old TTL

   This is the step that does the real work. After the old TTL has expired everywhere, every resolver is now holding a copy that only lives five minutes.

3. Make the actual change

   Now the worst case exposure is five minutes instead of a day.

4. Verify against authoritative, then public resolvers

   Authoritative first (did the change save correctly?), then public (is it visible to the world?).

5. Raise the TTL back up once you are confident

   Low TTLs mean more queries and a little more latency for everyone. Put it back to 3600 or higher when the dust settles.

Keep the old server running during the transition if you can. Some clients will keep hitting it for as long as their cache allows, and a server that answers correctly is much better than a connection refused.

When it genuinely is stuck

Sometimes waiting is not the answer because the change never actually happened. Signs to look for:

The authoritative server still returns the old value

Then nothing was saved, or it was saved on the wrong zone. This happens constantly when a domain has been moved between providers and both still host a zone file for it. The old one is often still the one the NS records point at.

The NS records point somewhere unexpected

Check the NS records at the domain level. If they name a provider you stopped using two years ago, you have been editing records on a server nobody asks. A Whois lookup shows the delegation at the registrar, which is the source of truth for where queries actually go.

There is a CNAME in the way

If the hostname is a CNAME pointing at another name, editing the A record on the target has no effect on what visitors resolve until the CNAME chain resolves the way you think it does. Pull the full record set and follow the chain rather than assuming it.

Your own machine is lying to you

Browsers cache aggressively and independently of the operating system. So do hosts file entries, VPN resolvers, and corporate split horizon setups that answer internal names differently. If a public resolver has the new value and your laptop does not, stop debugging DNS and start debugging your laptop.

The record is right but the site is still wrong

Once DNS resolves correctly, the remaining suspects are the server, its virtual host configuration, and any CDN in front of it. An HTTP(S) Check shows the status code and the redirect chain, which usually identifies whether you are hitting the new server at all.

The short version

Nothing propagates. Records change instantly at the authoritative server and slowly everywhere else, and the TTL tells you exactly how slowly. Lower the TTL before a change, not after. And when something looks stuck, query the authoritative nameserver directly: either your change is there and you simply wait, or it is not there and waiting was never going to help.