DNS propagation checker

Nothing propagates

The word is a misnomer, and believing it is why people wait for the wrong thing. Your change does not travel outward from your registrar, spreading across the world server by server. The authoritative name servers for your zone were updated the instant you saved the record, and from that moment they have been giving the new answer to everyone who asks.

What varies is who is still asking. Between you and those authoritative servers sit thousands of recursive resolvers: your ISP's, your company's, Cloudflare's, Google's, and each one keeps a copy of the last answer it received for as long as the record's TTL allowed. A resolver that fetched your record ten seconds before you changed it is contractually entitled to keep serving the old value for the full TTL, and it has no idea anything happened. It will not find out until its copy expires and it goes back to ask again.

So "has it propagated yet" is really "has that particular resolver's cache expired yet". That reframing is worth having, because it tells you the two things you actually need to know: how long the wait can be, and that there is nothing to do but wait.

Read the TTL, not just the answer

Every answer above carries a TTL in seconds, and it is a countdown rather than a setting. It is what remains of the time that resolver is allowed to keep this copy: not the TTL configured on your record, but what is left of it.

A low remaining TTL means that resolver is about to discard its copy and ask the authoritative servers again, so if it is wrong it is nearly done being wrong. A high one means it cached recently and will be serving that answer for a while. When the two resolvers disagree, the larger of the two TTLs is your worst case: after that many seconds, the stale one has to go and ask again, and it will get the new answer.

There is a corollary worth knowing before your next change. The TTL that governs the wait is the one that was in effect when the resolver cached, not the one you set afterwards. Lowering a TTL to 60 seconds five minutes before a migration does nothing for any resolver that cached an hour ago at the old value. Lower it a day ahead, make the change, then put it back.

How long does DNS propagation take?

As long as the largest TTL involved, and no longer. There is no fixed figure and no queue to wait in: the honest answer is the number in the TTL column above. A record with a 300-second TTL is fully consistent within five minutes of the last resolver that cached it. One with a 24-hour TTL can take a day, and will, for whichever resolver cached it first.

The "24 to 48 hours" figure repeated everywhere comes from two specific cases, not DNS records in general. Changing the name servers at your registrar means waiting on the parent zone's NS TTL, which is commonly 48 hours and is not yours to set. And some resolvers quietly cap very long TTLs, or serve a stale answer when the authoritative servers are unreachable. For an ordinary A or CNAME change on a sane TTL, minutes is normal.

Check DNS propagation against the live records: the TTLs above tell you what the wait actually is for your record, today.

When the resolvers disagree

This is the ordinary, expected state for the first minutes or hours after a change, and it is not a fault. One resolver has a cached copy from before your edit. Nothing you can do reaches inside somebody else's resolver and removes it: not editing the record again, not flushing your own cache, not clearing your browser. The record is already correct at the source: the only variable left is time.

Editing the record again is the common mistake, and it makes things worse. Resolvers that have already picked up the new value now have to expire it before they see the newer one.

A disagreement that persists well past the TTL is a different matter, and usually means something is interfering: a filtering service, a captive network, or a split-horizon setup answering differently inside than out.

When they agree and it is still wrong for you

If both resolvers here return the new value and your own machine does not, the stale copy is close to home: your operating system's cache, your browser's, or a resolver inside your own network. That one you can do something about, and it is the only case where flushing helps.

• The flush DNS command, for every platform, and what it does and does not clear.
• ipconfig /flushdns on Windows.
• Clearing the DNS cache on a Mac, where the command has changed several times.

The order matters: check here first. Flushing a local cache when the public resolvers still hold the old answer achieves nothing except making you refetch it.

Two resolvers, and what that honestly gets you

This page queries Cloudflare (1.1.1.1) and Google (8.8.8.8). They are genuinely independent of each other: separate companies, separate anycast networks, separate caches, so when they agree, the change has taken effect in the two largest public resolvers on the internet, and when they disagree you have caught a cache mid-expiry. That is a real comparison, and it answers the question for most domains most of the time.

It is not a map of twenty flags. This page cannot tell you what a particular office in Frankfurt is seeing. A map cannot do that either; those tools query resolvers in various places, not the machine on the desk of the person complaining. We would rather show you two answers and explain what they mean than show you twenty and let you infer coverage that nobody has.

Two resolvers are enough for this check. The whole check runs in your browser over DNS-over-HTTPS, and a browser can only talk to endpoints that permit cross-origin requests. Cloudflare and Google both do. Most public resolvers do not. The alternative, a server of ours making the queries for you, would measure our caches. That would answer a different, less useful question.

"No such name" is not "no record of that type"

Two results look similar and mean entirely different things. NXDOMAIN means the name does not exist at all: nothing in the zone answers to it. An empty NOERROR means the name exists and the zone answered, but has no record of the type you asked for: a domain with no IPv6 returns exactly that for AAAA, and it is not a fault.

Both are cached, which surprises people. A resolver that was told "this name does not exist" holds that negative answer for a period the zone sets in its SOA record. Create a record and ask immediately, and you may be told it does not exist by a resolver that is simply repeating what it learned a minute ago. The page shows how long that negative answer has left when it can.

Which record types matter when

• A and AAAA: where the name points. The usual thing being waited on after a move.
• CNAME: an alias. Check the target as well; a stale answer can be at either end of the chain.
• MX: where mail is delivered. Worth more care than the rest: a stale MX does not fail visibly, it delivers mail to the old server, where it sits read by nobody.
• NS: the zone's name servers. These are cached by the parent zone's TTL, frequently 48 hours, which is why a registrar change takes so much longer than a record change.
• TXT: SPF, DKIM, DMARC and verification records. If a provider says it cannot see the verification record you added, check here before adding it a second time.

For a single answer with the record's meaning explained, use the DNS lookup. For mail records specifically, the SPF, DKIM and DMARC checker reads them and says what is wrong with them.

Nothing is sent to us

The queries go from your browser straight to the resolvers over DNS-over-HTTPS. The domain you type never reaches a Kodura server, because there is no server involved, which also means this page cannot be used as somebody else's lookup proxy.