DNS Checker
| Location / DNS Server | Value | Response Time |
|---|---|---|
San Francisco, United States Cloudflare (1.1.1.1) | — | — |
Mountain View, United States Google Public DNS (8.8.8.8) | — | — |
San Jose, United States OpenDNS (Cisco) (208.67.222.222) | — | — |
Los Angeles, United States CleanBrowsing (185.228.168.9) | — | — |
Reston, United States Verisign Public DNS (64.6.64.6) | — | — |
Zurich, Switzerland Quad9 (9.9.9.9) | — | — |
Limassol, Cyprus AdGuard DNS (94.140.14.14) | — | — |
Kaiserslautern, Germany DNS.WATCH (84.200.69.80) | — | — |
Brisbane, Australia Cloudflare (1.1.1.1 for Families) (1.1.1.3) | — | — |
Yekaterinburg, Russian Federation Skydns (195.46.39.39) | — | — |
Cullinan, South Africa Liquid Telecommunications (5.11.11.5) | — | — |
Lelystad, Netherlands LeaseWeb Netherlands (83.149.125.95) | — | — |
Lille, France Completel SAS (83.145.86.7) | — | — |
Parla, Spain Aire Networks (84.232.73.171) | — | — |
Innsbruck, Austria nemox.net (83.137.41.9) | — | — |
Worcester Park, United Kingdom British Telecommunications (194.72.35.194) | — | — |
Copenhagen, Denmark Fiberby ApS (89.23.231.31) | — | — |
Frankfurt, Germany Ecrcnet (141.1.1.1) | — | — |
Mexico City, Mexico Total Play (186.96.11.240) | — | — |
Sao Paulo, Brazil Oracle Corporation (216.146.36.36) | — | — |
Antalya, Turkey Teknet Yazilim (31.7.37.37) | — | — |
Auckland, New Zealand Voyager Internet (49.50.244.107) | — | — |
Singapore DigitalOcean (139.59.219.245) | — | — |
Seoul, South Korea KT Corporation (168.126.63.1) | — | — |
Beijing, China Baidu Public DNS (180.76.76.76) | — | — |
Bengaluru, India BharatDNS (NIXI) (1.10.10.10) | — | — |
Karachi, Pakistan Connect Communications (118.103.239.9) | — | — |
Lisbon, Portugal Almouroltec (94.46.21.66) | — | — |
DNS Propagation Map
Updating a DNS record, migrating to a new host, or launching a site all raise the same question: has the change actually reached every resolver yet. This map runs your lookup against a curated set of public DNS servers spread across multiple regions worldwide, so you can confirm propagation is complete instead of relying on whatever your own connection happens to see.
What is a DNS propagation checker?
Update a DNS record and it doesn't switch over everywhere at once — every resolver on the internet caches its own copy and keeps serving that copy until its TTL runs out, so for a while, different people can see different answers for the exact same domain depending on which DNS server they happen to be routed through. A DNS propagation checker is how you see that in-progress state directly: instead of guessing, this tool runs a real lookup against 29 independently-operated public resolvers spread across the world and shows, resolver by resolver, which ones already see the change and which are still holding an older cached answer.
How this DNS checker works
One domain, resolvers worldwide
Enter a domain and pick a record type, and this DNS checker sends that same query out to 29 real public DNS resolvers spread across dozens of countries — not a simulation, an actual lookup against each one's own IP.
Every resolver answers on its own
Each resolver replies independently, with whatever it currently has cached. A resolver that already refreshed its cache answers with the new record; one that hasn't yet still hands back the old one, and that gap is exactly what a DNS propagation check is built to catch.
Results land on the map as they arrive
Every resolver has its own pin on the world map, placed at that provider's real network location. As responses come back, each pin updates in place — no page reload, no waiting for the slowest resolver before the first result shows up.
Green means resolved, red means it isn't yet
A green checkmark means that resolver's answer came back; a red cross means it didn't respond with a record for that domain and type. Click any marker or table row to see that resolver's full response, straight off the wire.
Why the same domain can show different results in different places
TTL is the reason. Every DNS record is published with a TTL — a number of seconds telling resolvers how long they're allowed to reuse their cached copy before checking again — and that number is set by whoever manages the domain, not by any individual resolver. A short TTL means resolvers re-check often, so a migration to a new host or an updated MX record for mail delivery shows up almost everywhere within minutes. A long TTL trades that speed for fewer repeated lookups, which also means global DNS propagation after a change can genuinely take up to a day or more before the last resolver's cache finally expires. Neither setting is wrong; it's a deliberate trade-off, and it's exactly what makes checking DNS propagation across many resolvers, rather than trusting whichever one your own device happens to use, the only reliable way to know where a change actually stands.
Reading the map and the results table
Each of the 29 resolvers above has a fixed location on the map, matching that provider's own real network presence — the same city or region its own published documentation gives for it. A yellow pin means that resolver hasn't answered yet; it turns into a green checkmark the moment a real record comes back, or a red cross if it responds with nothing for that record type. The table to the left mirrors the same data resolver by resolver, with each one's actual response time, and clicking through to any single resolver's entry shows the full raw DNS response it sent — id, flags, and all — the same detail a command-line dig lookup would show, not a summarized version of it.
Frequently asked questions
How long does DNS propagation take?
It depends entirely on the TTL (time to live) the old record was published with. A resolver won't ask for a fresh answer until its cached copy expires, so a record with a 5-minute TTL can be fully propagated worldwide in well under an hour, while one published with a 24-hour TTL can take a full day before every resolver on earth has picked up the change. Checking DNS propagation against a spread of real resolvers, the way this tool does, is the only way to see where in that window a domain currently stands.
Why does one DNS server show the new IP while another still shows the old one?
Caching, not an error. Every resolver caches a record independently and only re-checks it once its own copy's TTL runs out — resolvers don't share a cache or notify each other when something changes. A resolver that queried the domain recently can keep serving the old answer for a while after the record's DNS records were updated, right alongside another resolver that happened to query it fresh and already has the new one.
What does 'Not Resolved' mean on the propagation map?
That specific resolver didn't return a record for the domain and record type checked — most often because the domain genuinely has no record of that type published (an AAAA check on a domain with no IPv6 address, for instance), occasionally because that resolver timed out or is temporarily unreachable. It isn't a sign the domain itself is broken; check a different record type or compare it against the other resolvers still shown as resolved.
Is a DNS propagation checker the same thing as a DNS lookup?
Related, but answering a different question. A single DNS lookup asks one resolver for a domain's records and returns whatever that one resolver currently knows. A DNS propagation checker asks many resolvers around the world the same question at once, so the results show whether a change has reached everywhere yet or is still spreading — the comparison across resolvers is the whole point, not any single answer on its own.
Can I speed up DNS propagation?
Not after the fact — once a resolver has cached an answer, nothing forces it to drop that cache early. The one lever that works is set in advance: lowering a record's TTL a day or two before making a change means resolvers will hold shorter-lived copies of the old value, so when the actual change goes live, it reaches every resolver worldwide far sooner than if the old TTL had stayed high.