How Do You Troubleshoot CDN DNS Propagation Issues?

You troubleshoot CDN DNS propagation issues by proving where the truth lives, then walking outward. 

‍

• First, confirm your authoritative DNS holds the exact record set you intended. 
• Next, make sure the delegation at the registrar points to those name servers. 
• Check TTLs and record types, especially at the apex, and avoid mixing A or AAAA with CNAME. Validate DNSSEC status. 
• Test resolution from multiple recursive resolvers, flush local caches, and compare results with a domain propagation checker. 
• Finally, separate DNS from CDN cache by hitting the resolved IP or bypassing the proxy to confirm that what users see matches what DNS points to. 

‍

Here’s how you should be doing each of the above:

‍

1) Confirm What You Changed And Where

‍

You start by writing down the intended state. 

‍

Which hostname did you point at the CDN, what record type did you use, and where did you make the change: registrar DNS, a managed DNS provider, or the CDN’s own DNS product. 

‍

If I am calculating scope, I note the exact TTL and whether the record is proxied or DNS-only. That single snapshot keeps you honest when results start to look random.

‍

2) Verify Delegation At The Registrar

‍

If your domain’s NS at the registry still points at old name servers, nothing else matters. Look up the NS at the parent zone and match them to the DNS provider that holds your new records. 

‍

Mismatched delegation is like posting a new address in your living room instead of at the post office. If delegation is wrong, fix it at the registrar and expect full visibility to follow the NS TTL, not the record TTL.

‍

Quick checks you can run:

‍

• Query the NS for your zone from the parent.
• Make sure every authoritative server answers consistently.
• If you recently moved DNS providers, confirm the NS change actually completed.

‍

3) Inspect Authoritative Records Directly

‍

Stop asking the internet at large and ask the source. Query the authoritative name servers for the exact FQDN and type you changed.

‍

What to validate:

‍

• The record exists, is the correct type, and matches the CDN’s onboarding instructions.
• No conflicting records exist in the same set. For example, avoid a CNAME coexisting with A or AAAA at the same name.
• If you changed a CNAME target, that target resolves to addresses that the CDN actually uses.

‍

If I smell inconsistency, I query each authoritative server directly and compare answers. They should be identical.

‍

4) Get TTLs Right And Set Expectations

‍

DNS propagation is mostly caching. Your record TTL sets the upper bound on how long old answers linger once resolvers have cached them. A high TTL is great for stability but painful for change windows. If you are mid-migration, temporarily reduce TTL a day before the cut. 

‍

If you did not do that, accept the math. A 3600 second TTL means some users may keep the old answer for up to an hour, and a 86400 second TTL can drag for a full day. Your users’ resolvers do not care that you are in a hurry.

‍

Also check negative caching. If the name was recently NXDOMAIN, resolvers may cache that miss per the zone SOA’s minimum TTL. That hides a newly added record until the negative cache expires.

‍

5) Handle Apex Records Correctly

‍

Most CDNs prefer you point your subdomain to a CNAME that they control. That is straightforward for www.example.com. 

‍

The apex example.com is different because a pure CNAME at the zone apex is not allowed. Your options:

‍

• Use ALIAS or ANAME if your DNS provider supports it.
• Use CNAME flattening if your provider offers it.
• If you must use A and AAAA records, use the CDN-provided Anycast addresses and keep their TTLs reasonable.

‍

If you accidentally published a literal CNAME at the apex, some resolvers will reject it, and you will see bizarre partial reachability. That feels like a ghost in the machine, but it is just the standard doing its job.

‍

6) Check CDN Proxy Mode, Origin Reachability, And Certificate

‍

You may have toggled a “proxy on” feature that hides your origin behind the CDN. Test both modes:

‍

• DNS-only test: resolve the hostname and connect directly to the returned IP so you know the address is right.
• Proxy test: ensure the CDN returns the expected content and headers.

‍

Watch for IPv6 surprises. If your DNS publishes AAAA and your CDN or origin is not actually listening on v6, users on v6-preferred networks will fail while v4 users succeed. 

‍

If I suspect this, I query A and AAAA separately and test both paths.

‍

Also make sure the CDN issued or uploaded the right TLS certificate for the host. A DNS fix does not help if browsers refuse the connection due to certificate mismatch.

‍

7) Validate DNSSEC Status

‍

DNSSEC is great when configured correctly and brutal when it is not. 

‍

A stale DS record at the registrar or a missing RRSIG in your zone causes resolvers that validate DNSSEC to treat your domain as bogus. 

‍

That looks like random availability because some networks validate and others do not.

‍

Your choices:

‍

• Ensure the DS at the registrar matches the DNS provider’s current key.
• If you disable DNSSEC, remove the DS at the registrar so validators stop expecting signatures.

‍

I keep DNSSEC changes high on the list because they create binary success or failure instead of simple delay.

‍

8) Compare Multiple Recursive Resolvers

‍

Now that the authoritative side is clean, you measure propagation in the wild. Query a few well-known resolvers and your ISP’s resolver. 

‍

If the answers differ only by recency and TTL countdown, you are witnessing normal DNS propagation. If they differ in content, go back to delegation or authoritative checks.

‍

You can also route around a sticky resolver by specifying a different one on your test machine, which isolates caching from correctness.

‍

9) Flush Local And Browser Caches

‍

Local caching hides progress. Clear it so your tests reflect the network, not your laptop.

‍

• Windows: ipconfig /flushdns
• macOS: sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder
• systemd-resolved: resolvectl flush-caches

‍

Browsers and some apps cache DNS and HTTP aggressively. 

‍

Close the browser, or open a private window, or append a cache-busting query like ?v=timestamp when hitting the CDN to separate DNS changes from stale HTTP objects.

‍

10) Separate DNS From CDN Caching

‍

DNS tells users which CDN edge to ask. The CDN decides what content to serve. When users claim they still see the old site, decide if that is a DNS issue or a CDN cache issue.

‍

• If resolution returns the new CDN address but the content is old, purge the CDN cache for that host or path.
• If some edges serve new content and others old, your purge did not reach the entire network or you are hitting different hostnames through redirects.

‍

I like to fetch the resolved IP directly with curl and set the Host header to the hostname. That proves whether the edge serving that IP has the right content, independent of DNS repetition.

‍