About the DNS Propagation Checker
The day you migrate a site, change mail hosts, or add a verification record, one question dominates: has it gone live yet — and for whom? This tool answers it the way an engineer would: by querying the same record simultaneously across five major public resolvers (Google, Cloudflare, Quad9, OpenDNS, AdGuard) and your domain's own authoritative nameserver, then diffing the six answers.
The authoritative query — sent with recursion disabled, straight to the server your NS records delegate to — is the piece most “propagation checker” sites skip, and it matters most: it is the value the rest of the internet will converge on. If it still shows your old record, the change never saved and waiting is pointless. Each cached answer also shows its TTL counting down live, so you can see exactly when a stale resolver must re-fetch.
Queries run from our server at your request; nothing about your domains is stored beyond a 60-second result cache. This complements our single-resolver DNS Lookup, which inventories every record type for a domain in one place.
TTLs count down live — a stale resolver must re-fetch your record when its TTL reaches zero.
How to Use the DNS Propagation Checker
Enter the exact hostname you changed — example.com and www.example.com
are different records — pick the record type, and hit Check. Six queries fire in parallel: five
to the big public resolvers most of the world uses, one straight to your domain’s
authoritative nameserver with recursion disabled. The hero percentage counts how
many public resolvers already serve the authoritative answer; the table diffs every response and
counts each cached record’s TTL down in real time.
Propagation Is Just Cache Expiry — Nothing Is “Spreading”
DNS changes don’t push out to the internet; they wait to be pulled. Every resolver that ever answered a query for your record holds it in cache for the record’s TTL (time to live) and will not ask again until that timer expires. “Propagation” is simply the world’s caches expiring at different moments. That has a liberating implication: the old “wait 24–48 hours” advice only applies to records that had a day-long TTL when you changed them. A record with TTL 300 is fully live everywhere within minutes — which is why the pre-migration TTL drop (below) is the single highest-leverage DNS habit you can build.
The Authoritative Row Is the One That Decides Everything
Public resolvers can only ever converge on what your authoritative nameserver says. Read the authoritative row first, and interpret the grid from there: if it shows the new value, every disagreeing resolver is just a cache on a countdown — your change is done, physics is finishing the job. If it shows the old value, stop watching the percentages: the edit didn’t save, you edited the wrong zone (staging vs production, or a registrar zone that isn’t actually delegated), or a secondary nameserver is serving a stale copy of the zone. That last case is worth knowing: multi-server setups sync via zone transfers, and a broken transfer leaves secondaries answering with an old serial indefinitely.
The TTL-Drop Migration Playbook
- T minus 1 day (or one old-TTL period): lower the record’s TTL to 300 seconds. The old, long-TTL copies need time to age out before the low TTL takes effect.
- T zero: make the actual change at your DNS host. Verify the authoritative row shows the new value immediately.
- T plus 10 minutes: re-check here — with a 300s TTL you should see full propagation. Anything stale resolves itself within one more TTL cycle.
- T plus 1 day: raise the TTL back to 3600 or 86400 to cut resolver load and add caching resilience.
Nameserver (NS) changes at the registrar are the exception: they live in the parent zone (the TLD registry), whose TTLs commonly run 24–48 hours and are outside your control. For those migrations, run the old and new nameservers with identical zones in parallel until the parent TTL fully expires.
Reading Disagreements: Normal, Suspicious, and Broken
Normal: resolvers split between old and new values mid-migration, each with a ticking TTL. Suspicious: one resolver returns NXDOMAIN while others answer — usually negative caching from a query made before the record existed; it expires like any cache entry. Broken: resolvers still serving the old value with fresh, full TTLs long after the authoritative changed — they are re-fetching and still getting the old answer, which points at a stale secondary nameserver or a second authoritative provider still configured at the registrar. The pattern of the grid tells you which case you’re in within one glance — that’s the point of checking six sources instead of one.
Auditing the whole zone rather than one record? Run the DNS Lookup for a full inventory, or check your mail records end-to-end with the Email Deliverability Analyzer. Browse all Dev & Tech tools for more.
Frequently Asked Questions
How long does DNS propagation actually take?
It is not a fixed 24 to 48 hours — that number is folklore. Resolvers cache your old record only until its TTL expires, so a record with a 300-second TTL propagates nearly everywhere within minutes of the change. What takes longer: records whose TTL was high (86400 = a day) before the change, negative caching of previously missing records, and registrar-level nameserver changes, which involve the TLD registry and parent-zone TTLs of up to 48 hours.
Why do different DNS resolvers give different answers?
Each resolver caches independently: Google may have fetched your record five minutes ago while Quad9 cached the old value an hour ago and will hold it until TTL expiry. Big anycast resolvers also run many independent cache nodes, so even the same resolver can answer differently by region. Disagreement between resolvers during a migration is normal — it is literally what propagation is.
What is the authoritative nameserver and why does this tool query it?
The authoritative server is the one your domain's NS records delegate to — the source of truth every resolver eventually copies. Querying it directly, with recursion disabled, shows what the world WILL converge on. If the authoritative answer is still the old value, your change didn't save at the DNS host, and no amount of waiting will propagate it.
What should I set my TTL to before a migration?
Drop the TTL to 300 seconds (5 minutes) at least one old-TTL period before the change — if the record had a 24-hour TTL, that means a day in advance. Make the change, verify propagation, then raise the TTL back to 3600 or higher to reduce query load. This one habit turns a two-day cutover into a five-minute one.
A resolver still shows my old IP hours later — is something broken?
Check the TTL countdown on that resolver's row: if it is still counting down, the resolver is honoring the old record's remaining cache time, which is correct behavior. If it re-fetches after expiry and STILL returns the old value, check the authoritative row — the change may not have saved, or a secondary nameserver may be serving a stale zone (compare serial numbers at your DNS host).
