DNS propagation is the time it takes for DNS resolvers around the world to let go of their cached copy of a record and fetch the new one. Nothing is pushed anywhere. A record change usually reaches everyone within the record's old TTL (often 5 minutes to an hour), while a name server change can take 24 to 48 hours. To check it, ask public resolvers such as 1.1.1.1 and 8.8.8.8 directly with dig or nslookup and compare their answers with your authoritative name servers.
Here's why the wait varies, the commands to check it yourself, and how to make a planned change take minutes instead of a day.
What "propagation" really is
When you save a record at your DNS provider, the provider's authoritative name servers start giving the new answer almost at once, typically within seconds to a minute.
Visitors don't ask those servers directly. They ask a recursive resolver: their ISP's, their company's, or a public one such as Google's 8.8.8.8 or Cloudflare's 1.1.1.1. The resolver looks the answer up once and keeps it for the number of seconds set in the record's TTL (time to live). Until that timer runs out, it keeps handing out the old answer without asking again.
So "propagation" is really thousands of independent caches expiring at different moments. Each resolver cached the record at a different time, which is why you can see the new site while a colleague on another network still sees the old one. Operating systems and browsers keep short-lived caches of their own.
How long DNS propagation takes
The worst case is the TTL the record had before you changed it. The new TTL only applies to resolvers that have already picked up the new record.
| Change | Typical wait | What decides it |
|---|---|---|
| Edit or delete an existing A, AAAA, CNAME, MX or TXT record | Up to the old TTL: 5 minutes at 300, an hour at 3600, a day at 86400 | Resolver caches of the old answer |
| Add a record for a name that didn't exist | Seconds to minutes | Nothing is cached, unless the name was looked up earlier (see negative caching below) |
| Change name servers at the registrar | 24 to 48 hours | The delegation held by the TLD has its own long TTL (two days for .com and .net) |
Some resolvers and home routers hold answers a little longer than the TTL says, which is where the old "allow 48 hours" advice comes from. For an ordinary record change with a sensible TTL, most visitors move within the hour.
How to check DNS propagation yourself
Replace example.com with your own name. dig ships with macOS and comes in the dnsutils or bind-utils package on Linux. On Windows use nslookup or PowerShell.
1. Ask the authoritative name servers
First confirm the change is really published. List the domain's name servers, then ask one of them directly:
dig example.com NS +short # ask the first name server in that list, with the TTL shown dig @$(dig example.com NS +short | head -n 1) example.com A +noall +answer # example.com. 3600 IN A 203.0.113.10
This answer hasn't been through any cache. If it's wrong here, the problem is in your DNS settings and waiting won't help. The second column is the TTL in seconds.
2. Ask several public resolvers
dig @1.1.1.1 example.com A +short # Cloudflare dig @8.8.8.8 example.com A +short # Google dig @9.9.9.9 example.com A +short # Quad9 dig @208.67.222.222 example.com A +short # OpenDNS
If they all return the new address, most of the world sees the change. A mix of old and new means caches are still expiring. To see how long a resolver will keep its current answer, drop +short and read the TTL counting down:
dig @1.1.1.1 example.com A +noall +answer # example.com. 1742 IN A 198.51.100.7 (old address, 1742 seconds left)
Large public resolvers run many servers with separate caches, so two queries a few seconds apart can return different answers for a while. That's normal.
The same checks with nslookup (the last argument is the resolver to ask) and with PowerShell:
nslookup example.com 1.1.1.1 nslookup -type=AAAA example.com 8.8.8.8 nslookup -type=NS example.com Resolve-DnsName example.com -Type A -Server 1.1.1.1
3. Follow the whole chain
dig +trace example.com
+trace starts at the root servers and follows each referral down to your name servers, ignoring caches. Run it after a name server change: the referral from the TLD shows which name servers it's handing out right now.
4. Check your own machine last
If public resolvers return the new address but your browser still shows the old site, the stale copy is local. Flush it, then test in a private window:
# macOS sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder # Windows ipconfig /flushdns # Linux with systemd-resolved resolvectl flush-caches
See how to check if a site is down for everyone or just you for the other local causes.
How to speed up a planned DNS change
You can't hurry a cache that already holds the old record. You can make sure that, by the time you switch, every cache holds a short-lived copy:
- Check the current TTL with the authoritative query above.
- Lower the TTL to 300 seconds at least one full old TTL before the change. If the TTL is 86400, do it a day ahead. Change nothing else yet.
- Wait for the old TTL to pass. Every resolver now holds a copy that expires in 5 minutes.
- Make the change. Within about 5 minutes nearly all traffic is on the new address, and a rollback is just as quick.
- Keep the old server running for a day or two and watch its access log until the requests stop.
- Raise the TTL again (an hour or more) once everything is stable.
After an unplanned change there's one small lever: Google Public DNS and Cloudflare's 1.1.1.1 each have a public page for flushing a cached name. It helps for those two resolvers only.
Common mistakes
Changing name servers when you only needed to change a record
Moving a site to a new host needs a new A record (and AAAA, if you use IPv6). Changing the name servers moves the whole zone to a different DNS provider: every record, including MX and the TXT records used for email, has to exist at the new provider first, or mail and subdomains break. It's slower too. The TLD's delegation is cached for up to two days, and meanwhile some resolvers ask the old name servers and some the new ones. Keep both zones identical and keep the old provider answering for at least 48 hours. If the domain uses DNSSEC, sort out the DS record before you switch, or validating resolvers will refuse to resolve the domain at all.
Forgetting the AAAA record
If the name has an AAAA record that still points at the old server and you only update the A record, visitors on IPv6 networks (many mobile networks are) keep landing on the old server. Check both, and check www as well as the bare domain:
dig @1.1.1.1 example.com AAAA +short dig @1.1.1.1 www.example.com A +short
Negative caching
If anyone looks up a name before its record exists, the resolver caches the "no such name" answer too. How long is set by the zone's SOA record:
dig example.com SOA +noall +answer # example.com. 3600 IN SOA ns1.dns-provider.net. hostmaster.example.com. 2026110901 7200 3600 1209600 1800
The last number (1800 here) is the limit in seconds, unless the SOA record's own TTL is lower. So create the record first, then open the new hostname in a browser or send it to anyone.
What to monitor during a DNS change
A DNS switch usually fails on the new side, not in DNS: the new server has no certificate, a firewall refuses connections, or a redirect is missing. Watch these while caches expire:
- Both hostnames, from outside. An uptime monitor resolves the name, connects and requests the page on every check, so a DNS failure, a refused connection, a timeout or a 5xx from the new server shows up with its time and error. Upmonora checks every 5 minutes on the Free plan, every minute on Starter and every 30 seconds on Business.
- The certificate on the new server. It has to be valid for every hostname before traffic arrives. An uptime check fails on an invalid certificate, and SSL monitoring keeps watching validity, hostname match and expiry afterwards. To look by hand, see how to check an SSL certificate.
- Redirects. Confirm that http, https, www and the bare domain still end at one address on the new server. The free WWW Redirect Checker tests all four versions at once.
- CDN error pages. If the change put the site behind Cloudflare, a 521 or 522 means Cloudflare can't reach your origin. See Cloudflare 520, 521, 522 and 524 errors.
- Traffic on the old server. It should fall to nothing. If it doesn't, something still points there: a forgotten AAAA record or a hard-coded IP.
One caveat: a monitor sees DNS through its own resolver, like any single visitor. It proves the new destination works, not that every cache has expired. Use the dig checks above for that.
For a quick look from outside your own network, the free website checker shows the status code, response time and certificate of any public URL. To watch a whole switch, the free plan covers 5 monitors.
Frequently asked questions
How long does DNS propagation take?
Usually as long as the TTL of the record you changed: a few minutes to a few hours for A, AAAA, CNAME and MX records. A name server change at the registrar can take 24 to 48 hours, because the delegation is cached for much longer.
How do I check if DNS has propagated?
Ask several public resolvers directly and compare their answers with your authoritative name servers, for example: dig @1.1.1.1 example.com A +short and dig @8.8.8.8 example.com A +short. When they all return the new value, most visitors are seeing the change.
Can I speed up DNS propagation?
Not after the change, apart from flushing your own caches. You can make a planned change fast by lowering the record's TTL to about 300 seconds at least one old TTL before you switch, so resolvers only hold the old answer for a few minutes.
Why do I still see the old site after changing DNS?
Your resolver, operating system or browser still has the old answer cached. Query a public resolver such as 1.1.1.1 with dig or nslookup. If it returns the new address, flush your local DNS cache or wait for the TTL to run out.
