DNS Propagation:Why Changes Take Time and How to Check
Why DNS changes do not appear everywhere at once, how TTL controls the delay, how to check propagation from different locations, and how to plan changes so visitors barely notice.
Table of Contents
"DNS propagation" is the time it takes for a DNS change to be seen everywhere. Nothing is actually pushed around the internet: resolvers keep cached copies of DNS answers for as long as each record's TTL allows, so some visitors see the old answer until their resolver's cache expires. Record changes usually take effect within the record's TTL; nameserver changes can take up to 24–48 hours because the TLD's NS records carry longer TTLs.
Understanding this lets you plan changes so they take effect quickly and predictably.
Why changes are not instant
When a resolver looks up example.com, it stores the answer for the record's TTL (time to live), for example 3600 seconds. Until that hour is up, it answers from its cache without asking your DNS host again. Different resolvers cached the answer at different times, so they expire at different times. That staggered expiry is what people call propagation.
Other caches add to it:
- the operating system's DNS cache;
- the browser's own DNS cache;
- some internet providers' resolvers, which may hold answers longer than the TTL.
Record changes vs nameserver changes
| Change | What controls the delay | Typical time |
|---|---|---|
| Edit an A, CNAME, MX or TXT record | That record's TTL | Minutes to the TTL value |
| Change nameservers at the registrar | TTL of the NS records at the TLD, plus registry update time | Often a few hours, up to 24–48 hours |
| Add a brand-new record | Negative caching (how long "does not exist" is cached) | Usually minutes to an hour |
How to plan a change
- Lower the TTL in advance. A day or two before the change, reduce the TTL of the records you will change to about 300 seconds. Wait at least the old TTL so resolvers pick up the shorter one.
- Make the change at a quiet time.
- Keep the old service running until traffic and email have moved.
- Raise the TTL again (for example to 3600) once everything is stable.
This is how moving a website to a new host without downtime works.
How to check propagation
- Online DNS checkers query resolvers in many countries and show which answer each one returns.
- Query your authoritative nameservers directly to confirm the change was saved:
dig @ns1.yourdnshost.com example.com A. - Query a public resolver:
dig @1.1.1.1 example.com Aornslookup example.com 8.8.8.8. - Check the TTL in the answer: it counts down as the cache ages.
If the authoritative nameservers already return the new value, the change is correct and you are only waiting for caches.
Seeing the new site on your own computer
- Flush your local DNS cache: on Windows run
ipconfig /flushdns; on macOS and Linux the command depends on the version. - Restart the browser or use a private window.
- Use a hosts-file entry to test the new server before DNS changes at all.
Worked example: a planned A record change
A business moves its website to a new server on Thursday evening. The A record's TTL is currently 14400 seconds (four hours).
- Wednesday morning: the TTL of the A record is lowered to 300 seconds. Resolvers that cached the old record keep it for up to four more hours; after that, they cache it for only five minutes.
- Thursday 9 pm: the A record is changed to the new server's IP. Within about five minutes, most resolvers ask again and receive the new address.
- Thursday 9:30 pm: an online DNS checker shows the new IP almost everywhere; a few resolvers that ignore short TTLs still show the old one, so the old server keeps running.
- Saturday: the TTL is raised back to 3600 seconds, and the old server is retired the following week.
Without lowering the TTL first, some visitors could have kept reaching the old server for up to four hours after the change, or longer with resolvers that cache aggressively.
Testing from different resolvers
dig @1.1.1.1 example.com A +short # Cloudflare's public resolver
dig @8.8.8.8 example.com A +short # Google's public resolver
dig @9.9.9.9 example.com A +short # Quad9
Different answers from different resolvers during a change are normal. Consistent old answers after the TTL has passed suggest the change was made in the wrong place.
When it is not propagation
If hours have passed and nothing changed, look for another cause:
- The change was made at the wrong DNS host. Records only matter at the host your nameservers point to; see nameservers vs DNS records.
- A typo in the record name or value.
- The domain is expired or on hold; check with a WHOIS lookup.
- DNSSEC problems after changing DNS host, which make validating resolvers return errors.
- A CDN or proxy in front of the site still pointing to the old origin.
Frequently Asked Questions
Can I speed up propagation?
Only before the change, by lowering the TTL in advance. After the change, you wait for caches to expire, although you can flush your own local cache.
Why does my phone show the new site but my laptop shows the old one?
They use different resolvers or have cached the answer at different times. Mobile data, home Wi-Fi and office networks often use different resolvers.
Is 48 hours always required?
No. That figure is a cautious upper bound for nameserver changes. Planned record changes with a short TTL usually take effect within minutes.
Related reading
For how DNS works overall, see what is DNS and domain names explained. Connecting a domain step by step is covered in how to point a domain to hosting. Still stuck? Contact ServerNeed support.
Sources
Last updated 7 October 2026
