Troubleshooting Guides

Troubleshooting DNS Propagation Problems

Troubleshoot DNS propagation, TTL, resolver cache, authoritative nameservers, local cache and records changed at the wrong provider.

By CheckDomainHealth Editorial Team Reviewed by Dionis Ceban Updated Jun 28, 2026 9 min read Beginner

Introduction

DNS propagation problems happen when a DNS change has been made, but some resolvers, devices or regions still return the old answer. This is common after migrations, nameserver changes, CDN setup, email provider switches or TTL adjustments.

Propagation is not one global switch. Each resolver caches DNS answers based on TTL and its own behavior. To troubleshoot effectively, compare authoritative DNS with public resolver results, confirm you edited the correct DNS provider, and separate DNS issues from CDN or browser cache confusion.

Quick answer

Quick answer

If DNS changes are not visible everywhere, check authoritative nameservers first, then compare results from multiple public resolvers. Review TTL, confirm the record was saved in the active DNS provider, wait for old TTL to expire, and rule out CDN or local device cache before assuming propagation failed.

DNS propagation problems

DNS propagation means different resolvers may temporarily return different answers after a change. The authoritative nameserver holds the current intended value, while cached resolvers may still serve the previous record until TTL expires.

Authoritative DNS

The nameservers listed in the domain NS records. This is the source of truth for the zone.

Resolver cache

ISP, public, corporate or device DNS caches that store answers for the TTL period.

TTL

Time To Live. Tells resolvers how long they may keep a cached answer.

CDN confusion

Users may see old content or a CDN target even when authoritative DNS already changed.

A healthy troubleshooting flow is: authoritative answer → public resolver answer → local device cache → CDN/browser cache.

Why this matters

Why this matters

DNS propagation problems matter because they can make a correct change look broken. Website traffic may split between old and new servers, email may route incorrectly, SSL validation can fail, and support tickets may report “it works for me” while others still see the old destination.

Misdiagnosing propagation can lead to duplicate edits, unnecessary nameserver changes or rollback of a working migration. Checking authoritative DNS first saves time and reduces risk.

How to check

Use DNS Lookup and command-line checks to compare authoritative answers with resolver results.

  1. Authoritative nameservers — Confirm which NS records are delegated for the domain.
  2. Authoritative answer — Query the active nameserver directly for the record you changed.
  3. Public resolvers — Compare answers from 8.8.8.8, 1.1.1.1 or other resolvers.
  4. TTL value — Check whether the old TTL is still being served.
  5. Record type — Verify A, AAAA, CNAME, MX or TXT in the correct zone.
  6. CDN target — Confirm whether the domain should point to a CDN hostname or origin IP.
  7. Local cache — Test from another network or device if only one location looks wrong.

Check current DNS records

Use DNS Lookup to compare authoritative answers with what resolvers return for your domain.

Run DNS Lookup →

Common problems

Old TTL still cached

Medium

Resolvers are still serving the previous record until the old TTL expires.

Next step: Wait at least one full old TTL period and re-check from multiple resolvers.

Edited DNS in the wrong provider

High

Records were changed at the registrar or old host, but the domain uses different authoritative nameservers.

Next step: Check NS records and edit DNS where the zone is actually hosted.

Nameserver change not complete

High

Some resolvers still query old nameservers after an NS update.

Next step: Verify NS delegation at the registrar and confirm the new zone is complete.

Authoritative zone missing records

High

The new DNS provider does not contain all records from the old zone.

Next step: Export the old zone and recreate missing A, MX, TXT and CNAME records before switching.

CDN CNAME still points to old target

Medium

DNS now points to the CDN, but the CDN origin or proxy settings still reference the old server.

Next step: Check CDN dashboard origin settings separately from public DNS.

Root and www updated inconsistently

Medium

example.com and www.example.com resolve to different destinations during migration.

Next step: Align root and www records with the intended canonical setup.

Local device cache only

Low

Authoritative and public resolvers show the new value, but one laptop or office network does not.

Next step: Flush local DNS cache or test from another network.

Split answers across regions

Medium

Some resolvers refresh faster than others, creating temporary regional differences.

