DNS and Domain Problems
DNS Propagation Taking Too Long
Last reviewed
Graphic options · pick what to keep
requestTimeline
decisionTree
statusCompare
serverRack
Direct answer
DNS is not instant—resolvers cache old answers until TTL expires, so some networks see your new A/AAAA or NS records sooner than others. Verify the authoritative zone is correct with dig against the nameserver, lower TTL before future moves, wait out the previous TTL, and fix wrong NS or records instead of assuming propagation is broken.
After a migration or nameserver change, half your team may see the new site while others still hit the old IP or get NXDOMAIN. “Propagation” really means resolver cache plus TTL, not a single global switch. This guide shows how to prove the zone is right, estimate wait time, and spot misconfiguration that looks like slow propagation.
What the error means
When you change NS, A, AAAA, or CNAME records, the authoritative nameserver publishes the new answer immediately—but ISPs, public resolvers (1.1.1.1, 8.8.8.8), operating systems, and browsers cache the previous response for the record’s TTL (time to live). Until that TTL expires, clients may still use the old IP or old NS chain. Propagation is not a mysterious delay inside your host; it is distributed caching. If authoritative dig already shows the correct data but your laptop does not, you are waiting on cache—or editing the wrong DNS panel while NS still point elsewhere. WordPress, SSL, and caching plugins cannot speed up DNS; only correct records, aligned NS, and time (or lower TTL on the next change) fix the mismatch.
Common symptoms
- Some users reach the new site while others still see the old host, parked page, or error
- Online “DNS checker” tools show mixed results across regions and resolvers
- dig @1.1.1.1 and dig @8.8.8.8 return different A/AAAA answers for the same name
- Authoritative dig against the listed NS is correct but your home ISP still serves the old IP
- Change was hours ago but mobile data behaves differently from office Wi‑Fi
- www updated but apex (or reverse) still points at the previous server on some networks
- Email or SSL works on one hostname variant while the other still fails
Most likely causes
- 01 Previous TTL was high (e.g., 86400 seconds) so resolvers legitimately cache for a day
- 02 NS changed but A/AAAA edited at the old DNS host instead of the new authoritative panel
- 03 Split edits—apex updated at registrar default DNS while www lives at Cloudflare (or vice versa)
- 04 Local OS or browser DNS cache holding stale answers after repeated tests
- 05 CDN proxy (orange-cloud) showing edge IPs while origin records were also changed inconsistently
- 06 Corporate or ISP resolver ignoring low TTL and refreshing slowly
- 07 Actual misconfiguration (wrong IP, missing record) mistaken for “slow propagation”
What changed before the problem started
- Nameservers moved to Cloudflare, host DNS, or a new provider
- A/AAAA records updated for a hosting migration
- TTL raised or lowered during the cutover
- Registrar transfer completed with delayed NS updates
- CDN proxy mode toggled (DNS-only vs proxied) changing public IP answers
Troubleshooting steps
- 01
Query the authoritative nameserver directly
Run dig NS yourdomain.com to list nameservers, then dig @ns1.provider.com yourdomain.com A (and AAAA if used) plus www. Authoritative answers show what is live in the zone now, bypassing resolver cache. Success signal: authoritative dig matches the intended hosting or CDN IP documented by your provider.
- 02
Compare public resolvers to authoritative data
Query 1.1.1.1 and 8.8.8.8 for the same names. If they differ from authoritative but match each other’s old IP, you are still inside TTL/cache—not a broken zone. If authoritative is wrong, fix the zone; waiting will not help.
- 03
Confirm NS at the registrar match where you edit records
In the registrar panel, verify NS point to the DNS host whose dashboard you are using. Editing A records at Host A while NS still point at Host B produces “changes that never propagate.” Success signal: dig NS matches the panel where you saved A/AAAA.
- 04
Check apex, www, and critical subdomains together
Migrating only www or only @ is a common partial cutover. Verify both, plus mail-related names if applicable. Success signal: intentional CNAME or A setup documented by the host is present for every public hostname you expect visitors to use.
- 05
Flush local cache and retest from a neutral network
Flush OS DNS cache, try a phone on cellular, or use a VPN/DNS override to 1.1.1.1. Local cache often makes one engineer insist “DNS is broken” while authoritative dig is already correct.
- 06
Wait at least the previous TTL before escalating
Note the TTL on the old record if known (often 300–86400 seconds). Mixed public resolver answers usually converge within that window. Document when the change was made and retest on schedule instead of repeatedly toggling records.
When to stop troubleshooting
Stop repeated DNS edits if authoritative dig is correct but you are within the prior TTL window, you lack registrar access, glue or DNSSEC errors need provider support, or business email is at risk from partial zone changes. Hand off with authoritative dig output, registrar NS screenshot, change timestamp, intended IP, and samples from two public resolvers.
Information to collect before requesting help
- 01 When NS or A/AAAA records were changed and the previous TTL if known
- 02 Authoritative dig output for @ and www from the listed nameserver
- 03 Answers from 1.1.1.1 and 8.8.8.8 for comparison
- 04 Registrar nameserver list vs DNS panel where edits were made
- 05 Intended hosting or CDN IP and proxy mode (DNS-only vs proxied)
- 06 Whether email, SSL validation, or subdomains are also affected
- 07 Screenshots from third-party DNS checkers showing regional mix
How a professional repairs the problem
We prove whether the zone is correct at the authoritative host or still wrong, align NS and A/AAAA for apex and www, and separate true cache delay from misconfiguration. We document TTL strategy for the next change, verify SSL and WordPress URLs once resolvers converge, and leave a single DNS provider of record so future edits are not split across panels.
Frequently asked questions
How long should DNS propagation take? +
Why do DNS checkers disagree? +
Can I force DNS to update faster? +
Is stale DNS a WordPress issue? +
Should I change records repeatedly to “speed propagation”? +
Does Cloudflare always make propagation instant? +
Repair dispatch
Still Need Help Fixing Your Website?
If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.
- You will receive a clear explanation of the likely cause.
- We will tell you if the issue falls outside our repair scope.
- No additional work will be performed without approval.
- A backup should be created whenever access and website condition allow it.
Do not share passwords through an unencrypted contact form.