How Long Does DNS Propagation Take?
Short answer: most DNS record changes are visible worldwide within the record's TTL, usually somewhere between 5 minutes and an hour. Nameserver changes take longer, up to 48 hours, because the registry for your domain extension caches them for two days. Nothing physically "propagates". What you're waiting for is thousands of independent caches to expire their old copy.
Once you know which caches are involved and how long each one holds on, you can predict the wait, cut it down, and check progress instead of guessing.
What "DNS propagation" actually is
When someone visits example.com, their device asks a recursive resolver (their ISP's, or a public one like 1.1.1.1 or 8.8.8.8). The resolver asks your domain's authoritative nameserver, gets the answer, and caches it for as long as the record's TTL (time to live) says.
When you change the record, your authoritative nameserver has the new value immediately. Every resolver that cached the old value keeps serving it until its copy expires. Different resolvers cached it at different times, so the switch happens gradually, resolver by resolver. That rolling expiry is what people call propagation.
Typical wait times
| Change | What controls the wait | Typical wait |
|---|---|---|
| A / AAAA / CNAME record, TTL 300 | Record TTL | Up to 5 minutes |
| A / AAAA / CNAME record, TTL 3600 | Record TTL | Up to 1 hour |
| Record with TTL 86400 | Record TTL | Up to 24 hours |
| New record that didn't exist before | Negative cache (SOA minimum) | Minutes to an hour, if anyone looked it up before it existed |
| Nameserver (NS) change at the registrar | TLD's NS TTL (2 days for .com/.net) | A few hours, up to 48 hours |
Why the 24–48 hour figure exists
When you switch nameservers, say from your registrar's DNS to Cloudflare, the change is published in the TLD zone, not in your own zone. For .com and .net, those delegation records carry a TTL of 172,800 seconds, which is two days. A resolver that cached the old delegation just before your change can keep asking the old nameservers for up to 48 hours.
That's why hosting companies quote "24 to 48 hours". It's the worst case for a nameserver change, and support teams quote it for every kind of change. If you only edit an A record at your existing DNS host, the record's own TTL is the only thing you're waiting on.
See it yourself:
dig NS example.com @a.gtld-servers.net
# ...
# example.com. 172800 IN NS ns1.your-dns-host.com.That second column is the TTL in seconds.
How to check propagation
1. Confirm the authoritative answer
Ask your nameserver directly. If this is wrong, nothing downstream will ever be right:
dig +short NS example.com # find your nameservers
dig +short example.com @ns1.your-dns-host.com2. Compare public resolvers
for r in 1.1.1.1 8.8.8.8 9.9.9.9 208.67.222.222; do
printf "%-16s " "$r"; dig +short example.com @"$r" | head -1
doneOn Windows: nslookup example.com 8.8.8.8.
3. Read the remaining TTL
A resolver's answer shows how many seconds it will keep serving that answer:
dig example.com @8.8.8.8 +noall +answer
# example.com. 1873 IN A 198.51.100.4If that resolver still shows the old IP with 1873 seconds left, it will switch in about 31 minutes. Run it again and the number counts down. Large public resolvers run many independent cache nodes, so repeated queries can show different values.
4. Use a global checker
Sites like whatsmydns.net and dnschecker.org query resolvers in dozens of countries at once. They're useful for a quick overview, but treat them as a sample, not proof that every resolver has updated.
How to make the next change fast
You can't shorten a cache that already holds your record, but you can plan so the caches are short when you make the change:
- Lower the TTL first. Set the record you'll change to
300. - Wait out the old TTL. If it was 86400, wait at least 24 hours so every cache has picked up the 300-second version.
- Make the change. Now the worst case is about 5 minutes.
- Keep the old server running for a day or two anyway. Some resolvers enforce a minimum TTL or misbehave.
- Raise the TTL back to 3600 or more once everything is confirmed.
Avoid changing nameservers and the server IP on the same day. Move DNS hosting first, let it settle, then change the A record with a low TTL. The website migration checklist puts these steps in order.
Things that make it look slower than it is
- Your own caches. Your OS and browser cache DNS too. Flush them before deciding propagation is stuck.
- Negative caching. If you checked a hostname before creating it, resolvers cached "does not exist" for the zone's SOA minimum TTL. New subdomains are the usual victim.
- IPv6. If an old AAAA record is still there, IPv6 users keep reaching the old server while your IPv4 tests look fine. Update or delete AAAA alongside A.
- CDN or proxy in front. With Cloudflare's proxy turned on, public DNS shows Cloudflare's IPs whatever your origin is. Check the origin setting in the dashboard instead.
Preview the new server without waiting
The wait only matters for visitors. You can test the new server before you change anything:
- curl:
curl -I --resolve example.com:443:203.0.113.10 https://example.com/sends one request straight to the new IP. See the curl --resolve guide. - Hosts file: maps the domain to the new IP on your machine only. It works, but it's easy to forget to remove.
- skipdns.dev: enter the new IP and domain at skipdns.dev and get a link that serves the site from the new server under its real hostname. It works in any browser, on phones, and for clients you send the link to. It's free, needs no account, and links last 7 days.
Testing first means the DNS change becomes a formality: by the time caches expire, you already know the new server works.
FAQ
Does DNS propagation really take 48 hours?
Rarely. A normal A record change is visible everywhere within the record's TTL, which is often 5 minutes to 1 hour. The 24 to 48 hour figure comes from nameserver changes, because TLD registries like .com publish NS records with a 2-day TTL.
Can I speed up DNS propagation?
Only in advance. Lower the record's TTL to 300 seconds at least one full old-TTL period before the change, so caches pick up the short TTL first. Once the change is made, you can't shorten caches that already hold the old answer.
Why do I see the new IP but my friend sees the old one?
You're using different resolvers, and each one cached the record at a different moment. Each will switch when its own copy expires. Compare with dig +short example.com @1.1.1.1 and @8.8.8.8.
What TTL should I use?
3600 seconds (1 hour) is a sensible default for records that rarely change. Drop to 300 a day before a migration, and raise it back once the move is confirmed. Very low TTLs everywhere mean more lookups and slightly slower first page loads.
How can I see my site on the new server before DNS updates?
Use a hosts file entry, curl --resolve for command-line checks, or a skipdns.dev preview link, which loads the site from the new IP under its real domain in any browser and can be shared.
Does flushing my DNS cache speed up propagation?
It only clears your own device. If your resolver still holds the old record, you'll get the old record again. See how to flush DNS for where caches live.