Cloudflare DNS not propagating? Check authority, proxying, and cache

When Cloudflare DNS appears not to propagate, first check whether Cloudflare is authoritative for the name, whether the record is proxied, and what the authoritative server actually returns. Waiting is useful for a cached old answer. It does not fix an edit made in the wrong zone or a broken DNSSEC chain.

Write down the exact hostname, record type, expected value, time of change, and observed result. “The website still looks old” is a symptom; it does not yet tell you whether DNS, caching, or the application is responsible.

1. Check who is authoritative

For the common full-zone setup, the registrar must delegate the domain to the Cloudflare nameservers assigned to that zone. Compare the actual delegation with the dashboard. A zone present in your account is not necessarily the zone answering public queries.

dig example.com NS +short
dig example.com +trace

These are read-only example queries. If only a subdomain fails, inspect whether it has its own NS delegation. The authoritative records may live in a separate child zone, as explained in our subdomain delegation guide.

2. Account for the proxy

A proxied record normally answers with Cloudflare addresses rather than the origin address entered in your dashboard. Cloudflare’s proxy-status documentation explains this distinction. Seeing a Cloudflare IP is therefore not evidence that your origin change was ignored.

Confirm what you expected to observe. If the record is intended to serve a proxied website, inspect the site’s actual response and origin configuration. If it is a verification record or non-web service, check the provider’s instructions for whether it should be DNS-only. Do not toggle proxying across the whole zone as a guessing exercise.

3. Compare authoritative and recursive answers

A recursive resolver can still hold an earlier answer after the authoritative server has changed. Query both and compare the value and TTL. Substitute one of your assigned authoritative server names below:

dig @your-assigned-nameserver.example example.com A
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A
dig example.com AAAA

Check IPv6 as well as IPv4. A stale AAAA record can send some visitors to a different server even when the A record is right. Check the root name and www separately rather than treating them as interchangeable.

Cloudflare’s TTL guide describes caching and the default five-minute Auto TTL for proxied records. Local caches can last longer. Lowering the TTL now does not retroactively shorten a value a resolver already cached under the previous TTL.

4. Investigate SERVFAIL as a validation problem

If queries return SERVFAIL, check DNSSEC as well as server reachability. A common migration problem is a parent DS record that still refers to the old DNS provider’s signing keys. Cloudflare’s DNSSEC troubleshooting guide explains this failure and the use of a checking-disabled query to help diagnose it.

Use that comparison as evidence, not a permanent workaround that disables validation for visitors. Coordinate the correct DS and signing configuration with the registrar and DNS provider. Do not delete unrelated records because a resolver reports a validation failure.

5. Separate DNS from cached website content

Keep the previous working values and change one relevant setting at a time. If support needs to investigate, provide the queried hostname, resolver, record type, output, and timestamp. That evidence is much more useful than another screenshot saying that propagation has not finished.