How to read the result
- The first row is the domain’s own name server, asked directly. It holds the record as it is now — the answer every resolver is catching up with.
- A green tick means the resolver returns the same values as the name server; a red mark means it gave no usable answer at all. Once every row has a tick, the change has reached all twelve.
- Differs marks an answer that is not what the name server says. Compare the TTL with a second check a minute later: an old value whose TTL is counting down is a cached copy and will expire by itself.
- Several addresses that differ between resolvers are not always a problem: CDNs and large sites answer with the servers nearest to the resolver, so a resolver in Russia and one in Germany can both be right.
- Does not exist (NXDOMAIN) is cached too. If a resolver looked a name up before you created it, it keeps that answer for the negative-caching time in the zone’s SOA record.
The resolvers this checker asks
| Resolver | Address | Operator | Based in |
|---|---|---|---|
| Google Public DNS | 8.8.8.8 | United States | |
| Cloudflare | 1.1.1.1 | Cloudflare | United States |
| Quad9 | 9.9.9.9 | Quad9 Foundation | Switzerland · filters malware or ads |
| OpenDNS | 208.67.222.222 | Cisco | United States |
| AdGuard DNS | 94.140.14.14 | AdGuard | Cyprus · filters malware or ads |
| Yandex DNS | 77.88.8.8 | Yandex | Russia |
| Hurricane Electric | 74.82.42.42 | Hurricane Electric | United States |
| Control D | 76.76.2.0 | Control D | Canada |
| DNS4EU (unfiltered) | 86.54.11.100 | DNS4EU consortium | European Union |
| Google Public DNS (IPv6) | 2001:4860:4860::8888 | United States | |
| Cloudflare (IPv6) | 2606:4700:4700::1111 | Cloudflare | United States |
| Quad9 (IPv6) | 2620:fe::fe | Quad9 Foundation | Switzerland · filters malware or ads |
All of them are anycast and answer from their site nearest to our test server in Amsterdam. Each is asked directly, with nothing cached in between on our side, and a question that gets no reply within 0.7 seconds is sent once more — so one lost packet does not show up as a failure. A second check asks again. The domain’s own name server is found through its SOA and NS records and asked without recursion; if the name is a CNAME there, the row says so, because public resolvers follow it to the target’s records.
Moving a domain without waiting
- 1Lower the TTL a day ahead
Set the TTL of the records you will change to 300 seconds at least one old TTL before the move, so every cache has picked up the short value by the time it matters.
- 2Change the record
Point the A and AAAA records at the new server — the steps are the same as when you first point a domain to a VPS — and keep the old server running.
- 3Watch it here
Run the check every few minutes until all twelve resolvers show the address the name server has.
- 4Raise the TTL again
Once the old server sees no more traffic, set the TTL back to an hour or more.
Changing name servers takes longer
Moving a domain to new name servers is a change at the registry, and the NS records of most top-level domains are cached for one to two days — that, not an A record, is where “up to 48 hours” comes from. Choose NS above to see which name servers each resolver has. Until they agree, set the same records at the old and the new provider so that either answer is right.
Frequently asked
What is DNS propagation?
Nothing is pushed out when you change a record. The authoritative name servers have the new value at once, but every resolver that cached the old one keeps serving it until its TTL runs out. “Propagation” is those caches expiring, one resolver at a time. That is why this checker asks the domain's own name server too: its answer is the one the resolvers are catching up with.
How long does DNS propagation take?
At most the TTL the old record had when a resolver last fetched it — commonly between five minutes and an hour for A and MX records. The well-known “up to 48 hours” comes from changing a domain's name servers, because the NS records at the registry often carry a TTL of one or two days. Lowering a record's TTL a day before a planned move makes the switch itself take minutes.
Why do some resolvers show a different answer?
Either they still hold the old record in their cache, or the name uses round-robin DNS, a CDN or geographic DNS, which hand out different addresses on purpose — to different resolvers, or in turn. A cached old answer usually shows the old value with a TTL that counts down between two checks; a CDN shows several valid addresses that all belong to the same service.
Which resolvers does this checker ask?
Google Public DNS (8.8.8.8), Cloudflare (1.1.1.1), Quad9 (9.9.9.9), OpenDNS (208.67.222.222), AdGuard DNS (94.140.14.14), Yandex DNS (77.88.8.8), Hurricane Electric (74.82.42.42), Control D (76.76.2.0) and DNS4EU (86.54.11.100), and Google, Cloudflare and Quad9 once more over IPv6 — plus the domain's own name server, asked directly. All questions leave from our test server in Amsterdam, and the anycast resolvers answer from their nearest site, so a name with location-based answers shows the ones meant for Europe.
Can I make propagation faster?
Not for a resolver that already holds the old record — its copy lives until the TTL runs out. Google Public DNS and Cloudflare 1.1.1.1 each have a public form for flushing one name from their cache, which helps if those are the resolvers your visitors use.
Related guides
How to point a domain at your VPS (and add HTTPS)
Two DNS records and a short wait. Which record types to use, how to verify propagation, why it is not instant, and how to add a free HTTPS certificate.
Cloudflare error 522: connection timed out — find what drops Cloudflare at your origin
Error 522 means Cloudflare got no answer from your server within 19 seconds. Find the cause at the origin: firewall, wrong DNS IP, fail2ban bans or overload.