The authoritative answer
What your own nameservers say. This is the truth every cache is converging towards, and it is what each resolver below is compared against — not a majority vote.
DNS changes do not spread. Each resolver holds the old answer until its copy expires, then asks again and gets the new one. So the only real answer to "has it propagated" is how long the slowest cache has left, which is what this shows.
What your own nameservers say. This is the truth every cache is converging towards, and it is what each resolver below is compared against — not a majority vote.
How long a resolver may keep an answer. A record with a TTL of an hour can be an hour out of date, and nothing from outside can shorten that.
One still serving the old record. Not a fault and not something to fix: it is DNS caching working exactly as designed.
A different and more serious problem. If your own nameservers return different answers, there is no correct value for anything to propagate to.
It can tell you what a specific set of large public resolvers currently hold, and how long each will hold it. That is genuinely useful: if Cloudflare and Google already have the new record, most of the internet will follow quickly, because a great many networks forward to them.
It cannot tell you what the internet as a whole sees. Every corporate network, most ISPs and many home routers run their own resolver with its own cache, and none of those is visible from here. A map with pins on twenty cities implies a survey that no tool is actually doing — the pins are a handful of public resolvers, the same handful this page names.
The practical advice is the part nobody likes: lower the TTL before you make a change, not after. A TTL of 300 seconds set a day ahead means the change takes five minutes. Dropping the TTL at the same time as the record means the old TTL still applies to the old answer, and you wait the full original time anyway.
If a resolver is still disagreeing well after its TTL has elapsed, that is worth looking at — some resolvers extend TTLs, and a few ignore very low ones entirely. That is a different problem from propagation, and this page gives you the elapsed-time evidence to tell them apart.
As long as the TTL on the old record, and no longer. If the record had a TTL of 3600, a resolver that cached it one second before your change will serve the old answer for an hour. There is no way to speed that up from outside, which is why lowering the TTL a day before a planned change is the only real technique.
They cached at different times. A resolver that had no copy of the record asks your nameservers and gets the current answer immediately; one that cached ten minutes before your change holds the old answer for the rest of its TTL. Both are behaving correctly.
Because the others are not checking locations either. Querying a resolver tells you about that resolver's cache, not about the country it happens to be in — and a resolver like Cloudflare's answers from whichever of its sites is nearest to us, not to the city on someone's map. We name the ten resolvers we ask so you know exactly what the result covers.
First check that your own nameservers agree with each other, which this page shows at the top — a disagreement there explains everything downstream. If they agree, some resolvers do extend TTLs or apply a minimum of their own, and a few negative answers get cached longer than the record's TTL suggests. Waiting another cycle is usually the answer.
No, and it is slower. Nameserver delegation is cached by the parent zone's TTL, which registries often set to a day or two and which you do not control. Plan a nameserver move in days, not minutes.
A record changed by someone who left, a registrar nobody has the login for, a zone signed but never delegated. We take over the operation of this properly — documented, monitored, and changed through a process rather than through whoever is awake.