DNS Propagation: How Long It Really Takes, Why, and How to Check
You changed a DNS record. Your laptop sees the new value. Your colleague's does not. A customer in another country says the site is down. Your registrar's help page says "allow up to 48 hours". Nobody says why.
This is DNS propagation, and the name is misleading. Nothing is being propagated. Your change was live on your authoritative nameservers the moment you saved it. What you are waiting for is every cache between you and those nameservers to throw away the old answer.
What is actually happening
When a device looks up www.example.com, it almost never asks your nameservers directly. It asks a recursive resolver, the one your ISP, your office or a public service like 1.1.1.1 or 8.8.8.8 runs, and that resolver either answers from its cache or goes and finds out.
Every DNS record carries a TTL (time to live), in seconds. When a resolver fetches your record it stores the answer and reuses it, without asking again, until the TTL runs out. If your A record had a TTL of 3600 and a resolver fetched it one minute before you changed it, that resolver will keep serving the old address for another 59 minutes. No amount of waiting on your end changes that, because the resolver simply does not ask.
So "propagation time" is really the longest remaining TTL on the old answer, in whichever cache the person complaining happens to be behind. That is why it looks random. It is not random: it is a set of independent countdowns that started at different moments.
There are more caches than most people expect:
Your operating system keeps a small resolver cache.
Your browser keeps its own, separately.
The recursive resolver you use. Large public resolvers are many separate cache nodes behind one IP, which is why
8.8.8.8can give two different answers a minute apart.Corporate and ISP forwarders that sit in front of the recursive resolver and cache again.
Each one honours the TTL independently. A change has "propagated" when all of them have expired the old record.
How long does DNS propagation take?
It depends entirely on what you changed.
Changing a record (A, AAAA, CNAME, MX, TXT)
The worst case is the record's old TTL. If the TTL was 300 seconds, effectively everyone sees the change within five minutes. If it was 86400, a common default, some resolvers will serve the old value for up to a day. The TTL that matters is the one on the record before you changed it, because that is what caches were told when they last fetched it. What is DNS TTL? covers how to pick values.
Changing nameservers
This is the case behind the "48 hours" folklore, and it is the one case where the number is real.
Your domain's nameservers are published in two places: in your own zone, and, the one that matters, in the TLD zone as a delegation. When you move example.com to another DNS provider, the .com registry updates the NS records for example.com in the .com zone. Those delegation records, and the glue addresses that go with them, are served with a TTL of 172,800 seconds, exactly 48 hours, and you cannot change it because the registry sets it. A resolver that looked up your delegation an hour before you switched providers will keep asking the old nameservers for up to two days.
That is where 48 hours comes from. It applies only to nameserver changes, and many resolvers pick up the change sooner, but Cloudflare found that a large share of resolvers took at least eight hours, and the full switch can take the whole two days.
The practical consequence: keep the old nameservers running and serving identical records for 48 hours after a nameserver change. If you cancel the old provider the day you switch, the part of the internet still delegated to them gets a dead server. If you are moving between providers, how to change nameservers has the steps for the common ones.
Adding a record that did not exist
The third case surprises people: you add a record, and some resolvers keep saying it does not exist. That is negative caching. When a resolver asks for a name and gets NXDOMAIN, it caches the "no such record" answer too, for a time set by your zone's SOA record (RFC 2308). If someone, a monitoring script or a mail server queried the name before you created it, that resolver will insist it does not exist until the negative cache expires. Check your SOA minimum before creating records you need to appear quickly.
How to change DNS with no visible downtime
The delay is predictable, so it can be planned around. The procedure experienced DNS operators use:
Lower the TTL first, then wait. A day or two before the change, set the record's TTL to 300. Then wait the old TTL (if it was 86400, wait 24 hours) so every cache has fetched the record with the new short TTL.
Make the change. Now the worst case is five minutes.
Verify against the authoritative servers, not your own resolver.
dig @ns1.yourprovider.com www.example.comtells you what the source of truth says.dig www.example.comonly tells you what your cache says.Watch it spread. Query a spread of public resolvers, or use the DNS propagation checker, which shows the TTL remaining on each cached answer so you can see how long each resolver will keep the old value.
Raise the TTL back once you are satisfied. Short TTLs mean more queries to your nameservers and slower resolution for users. 3600 is a reasonable resting value for most records.
For nameserver changes, keep both providers serving identical zones for 48 hours.
How to check whether DNS has propagated
Ask the authoritative server directly
dig +short www.example.com @ns1.yourprovider.comIf this shows the new value, your change is live at the source. Everything else is caching.
Ask a specific public resolver
dig www.example.com @1.1.1.1
dig www.example.com @8.8.8.8
nslookup www.example.com 9.9.9.9The number after the name in the ANSWER SECTION is the TTL remaining on that resolver's cached copy: how many more seconds it will serve what you are seeing. A full TTL (3600 on a 3600 record) means it just fetched a fresh copy. A low number means it is about to.
Check many resolvers at once
DNS Spy's free DNS propagation checker queries 40+ public resolvers around the world and shows, for each one, the answer it returned, the TTL remaining on it, the response time, and whether the answer was DNSSEC-validated. It is the same check as above, run everywhere at once, with the countdowns visible. No account, no ads.
Flush your own caches
If the only place still showing the old answer is your own machine, clear the local cache:
Windows:
ipconfig /flushdnsmacOS:
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponderLinux (systemd-resolved):
sudo resolvectl flush-cachesChrome or Edge: open
chrome://net-internals/#dns(oredge://net-internals/#dns) and clear the host cache.
This does nothing for anyone else. It only removes your own stale copy.
Common propagation problems that are not propagation
If it has been longer than the old TTL and resolvers still disagree, stop waiting and look for these:
The change did not save, or saved to the wrong zone. Query the authoritative server first. If it shows the old value, no cache is involved.
Two providers, two zones. After a nameserver move, the old provider's zone still answers for resolvers that have not picked up the new delegation, and it has the old records. Update both zones during the overlap.
Nameservers not updated at the registrar. You changed the
NSrecords inside your zone but not at the registrar, so the TLD delegation still points at the old provider. Check withdig NS example.com @a.gtld-servers.net(for.com) or your TLD's registry server.A negative cache from a lookup made before the record existed, as above.
A CDN or proxy in front of the record. With Cloudflare's proxy turned on, for instance, the
Arecord the world sees is Cloudflare's, not yours, so changing your origin changes nothing publicly.DNSSEC signatures not updated. If the zone is signed and the new record was not re-signed, validating resolvers will reject it. The propagation checker shows validation status per resolver for exactly this reason.
The other direction: changes you did not make
Everything above assumes you made the change. The same mechanics apply when you did not.
If an attacker, a colleague or an automated integration changes a record on your authoritative nameservers, caches hide it from you in exactly the same way they hide your own changes from the world. Your office resolver keeps serving the old record until its TTL runs out, so by the time you notice, the change may have been live for hours. Nameserver changes at the registrar are the worst case: they can take two days to reach you, and they are the change that hands the whole domain to someone else.
That is why monitoring has to query the authoritative servers, not a cache. DNS Spy re-resolves every monitored domain directly from its nameservers at least every ten minutes, records every change to every record with a timestamp, and alerts on the change itself: what it was, what it is now, and which nameserver answered. A domain's DNS history is then a record of what actually happened, not of what a cache eventually showed. See DNS record monitoring for how it works.
Summary
Propagation is cache expiry. Your change is live at the source immediately.
Record changes take up to the old TTL. Lower it in advance and the wait is minutes.
Nameserver changes take up to 48 hours because the TLD delegation TTL is 172,800 seconds and you cannot change it. Keep the old provider running.
New records can be hidden by negative caching for the SOA minimum.
Verify at the authoritative server first, then check resolvers, then flush your own cache.
Monitoring that watches the authoritative servers sees changes, yours and anyone else's, before any cache does.
Related
Check This on Your Own Domain
DNS Spy's free scan reads your live DNS, nameservers, SSL and email-authentication records and reports what it finds. No account required. Scan a domain →
If you want the same checks to keep running: DNS Spy re-resolves every monitored domain at least every ten minutes and alerts you when a record changes. See how monitoring works →
Frequently asked questions
How long does DNS propagation take?
DNS propagation takes as long as the old TTL on the record you changed, often an hour or less, because caches keep the old answer until it expires. Nameserver changes are the exception: the TLD delegation is cached for 48 hours, and you cannot shorten it, so allow two full days.
Why does DNS propagation take 48 hours?
The 48 hours applies to nameserver changes. TLD registries such as the .com registry publish your domain's delegation with a TTL of 172,800 seconds, exactly 48 hours, so a resolver that cached it just before you switched providers can keep using the old nameservers for up to two days.
Can I speed up DNS propagation?
You cannot force other resolvers to drop their cache, but you can plan ahead. Lower the record's TTL to 300 seconds a day or two before the change and wait out the old TTL. When you then make the change, most resolvers pick it up within five minutes.
How do I check if DNS has propagated?
First query your authoritative nameserver directly with dig, which shows the true current value. Then check public resolvers, either one at a time with dig or all at once with a propagation checker that shows each resolver's answer and the TTL remaining before its cached copy expires.
