Free tool
Whether your DNS change is already visible around the world, and how long each old copy has left.
Reference
Your DNS provider serves the change as soon as you save it. What takes time is each resolver throwing away the copy it had stored, and that's decided by the TTL.
The reference
We query the domain's authoritative servers directly, with no cache in between: what they say is what everyone will see once the copies expire. If they still don't give the new value, waiting won't help: the change isn't in the zone the domain uses.
The same question, three answers
examplens1.yourprovider.com
authoritative: the current value
1.1.1.1 · Cloudflare
has already renewed its copy
8.8.8.8 · Google
copy stored before the change
The TTL
The TTL says how many seconds a resolver can keep the answer. Each one asked at a different moment, so each one renews it in its own time. In the worst case, the last one takes a full TTL from your change.
1 h TTL: time left for each
example1.1.1.1
Cloudflare
9.9.9.9
Quad9
8.8.8.8
What isn't propagation
Large services give a different IP depending on where the query comes from: it's geographic load balancing or a CDN, and with a one-minute TTL it leaves no old copies. Also, almost all these resolvers are anycast: the node closest to whoever asks answers, so the country is the operator's. And if you change the DNS servers of a .es domain, Red.es comes before any cache: it publishes the zone in rounds of about four hours.
www.github.com · A
real examplens-520.awsdns-01.net
authoritative
dns1.p08.nsone.net
authoritative, another IP
4.2.2.1 · Level 3
another region of the service
168.126.63.1 · KT
another region of the service
At most, the TTL the record had before you changed it, counted from the change. With a TTL of 300 it's five minutes; with 86400, a day. The oft-repeated “48 hours” comes from DNS server changes at the registrar, where the TTL of the delegation in the top-level domain's zone applies (two days for .com), and from internet providers that extend cached copies on their own.
Because each resolver stored its copy at a different moment and renews it when it expires, not when you change the record. Your own computer, the browser and the router also keep copies: if everything looks fine here and you still see the old value, flush your computer's DNS cache (ipconfig /flushdns on Windows, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder on macOS) and try a private browser window.
Once the change is made, no: copies already stored last for their TTL. What does work is preparing for it: lower the TTL to 300 a day before (or at least the old TTL ahead of time), make the change and raise it again when it's done. Google and Cloudflare also let you ask them to flush a name from their public resolvers, but that only affects them.
Because Red.es doesn't publish changes to the .es zone immediately, but in cycles of about four hours: they have been observed at 2, 6, 10, 14, 18 and 22 h, mainland Spain time, although there's no official schedule. A server change made at 10:05 usually waits for the 14:00 one, and after that the caches still count. It only affects DNS server changes and new domains: editing an A, MX or TXT record in a zone that already works waits for no one.
For large services, yes. Many spread traffic with geographic load balancing or a CDN and answer with the IP of the data centre closest to whoever asks; that's why www.github.com returns several IPs at once. We detect it when the authoritative servers themselves give different answers or when there are several with a short TTL, and in that case we don't flag it as a half-finished change. If the name is an alias (CNAME) to a CDN, we compare the alias, which is what your zone publishes. To see all the records for a name, use the DNS lookup.
