DNS propagation check
One lookup tells you what a single cache holds. This asks four resolvers in different parts of the world at the same time, so after a change you can see who has caught up and who has not.
- Cloudflare1.1.1.1
- Google8.8.8.8
- AliDNS223.5.5.5
- DNSPod119.29.29.29
Las consultas se procesan en el momento y no se guardan. MyIPKit no conserva ningún registro de lo que consultas.
What this actually measures
Nothing about DNS spreads outward. A change is live at your nameserver the instant you save it. What delays it is that resolvers around the world already asked, got an answer, and were told how long they may reuse it. This page samples four of those caches at once.
Reading the result
- Everyone agrees, and it is the new value — the change is done.
- Everyone agrees, and it is the old value — every cache is still inside the old TTL. Wait.
- Some agree and some do not — you are partway through. The "expires in" column says how much longer.
- Everyone agrees, and it is neither value — the record is not what you think it is. Check you edited the zone the domain actually uses.
- They disagree but you changed nothing — likely geographic routing rather than a cache. Resolvers in different regions are meant to differ.
If it still looks wrong afterwards
Once every resolver here shows the new record and your browser does not, the remaining cache is on your own machine. Why a DNS change has not taken effect covers how to clear each one, and the mistakes that look like a slow change but are not.
Why do resolvers disagree right after I change a record?
Each resolver cached the previous answer and is allowed to keep serving it until the old TTL expires. Nothing is propagating; they simply have not asked again yet.
How long until they all agree?
At most the TTL that was set on the old record, counted from when you saved the change. Lowering the TTL now does not speed up caches that already hold a copy.
All four agree but my browser still shows the old site.
Your browser and operating system keep their own DNS caches, and the browser also caches the page itself. Test in a private window, and flush the OS cache.
They disagree but I have not changed anything.
Then it is probably not a cache. Many large sites publish different addresses to different parts of the world so each visitor reaches a nearby server, which means resolvers in different regions are supposed to disagree. Compare the addresses: two locations of one service look different from an old value and a new one.
Why these four resolvers?
They are large, public, operate in different regions and serve the DNS-over-HTTPS JSON API. Filtering resolvers are excluded on purpose: they answer differently by policy, which would read here as a stale cache.
Does this query my authoritative nameserver?
No. It asks four public recursive resolvers, which is the point — they are the caches your visitors actually use. To ask your own nameserver directly, run dig against it.