A DNS propagation checker queries a domain against resolvers spread across multiple regions and compares the answers - the point is not speed, it is whether every resolver agrees yet.
Why the same domain answers differently depending on where you ask
DNS has no central live database that every server reads from in real time. Each authoritative nameserver holds the current records, but recursive resolvers around the world - the ones ISPs and public services like Cloudflare or Google run - only refetch those records when their cached copy expires. Until that happens, a resolver keeps serving whatever it cached, even if the authoritative answer changed an hour ago.
That cache lifetime is the TTL (Time To Live) set on each DNS record, expressed in seconds. A record with a 3600 TTL can be cached by any resolver that queried it for up to one hour before that resolver is required to ask again. Two resolvers that queried the domain at different times will hold the same record but expire it at different moments - which is why a propagation check run five minutes after a DNS change routinely shows some servers already returning the new value and others still returning the old one.
This is not a bug in DNS and it is not a sign that "propagation" is stuck. It is the caching model working as designed. RFC 1035 defines TTL as advisory to any caching resolver, and RFC 2181 clarifies that TTL applies to the record, not to a particular response - every resolver independently decides when its copy has aged out.
- A resolver never asks again before its cached TTL expires, no matter how urgent the change feels on your side
- Lower TTL values before a planned change shorten the worst-case wait, but they must be lowered in advance - changing TTL at the same time as the record does nothing for that first change
- Recursive resolvers, not authoritative servers, are what "propagation" actually measures - the authoritative side updates immediately
- A record with no prior TTL change can take up to its full TTL value to be consistent everywhere, and stale local resolvers or ISP-level caching can occasionally hold on longer than the TTL suggests
Reading a propagation check
Each row in the results represents one public resolver queried directly, grouped by region - expect entries from providers like Cloudflare (1.1.1.1), Google (8.8.8.8), Quad9, and regional operators across North America, Europe, and Asia. A server can come back in one of three states: it returned records successfully, it returned an error (refused, format error, server failure), or it timed out without answering at all. A timeout does not mean the record is missing - it usually means that specific resolver was unreachable or slow to respond during the check, and a retry a moment later often succeeds.
The summary at the top reports a percentage of resolvers that returned a successful answer, alongside how many were consistent with each other. Consistency matters more than the percentage on its own: 100% of resolvers answering, but split across two different record sets, means the change has not fully propagated even though every server technically responded. The results group answers into result sets - resolvers reporting an identical record set are bucketed together, so a domain mid-propagation typically shows one bucket with the old value and one with the new value, alongside a count of which resolvers hold which.
A domain with no records at all for the queried type (an empty A lookup on a domain that only has AAAA, for instance) shows up as a distinct "no records" group rather than an error - that is a legitimate, consistent answer if every resolver agrees on it.
| Field | What it tells you |
|---|---|
| Propagation percentage | Share of queried resolvers that returned an answer at all (success vs. error/timeout) - not agreement |
| Consistent | Whether every successful resolver returned the identical record set |
| Unique results | How many distinct record sets are in circulation - 1 means fully propagated, 2+ means resolvers disagree |
| Result set grouping | Resolvers sharing an identical answer, bucketed together with a server list per bucket |
| Response time per server | Round-trip time for that individual query - a proxy for that resolver's distance or load, not for propagation status |
What actually controls how long a rollout takes
The TTL on the record being changed is the ceiling, not the average. If the previous TTL was 86400 (24 hours), a resolver that cached the old record 23 hours before the change will hold it for another hour regardless of when the check is run. If that same resolver had queried the domain one minute before the change, it will refetch almost immediately. This is why propagation checks against a freshly changed record often show a wide spread of results in the first few hours and then converge - resolvers are expiring their individual caches on independent schedules, not on a synchronized timer.
Changing the TTL itself only helps the next change. Lowering a TTL from 86400 to 300 seconds takes effect once resolvers have re-cached the record with the new, lower value - which itself is gated by the old TTL. The standard practice is to lower the TTL well ahead of a planned cutover (a day or more, depending on the old TTL), wait for that lower value to take hold everywhere, make the actual record change, then raise the TTL back once the rollout is confirmed stable.
Registrar-level changes - switching nameservers at the registrar rather than editing a record at the DNS provider - follow a separate, slower path: the parent zone also caches the NS delegation, and that delegation's TTL is set by the registry, not by whoever runs the DNS. Waiting is the only lever here, since the controlling TTL sits outside the zone being changed.
FAQ
How long does DNS propagation normally take?
It depends entirely on the TTL of the record being changed, not on a fixed industry figure. A record with a 300-second TTL is fully consistent almost everywhere within minutes once every resolver that had it cached has expired that cache. A record with a 24-hour TTL can take the better part of a day, since a resolver that cached the old value just before the change waits out its full cache window before refetching.
Why do some resolvers time out instead of returning an answer?
A timeout in a propagation check usually reflects that specific resolver being briefly unreachable or overloaded at query time, not that the domain has a problem. Public resolvers occasionally rate-limit or drop queries from automated checking tools. A timeout on one resolver with every other resolver responding normally is not evidence of a DNS misconfiguration.
If every resolver shows a different record, is that always a problem?
Not necessarily - it depends on timing. Immediately after a DNS change, a split between the old and new record across different resolvers is expected and temporary; it resolves once each resolver's cached TTL expires. If the same split persists well past the TTL that was set on the record, that points to an actual issue - a resolver caching longer than instructed, or the authoritative nameservers themselves disagreeing.
Does lowering the TTL make an in-progress propagation finish faster?
No. A TTL change only affects how long resolvers cache the record going forward, and that new TTL only reaches a resolver once it refetches - which is gated by the TTL that was already cached. To speed up a future change, lower the TTL well before making it, not during or after.
Can a domain be "stuck" in propagation indefinitely?
Beyond the record's TTL window, a persistent split usually traces to one of a few causes: a resolver or ISP-level cache ignoring the TTL and holding records too long, the authoritative nameservers themselves returning inconsistent answers, or a registrar-level nameserver delegation change gated by the parent zone's own TTL.
Does checking from more resolvers give a more accurate picture than checking from one?
Yes, because any single resolver only reflects its own cache state at that moment. Querying a spread of resolvers across regions and providers reveals whether propagation is actually in progress (a mix of old and new answers, resolving over time) versus stalled (the same split persisting long after the TTL has elapsed) - information a single lookup cannot distinguish.
Related tools
- Run a direct record lookup against a single resolver when you need the current answer, not a global comparison
- Run a full DNS health audit once propagation has settled, covering delegation and configuration issues beyond record consistency
- Check which nameservers are currently delegated for a domain - the layer that sits above individual record propagation
- Look up registrar and registration details when a propagation delay traces back to a recent nameserver or registrar change