Why Isn’t My Cloudflare DNS Change Working Yet?

“DNS propagation” describes something that does not happen. No record is pushed out to the world’s resolvers. Authoritative nameservers hold the current answer and wait to be asked; every other machine in the chain keeps a copy for as long as it was told to. So the delay you are sitting through is never Cloudflare publishing the change — Cloudflare’s own documentation puts that at within five minutes, usually much less. It is a cache expiring, and which cache decides what you should do about it.

Four places the old answer can be sitting

A lookup walks down this stack and stops at the first layer that already has an answer. Restarting your browser fixes exactly one of these layers. Waiting fixes another. The bottom two are not caches at all and never fix themselves — a delegation that points at the wrong nameservers will still be wrong tomorrow.

Start by asking the authoritative nameserver

Before diagnosing anything, find out what Cloudflare is actually publishing. Querying a Cloudflare nameserver directly skips every cache above it:

dig @1.1.1.1 example.com NS +short
dig @hera.ns.cloudflare.com www.example.com A

Use whichever nameserver names the first command returns for your zone. The answer splits the problem cleanly in two:

• The new value is there. Cloudflare has done its part. The remaining wait is a cache above it, and the sections below cover which one.
• The new value is not there, or the query fails. The record was not saved as you think it was, the hostname does not match exactly, or your zone is not delegated to these nameservers at all. Skip to the delegation section.

Case one: the TTL has not run out

A resolver holding the previous record keeps it for the TTL it was handed at the time it cached it. That is the single most misunderstood point here: editing the TTL now has no effect on a copy that is already cached. The values Cloudflare allows:

Two consequences worth internalising. First, proxied records are pinned to five minutes precisely so Cloudflare can move its anycast addresses without stranding anyone — which means an orange-clouded hostname can never be more than five minutes stale. Second, the nameserver TTL is a separate 24-hour figure, so a zone that has just moved to Cloudflare can look inconsistent for a full day even when every record is correct.

Case two: the resolver cached “this does not exist”

This is the failure that sends people in circles. You add a brand-new subdomain, it returns NXDOMAIN, you lower the TTL, you flush your cache, you wait — and nothing changes.

The reason is negative caching. When a resolver is asked for a hostname that has no records, it caches the absence, so it does not have to ask again immediately. If anything queried your hostname before you created it — a monitoring check, a certificate probe, your own impatient browser — that empty answer is now stored. Per RFC 2308, its lifetime comes from the MINIMUM field of your zone’s SOA record, and Cloudflare’s troubleshooting guidance spells out what follows from that:

• Lowering the new record’s TTL changes nothing, because the entry being served is not your record.
• Flushing locally changes nothing, because the entry lives in the resolver upstream of you.
• Different resolvers queried the name at different moments and apply different limits, which is exactly why the result looks like it is “propagating” unevenly.

You can watch the countdown rather than guess at it:

dig +noall +answer +authority newhost.example.com

If the answer section is empty and the authority section returns your SOA, the number beside it is how many seconds remain before that resolver will ask again. To stop waiting on the two big public resolvers, purge the name directly at 1.1.1.1 and 8.8.8.8. The habit that prevents all of this: create the record first, and only then point anything at the hostname.

Case three: the zone is not really delegated to Cloudflare

If the authoritative query in the first step came back empty or failed, no amount of waiting will help. Check what the parent zone publishes, rather than what your registrar’s control panel claims:

dig +trace example.com NS +noall +authority +nodnssec

The usual causes, all of them things you have to go and fix:

1. The nameservers do not match exactly. Each zone is assigned a specific pair, and re-adding a deleted domain gets a fresh pair. A previously working set may no longer be the right one, and typos like cloudfare.com are common enough that Cloudflare calls them out by name.
2. Extra nameservers are still listed. The registrar should list the Cloudflare nameservers and nothing else.
3. A stale DS record is still published. DNSSEC from your previous provider blocks the delegation and produces SERVFAIL until the old DS record is removed and its TTL at the parent has expired — commonly 24 to 48 hours for most top-level domains.
4. The registrar has not published the change yet. Some take up to 24 hours. This one really is a wait — but confirm it with dig +trace rather than assuming.

A zone sitting in Pending Nameserver Update is Cloudflare telling you it cannot see the delegation either; the zone status reference explains what each state means, including the Moved state that eventually deletes the zone.

When DNS is correct and the site is still wrong

One case looks like a DNS delay and is not one at all. A proxied recordis answered with Cloudflare anycast addresses, never with your server’s address — so if you change the origin IP behind a proxied hostname, the DNS answer does not change. There is nothing for a resolver to re-fetch, and dig cannot confirm the change either way. The new origin takes effect at the edge within the same few minutes Cloudflare needs to publish it.

Toggling proxy status is the opposite case, and it is asymmetric. Turning the proxy off replaces a record whose TTL was pinned at 300 seconds, so it settles in about five minutes. Turning it on has to wait out the DNS-only TTL that was in force before — which, if someone set it to a day, means a day of visitors still reaching your origin directly. Lower that TTL first, then flip the switch. The proxy status reference covers what else changes with it.

Making the next change painless

1. Lower the TTL on the records you are about to change to 60 or 300 seconds, and do it at least one old-TTL period in advance.
2. Wait out the old TTL. Until it expires, resolvers are still handing out the long one.
3. Make the change, then verify against an authoritative nameserver before testing anywhere else.
4. Create records before anything queries their hostnames, so no negative cache entry is ever created.
5. Once the change is stable, raise the TTL back up — long TTLs are good for everyone the rest of the time.

None of this needs a fourth tool: dig, the record itself, and knowing which of the four layers you are talking to will resolve nearly every “my DNS change is not working” report.

FAQ