Next step: Compare multiple resolvers and wait for TTL expiry rather than making duplicate edits.

Confusing CDN edge with DNS propagation

Medium

DNS is correct, but cached CDN content or SSL mode makes the site appear unchanged.

Next step: Purge CDN cache and verify edge SSL separately from DNS records.

SOA serial or zone not published

High

The DNS provider saved the record locally but did not publish the zone correctly.

Next step: Re-save the record, confirm zone status in the DNS panel and query authoritative NS directly.

How to fix propagation issues

  1. Step 1: Confirm authoritative nameservers

    Check NS records and identify where the live DNS zone is managed.

  2. Step 2: Query authoritative DNS directly

    Use dig @nameserver to confirm the intended record exists at the source.

  3. Step 3: Compare public resolver results

    Test 8.8.8.8, 1.1.1.1 and other resolvers to see whether caching is involved.

  4. Step 4: Review TTL and timing

    Note the current TTL and wait for the previous value to expire if needed.

  5. Step 5: Fix the record in the correct provider

    Edit DNS only where the authoritative zone is hosted.

  6. Step 6: Verify related records

    Check root, www, mail, verification TXT and CDN CNAME records together.

  7. Step 7: Separate CDN and browser cache

    Purge CDN cache and test from a clean network if DNS is already correct.

  8. Step 8: Re-test after TTL expiry

    Confirm the new answer is visible from authoritative and public resolvers.

Examples

Check authoritative nameservers 
dig example.com NS +short

Expected:
ns1.example-dns.net.
ns2.example-dns.net.
Query authoritative DNS directly 
dig @ns1.example-dns.net example.com A +noall +answer

dig @ns1.example-dns.net www.example.com CNAME +noall +answer
Compare public resolvers 
dig @8.8.8.8 example.com A +noall +answer
dig @1.1.1.1 example.com A +noall +answer
dig @9.9.9.9 example.com A +noall +answer
Trace delegation and TTL 
dig +trace example.com A

dig example.com A +noall +answer +ttlid
Example propagation scenario 
Authoritative NS:
example.com A → 192.0.2.20 TTL 300

Public resolver 8.8.8.8:
example.com A → 192.0.2.10 TTL 842

Likely cause:
Old A record still cached.

Fix:
Wait for old TTL to expire.
Do not edit DNS again unless authoritative NS is wrong.

Commands are examples. Replace example.com and nameserver hostnames with your real domain and DNS provider values.

Frequently asked questions

How long does DNS propagation take?

It depends on TTL, resolver cache and whether nameservers changed. Many updates appear within minutes to a few hours, but old values can linger until TTL expires.

Why do different locations see different DNS results?

Resolvers cache answers independently. Some may still hold the old record until TTL expires or the cache is flushed.

Does lowering TTL guarantee instant propagation?

No. Lower TTL helps resolvers refresh sooner, but it does not force every resolver to update immediately.

Can a CDN make DNS look wrong?

A CDN can change what users see at the edge, but authoritative DNS still controls where the domain points. Check both DNS and CDN settings.

Why does authoritative DNS show the new record but my laptop does not?

Your device or local resolver may still have the old answer cached.

Should I flush DNS cache on every device?

That can help for local testing, but the real fix is waiting for TTL expiry or correcting the authoritative DNS record.

When should I contact my DNS provider?

If authoritative nameservers show the wrong zone, records were edited in the wrong panel, or nameserver delegation is incorrect.

Use these free tools to verify your configuration after applying changes.

DNS Lookup Domain Health Checker MX Lookup SSL Checker
Understanding TTL: DNS Cache and Propagation Times 8 min read Changing Nameservers: Step-by-Step Guide 9 min read Nameserver Basics: How to Delegate Your Zone 8 min read Understanding DNS: How Domain Names Connect to Websites and Email 8 min read "Domain Not Found" DNS Errors: Causes and Fixes 8 min read
Browse all Troubleshooting guides →

Need help applying this fix?

Send us your domain, report link or issue details. CheckDomainHealth will review the request and route it to the right technical team if hands-on support is needed.

Get Help Run Domain Health Check

Was this guide helpful?

Your feedback helps us improve our guides for everyone.