DNS propagation delays are one of the most frustrating parts of managing a domain. You update a record, wait hours, and visitors still see the old destination. Before concluding that something is broken, it helps to understand what's normal and what genuinely signals an error that needs fixing.
Before troubleshooting propagation, confirm that your authoritative nameserver is already serving the new record. If the authoritative answer is wrong, no amount of waiting will fix propagation — resolvers will keep caching the wrong value. Run dig example.com A +trace to verify the authoritative answer.
Step 1 — Verify the Old vs New Record
The first step is to compare what different resolvers currently serve against what your authoritative server serves. This tells you whether propagation is in progress or whether there is a configuration error.
# Check what your system resolver returns (may be cached)
dig example.com A
# Check authoritative nameserver directly (replace ns1.example.com)
dig example.com A @ns1.example.com
# Check Google's public resolver
dig example.com A @8.8.8.8
# Check Cloudflare's public resolver
dig example.com A @1.1.1.1If the authoritative nameserver returns the new value but public resolvers still return the old one, propagation is simply in progress — the cached TTL has not yet expired on those resolvers. If the authoritative server returns the old value, the problem is in your DNS zone configuration and must be fixed there first.
Step 2 — Check the Remaining TTL
The TTL (Time to Live) tells you the maximum time a resolver will cache a record before re-querying. To see the remaining TTL on a cached record at a public resolver, query it and look at the number in the answer section:
# The number before "IN A" is the remaining TTL in seconds
dig example.com A @8.8.8.8 +noall +answer
# Example output:
# example.com. 2847 IN A 192.0.2.1
# The TTL here is 2847 seconds (~47 minutes) remainingIf the TTL is still high (thousands of seconds), you simply need to wait. If the TTL has already expired but resolvers are still serving the old value, the issue may be that your authoritative server is not yet returning the new record, or the resolver is applying its own minimum TTL floor.
Step 3 — Lower the TTL Before Future Changes
For future DNS changes, lower the TTL well in advance to reduce the propagation window. Change the TTL to 300 seconds at least one full TTL period before the switch, then make the actual record change, and raise the TTL again once the change is confirmed.
; DNS zone file — set a low TTL before making a change
example.com. 300 IN A 192.0.2.1 ; was 86400 (24 hours)
; After confirming the new record is live and propagated,
; raise the TTL back to a reasonable production value
example.com. 3600 IN A 198.51.100.1If the original TTL was 86400 (24 hours), lower it to 300 at least 24 hours before you plan to make the change. That way, when you flip the record, most resolvers will already have the short TTL cached and will re-query within 5 minutes instead of waiting up to 24 hours.
Step 4 — Flush Your Local DNS Cache
Your device maintains its own DNS cache, separate from your ISP's resolver. Even if propagation is complete globally, you may still see the old site until you flush your local cache.
On Windows, open Command Prompt as Administrator and run:
ipconfig /flushdnsOn macOS:
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponderOn Linux (systemd-resolved):
sudo systemctl restart systemd-resolvedStep 5 — Test Against Multiple Resolvers
After flushing your cache, use the ShowDNS DNS Propagation Checker to verify propagation status across global locations. For manual testing, compare Google and Cloudflare's resolvers — two of the most widely used public DNS services:
# Google Public DNS
nslookup example.com 8.8.8.8
# Cloudflare DNS
nslookup example.com 1.1.1.1
# OpenDNS
nslookup example.com 208.67.222.222Step 6 — Check Nameserver Delegation
If you recently changed nameservers at your registrar, the registrar must update the NS records in the parent zone (the TLD registry). Until the registry updates its delegation, the old nameservers remain authoritative. Check the delegation chain:
# Trace the full DNS delegation from root servers
dig example.com A +trace
# Check what the TLD registry says about your nameservers
dig example.com NS @a.gtld-servers.netIf +trace shows the old nameservers at the registry level, the registrar update has not yet propagated to the TLD. Registry NS updates can take up to 24–48 hours. Contact your registrar if the delegation does not update within that window.
Step 7 — Use the DNS Lookup Tool for Targeted Checks
The ShowDNS DNS Lookup tool lets you query a specific resolver for any record type and inspect the full answer, including TTL values. This is useful for checking individual resolvers without installing command-line tools.
When to Contact Your Registrar or Host
Most propagation issues resolve on their own within the TTL window. Contact your registrar or hosting provider if any of the following apply:
- The authoritative nameserver is not returning the correct record after you saved the change in your DNS control panel.
- Nameserver delegation at the TLD registry has not updated after 48 hours.
- Your domain shows SERVFAIL or NXDOMAIN on the authoritative server — indicating a zone configuration error.
- You cannot access your DNS control panel or the changes you make do not appear to be saved.
| Symptom | Likely Cause | Fix |
|---|---|---|
| Old record everywhere after the TTL | Authoritative server still serves old value | Check and update the zone file / DNS panel |
| New record on some resolvers, old on others | Normal propagation in progress | Wait for cached TTL to expire |
| New record globally but browser shows old site | Local DNS or browser cache | Flush local DNS cache, clear browser cache |
| SERVFAIL on all resolvers | Zone error or missing SOA/NS records | Fix zone file; contact host if necessary |
| Nameserver change not propagating after 48h | Registrar did not update the registry | Contact registrar support |
Every time you change a record, you reset the TTL clock. Repeatedly updating a record while it is still propagating extends the window indefinitely. Make one correct change and wait for the TTL to expire before making further adjustments.
Frequently Asked Questions
My DNS change was made hours ago but nothing has changed — what should I do?
First, check that the authoritative nameserver is returning the new value usingdig example.com A @ns1.yourhost.com. If it still shows the old value, the change was not saved correctly in your DNS panel — log back in and re-save. If the authoritative answer is correct, check the TTL on public resolvers and wait for it to expire.
Can I force a DNS resolver to clear its cache?
You cannot force third-party resolvers like 8.8.8.8 or 1.1.1.1 to flush their cache for your domain. However, Google and Cloudflare each provide cache-purge tools: Google's is at Google Public DNS flush and Cloudflare's is available through their 1.1.1.1 dashboard.
Why does 8.8.8.8 show the new record but my ISP's resolver does not?
Different resolvers cached the old record at different times and will expire their caches independently. Your ISP's resolver may have cached the record shortly before your change and still has time remaining on its TTL. It will update automatically once that TTL expires.
Is it safe to change my nameservers while my site is live?
Yes, if you set up the new nameservers with identical records before switching. During the propagation window, different users will be directed by different nameservers, so both old and new nameservers must serve correct, consistent records to avoid downtime for any visitors.
How do I check propagation without command-line tools?
Use the ShowDNS DNS Propagation Checker to check propagation from dozens of locations via a browser. The DNS Lookup tool lets you check a specific record type against any resolver of your choice.