01Copies, not waves
A domain’s records live on its authoritative nameservers — the servers named in its NS records, run by whoever hosts its DNS. Change a record there and the change is complete at once: ask those servers a second later and they give the new answer. Nothing more has to happen for the change to exist.
Almost nobody asks those servers directly, though. Your laptop asks a resolver — your internet provider’s, or a public one such as Google’s 8.8.8.8 — and the resolver asks the authoritative servers on your behalf and then keeps the answer, so that the next ten thousand people who ask it do not have to wait. What people call propagation is those kept copies running out, one resolver at a time, each on its own schedule.
02The TTL is set in advance
Every record carries a TTL — time to live, in seconds — and a resolver may keep its copy for that long and no longer. The catch is that the TTL that counts is the one the record had when the resolver asked. A record with a TTL of a day, changed at noon, can be served in its old form until noon tomorrow by a resolver that fetched it at 11:59. Lowering the TTL at the moment of the change does nothing for copies already out there.
That is why the TTL column on this page counts down. The number a resolver returns is not the record’s TTL but the time its copy has left; when it reaches zero, that resolver will ask again on its next question and get whatever the authoritative servers say then.
03One address, many machines
8.8.8.8 is not a computer. It is an anycast address, announced from hundreds of places at once, and the network delivers each question to the nearest of them. Each of those machines — or clusters of them — has its own cache. When this page asks 8.8.8.8, the answer comes from the Google node nearest our server; a visitor on another continent reaches a different node that may hold a different copy, fetched at a different moment.
So no checker can see “the world”. This one shows fourteen resolvers as seen from one place, which is a fair sample of the copies in circulation and says honestly what it is. Your own provider’s resolver, and your computer’s own cache, are not on it — and they are the two most likely to be holding the old answer you are looking at.
04Different, and still right
A resolver that gives a different answer is usually holding an old copy — but not always, and the reading says when it looks like something else:
| What you see | What it usually means |
|---|---|
| A different address, the TTL well above the record’s own | A copy of the previous answer, fetched before the change. It expires when its countdown reaches zero. |
| Every resolver a different address, all with short TTLs | Location-aware DNS: a CDN or load balancer hands each asker a nearby address. Nothing is out of date. |
0.0.0.0 or a block page’s address at AdGuard, OpenDNS or CleanBrowsing | A filtering resolver refusing to send its users there. A policy, not a cache. |
| NXDOMAIN at some resolvers for a name just created | Negative caching: they asked before the name existed and were told so, for the time set in the zone’s SOA record. |
| SERVFAIL at Google, Cloudflare and Quad9 only | They check DNSSEC signatures and the check failed — usually a DS record at the registrar that no longer matches the zone. |
| Silence from the resolvers in China | Questions from outside China are often slow or unanswered there. It is counted as no answer, never as agreement. |
05Moving to new nameservers
Changing which company hosts your DNS is a change one level up: the new nameservers are recorded at the registry for your ending, and resolvers cache that delegation too — for .com and .net, the registry hands it out with a TTL of two days. During that window some resolvers still ask the old provider’s servers and some ask the new one’s.
The move is painless if both answer the same. Copy every record to the new provider before switching the nameservers, leave the old zone running until the old delegation has certainly expired, and only then take it down. Check the NS type here to watch the resolvers move across.
06Changing DNS without waiting
- Look up the record’s current TTL here — the authoritative row shows it.
- At least that long before the change, lower the TTL to 300 seconds, changing nothing else. The old, long copies drain away.
- Make the change. Every copy in circulation now expires within five minutes.
- Check it here: the countdowns show exactly when the last different copy runs out.
- Once it is right, put the TTL back up — an hour or a day — so resolvers ask less often.
07How this check works
- Your input is reduced to a name: a scheme, path, port or mailbox around it is dropped, and an internationalised name is converted to its ASCII form.
- The domain’s nameservers are found from its delegation, each resolved to a public address, and asked the question directly with recursion off — the authoritative answer, the truth.
- The same question goes to fourteen public resolvers at the same moment, over UDP port 53, each with three seconds to answer; a truncated reply is asked again over TCP.
- Each answer is compared with the authoritative one, record by record, and its TTL is kept as the time its copy had left.
- This page counts every TTL down from the moment the reading was taken, and reads the pattern of differences back to you in plain words.
A reading is kept on our server for thirty seconds, so asking again sooner shows the same one — the page says when that happens. Each address may run twenty checks a minute. No account, no tracking, and nothing you check is kept anywhere but that thirty-second cache.