DNS TROUBLESHOOTING GUIDE
DNS Propagation: Why Your DNS Changes Aren't Showing
You have saved a DNS change, but your website still reaches the old server or your email still goes to the previous provider. Often, different recursive DNS resolvers are answering from their own caches. Their cached answers expire or refresh at different times, so the same hostname can temporarily produce different results.
This can happen when you move a website, change nameservers or DNS providers, update an A or CNAME record, change MX records for business email, or add a TXT record for domain verification. Waiting may be appropriate—but only after you confirm the change was made in the active authoritative DNS zone.
Check these first
Verify the exact hostname and record type, confirm the domain’s active nameservers, and compare authoritative answers with recursive resolver results. Then check TTLs, negative caching, and local DNS settings. If the authoritative records are wrong, more waiting will not repair them.
What Is DNS Propagation?
“DNS propagation” is the common name for the period during which a DNS change becomes visible through different lookup paths. It does not usually mean your new record is being copied simultaneously to every DNS server worldwide. Authoritative servers publish the zone, while recursive resolvers reuse previously cached answers until they need to refresh them.
Authoritative DNS servers
These servers hold and serve the DNS zone for your domain. Your DNS provider must publish a change to the servers that actually answer for that zone. If the provider’s authoritative servers disagree, ask the provider to investigate zone publication rather than assuming ordinary resolver caching.
Recursive DNS resolvers
Your ISP, workplace, Google Public DNS, Cloudflare, or another service may provide a recursive resolver. It finds answers on your behalf and caches them according to TTL and its own supported behavior. Two resolvers can have cached the same record at different times.
Device and browser caches
Your operating system and browser can also keep lookup information. A browser using DNS-over-HTTPS may use a different resolver from your operating system. VPNs and private networks may intentionally use their own DNS views.
A typical lookup starts with a browser or operating-system cache. If it needs a fresh answer, it asks a recursive resolver. That resolver either uses its cache or follows DNS delegations to an authoritative server. Private DNS, browser Secure DNS, and other network arrangements can change this path.
How Long Does DNS Propagation Take?
Some changes become visible within minutes, particularly when a resolver has no old answer cached. Previously cached responses can persist for hours when their original TTL is longer. A record with a nominal one-hour TTL does not mean every user starts the same one-hour countdown when you press Save.
Nameserver changes can take longer to become consistently visible because registrar or registry processing and cached delegation information are involved, alongside cached records inside the zone. Confirm that the registrar has applied the intended delegation; a record’s own TTL is not the only relevant timer.
There is no universal 24–48-hour completion time. TTLs, lookup timing, provider publication, and resolver behavior all affect what you observe. Some resolvers may serve stale answers temporarily when fresh data cannot be obtained, so a nominal TTL is not an absolute deadline for every lookup.
Negative caching: when the old answer was “not found”
A resolver can cache NXDOMAIN responses and empty answers for missing record types. If you add a TXT verification record or create a new hostname after a failed lookup, that resolver may keep returning the earlier negative answer until its negative cache expires. This is governed by the zone’s SOA-derived negative-cache lifetime and resolver behavior, not simply by the TTL of the newly added record.
First verify that authoritative servers now return the expected record. If they do, compare recursive results and allow the relevant cached data to expire. If they do not, investigate the configuration instead of restarting the waiting period.
How to Check DNS Propagation
1. Open Hostingcone’s Free DNS Lookup Tool.
2. Enter the domain or exact hostname you changed, such as www.example.com or _dmarc.example.com. Do not include https:// or a page path.
3. Review the relevant A, AAAA, MX, TXT, CNAME, or NS records. A successful A lookup does not verify a separate TXT or MX change.
4. Use the resolver comparison option and examine the available Google Public DNS and Cloudflare results.
5. Compare the returned values with your intended DNS configuration, including MX priorities, full TXT values, and the correct hostname.
Agreement between Google Public DNS and Cloudflare is useful evidence, but it does not prove that every resolver worldwide has updated. These services also use distributed infrastructure, so a comparison represents the queries made by the tool, not every cache within either provider. The tool checks public records and selected common hostnames; it does not discover an entire DNS zone.
Compare cached answers with the source
Where dig is available, compare public resolver answers, then query an authoritative nameserver directly. Replace the examples with your hostname and a verified authoritative server for its zone. The ns1.example.net name below is illustrative, not a Hostingcone server.
dig @8.8.8.8 example.com Adig @1.1.1.1 example.com A
dig @ns1.example.net example.com A +norecurse
Check the response status, returned values, and whether the direct answer is authoritative. If the authoritative answer is current but a recursive answer is old, caching is plausible. If a command times out, the network may restrict direct DNS queries; that alone does not prove the record is missing. Check each authoritative server when you suspect inconsistent zone publication.
Understanding DNS TTL
Time to Live (TTL) is a record’s nominal cache lifetime, expressed in seconds. A recursive resolver normally reduces the remaining TTL as a cached answer ages. A fresh lookup after that answer expires can retrieve the current record from authoritative DNS.
TTL
Approximate cache lifetime
300 seconds
5 minutes
900 seconds
15 minutes
3600 seconds
1 hour
86400 seconds
24 hours
These conversions describe nominal TTL durations, not guaranteed propagation deadlines. Different records and delegation information can have different TTLs. Negative answers and exceptional resolver behavior also matter.
Lower TTL before a planned migration
If your provider allows it, lower the relevant TTL well before the migration and leave time for answers cached under the previous, longer TTL to expire. For example, if the old TTL was 24 hours, reducing it shortly before the cutover cannot remove copies already cached for that longer period. Plan website and email migrations with overlapping service availability where appropriate.
Lowering TTL after a record is already cached does not push an invalidation message to remote resolvers. It affects newly obtained answers. Once the migration is verified, choose an appropriate stable TTL rather than keeping every record unnecessarily short.
Why Your DNS Changes Aren't Showing
1. Previous DNS answers are still cached
Recognize it: authoritative servers return the new value while one or more recursive resolvers still return the old value. Check the remaining TTL, previous TTL, and any cached negative answers. Retest the exact hostname and record type after relevant caches expire; repeatedly saving the same record does not clear remote caches.
2. Records were changed at the wrong provider
Recognize it: the control panel shows your edit, but the active authoritative servers still serve a different record. Check which nameservers the registrar delegates to and which zone they serve. Make the correction at that active provider instead of copying changes into several inactive panels.
3. Unexpected authoritative nameservers
Recognize it: NS or delegation checks point to a previous DNS host or an unintended service. Verify the registrar’s nameserver assignment and whether the intended provider has an active zone. For delegated subdomains, also check the parent zone’s delegation. Do not change nameservers casually: a zone migration can affect web, email, and verification records together.
4. An incorrectly entered hostname
Recognize it: the root domain works but www or a verification name does not, or the panel created a doubled name such as www.example.com.example.com. Check whether the panel expects a short label or a fully qualified name. Query the exact record name required by the service, including prefixes such as _dmarc or a DKIM selector.
5. Conflicting or incorrect records
Recognize it: lookup results contain extra addresses, a wrong destination, or old mail servers. Compare all records of the relevant type with the provider’s requirements. A stale AAAA record can send IPv6-capable users to a different server even when A is correct. An ordinary CNAME must not coexist with other data at the same name; follow provider-specific guidance for apex alias or flattening features.
6. Cloudflare proxying changes the public answer
Recognize it: a proxied hostname returns Cloudflare edge addresses rather than your configured origin IP, or a CNAME target is not exposed as expected. This can be normal proxy or flattening behavior rather than propagation failure. Compare the proxy setting and origin record in the dashboard with the public answer. Do not disable a required proxy merely to force an IP match; the change can affect security and availability.
7. DNSSEC or delegation failures
Recognize it: lookups consistently return SERVFAIL, time out, or fail only through validating resolvers. After a DNS-provider move, a stale DS record at the registrar can mismatch the new zone’s DNSKEY records. Ask the registrar or DNS provider to verify delegation and the signing chain. DNSSEC failures commonly cause SERVFAIL, rather than a normal cached old value; do not blindly disable DNSSEC.
8. Device, VPN, or network DNS settings
Recognize it: public lookups look correct but one device or network still fails. Check the operating-system cache, browser Secure DNS, VPN DNS, router resolver, private DNS views, and any hosts-file override. Compare another device and a different network before editing public records. Restore any temporary test changes and respect organization-managed settings.
How to Refresh DNS on Your Device
Windows
Open Command Prompt, using Run as administrator if your Windows configuration requires it, and run:
ipconfig /flushdnsThis clears the local Windows DNS resolver cache. It does not clear ISP caches, Google or Cloudflare caches, or every browser-managed DNS cache. Retest the site and compare your configured resolver before making broader network changes.
macOS
On many modern macOS versions, open Terminal and use this example. Enter your administrator password when prompted; password characters are not displayed.
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponderBehavior and commands can differ between macOS versions. Successful execution may show no confirmation message. Check version-specific guidance if the command is unavailable; it only refreshes local lookup state, not public resolver caches.
Linux
There is no universal cache-flush command for every Linux distribution. Identify the active resolver or caching service first. If the system actually uses systemd-resolved and resolvectl is available, these commands show its status and request a cache flush:
resolvectl statussudo resolvectl flush-caches
If the machine uses dnsmasq, nscd, another caching service, or no local DNS cache, follow that service’s documented procedure instead. Do not restart an unrelated daemon. Browser, router, VPN, and remote resolver caches are separate from the cache cleared by these commands.
DNS Propagation vs Website Caching
DNS caching affects which destination a hostname resolves to. Website caching affects the content returned after a connection is made. If the domain already resolves to the intended destination but a page still looks old, the next investigation may belong in the website’s caching layers.
Browser page caching
A browser can reuse HTML, images, scripts, or service-worker content. Compare a fresh browser session or request before concluding that the DNS answer is stale. A hard refresh can help with page assets, but it does not reliably clear every DNS cache.
WordPress and server-side application caching
WordPress page caches, object caches, application caches, and reverse proxies can serve older content at the correct address. Check which environment received the content update and which cache is responsible. Changing DNS again will not purge a WordPress page cache.
CDN and Cloudflare caching
A CDN can serve cached content through edge servers even when origin routing is correct. Cloudflare’s public proxy addresses and its content cache are separate concepts. A content-cache purge does not clear every recursive DNS cache, and flushing local DNS does not purge CDN content.
Compare the resolved destination with the hosting provider’s expected configuration, then compare the actual response or content version. For proxied sites, the public IP may be the CDN rather than the origin; use your provider’s diagnostics to identify the serving environment without exposing or bypassing protected origins.
When Should You Contact Your DNS Provider?
Ask for help when authoritative nameservers are wrong, records are incorrect or inconsistent, or you see persistent NXDOMAIN, SERVFAIL, DNSSEC validation failures, expiration, or delegation problems. These are reasons to investigate configuration rather than simply wait for a generic propagation window.
If email stops arriving after an MX migration, confirm the active MX records, mailbox readiness, and any bounce message with the email provider. Correct DNS does not guarantee mailbox acceptance or recover messages already rejected. The published MX guide explains the next checks.
Provide the hostname, record type, expected and observed values, time of the change, authoritative provider, resolver results, and recent registrar or DNS changes. Do not share passwords, API keys, private keys, or recovery codes in an ordinary support request.
Hostingcone’s published DNS Fixes service is $79 one-time for one domain and includes up to 1 hour of standard DNS troubleshooting and configuration. Additional work requires approval. Review the current service page for included scope and exclusions; it does not include email migration or application-level website repairs.
Frequently Asked Questions
What is DNS propagation?
It is the period during which a DNS change becomes visible through different lookup paths. Recursive resolvers and local caches may continue serving earlier answers until they expire or refresh; updates are not pushed to every DNS server simultaneously.
How long does DNS propagation take?
Some changes appear within minutes, while cached answers can persist for hours. Nameserver changes add delegation and provider-processing considerations. TTLs and resolver behavior matter, so there is no universal completion time.
Can I speed up DNS propagation?
For planned changes, lower relevant TTLs early enough for previously cached answers to expire. Confirm that the authoritative zone is correct. You cannot force every remote resolver to discard an existing cached answer on demand.
Why does my website work on one network but not another?
The networks may use different resolvers or cached answers. VPNs, private DNS, filtering, or connectivity can also affect the result. Compare the exact hostname across resolvers and devices before assuming public DNS is incorrect.
Does flushing DNS speed up propagation?
It may refresh your device’s local cache and help your own test. It does not clear caches at ISPs, public resolvers, routers, or every browser, and it does not accelerate authoritative publication.
Why does Cloudflare show a different IP address?
A proxied Cloudflare hostname normally returns edge addresses instead of the origin IP. CNAME flattening can also change the form of the public answer. Compare proxy and record settings before treating this as stale DNS.
How can I check whether my nameservers have updated?
Review the registrar’s assigned nameservers and compare the parent-zone delegation with public NS results. Cached delegation or zone NS records can differ temporarily. Ask the registrar or DNS provider to confirm discrepancies rather than relying on a single lookup.
Why are my MX records not updating?
An older answer may still be cached, or the edit may have been made in an inactive DNS zone or under the wrong hostname. Check authoritative MX answers, priorities, and all remaining records. Delivery problems can also come from mailbox or provider configuration.
Can a DNS lookup tool check propagation worldwide?
A tool can sample the resolvers or locations it queries, not prove that every resolver worldwide has updated. Hostingcone’s resolver comparison is useful evidence from selected services; it is not a complete global cache inventory.
Still Waiting for Your DNS Changes?
Check your domain's public DNS records with Hostingcone's free tool, or get professional help troubleshooting DNS configuration issues.
Explore Hostingcone domain services
Explore more DNS troubleshooting guides and tools in the Hostingcone DNS Troubleshooting Hub.