EnterraHost
DNS propagation is the wrong name for a real problem. Nothing is pushed anywhere. The authoritative nameservers for a zone hold the records, and every resolver between them and a visitor keeps its own copy until that copy expires. What people call propagation is a set of caches running out at different times, and once you see it that way the wait becomes predictable.
You can watch twenty resolvers report the same record without an account, and the panel itself is read here. This page is about the change and the wait.
There is no list of servers to update
The domain name system is a lookup protocol, not a broadcast one. A resolver that needs a record asks the authoritative server for the zone, and the authoritative server has no way to contact the resolvers that have already asked it. It answers questions and it forgets them.
That is why a change is invisible at first and then appears unevenly. The zone has the new value immediately. Every cache holding the old one keeps serving it until its copy expires, and caches expire when they expire rather than when you would like.
A TTL is a ceiling, not a schedule
The time to live is the maximum a resolver may keep an answer. It is not a promise about how long it will. A resolver is free to discard a record early, and busy public resolvers do, but none may keep one longer than the TTL allows.
A real lookup makes the point better than a description. This is the A record of example.com, asked of four public resolvers in each of five regions in a single pass on 2026-10-09. All twenty returned the same two addresses. Their remaining TTLs were 4, 19, 35, 42, 55, 92, 111, 150, 165, 224, 268 and 300 seconds, with several values repeated because two resolvers often share a cache state.
One record, nobody disagreeing, and a spread of nearly two orders of magnitude. A resolver reporting 300 is at the start of a fresh copy. The one reporting 4 is about to ask the authoritative server again, and when it does it will see whatever the zone says at that moment.
Why two resolvers disagree
They are not disagreeing about the zone. They are reporting two caches that were filled at different times, and if the record changed in between, one of them is holding history.
That is also why a lookup from your own machine is a poor test. Your operating system, your browser and the resolver your internet provider runs are three separate caches, and a record you can see is a statement about those three rather than about the internet.
Planning a change so the wait is short
The TTL is the only lever, and it has to be pulled before the change rather than after it.
Lower the TTL on the record a day or more ahead, to something in the low minutes. Then wait at least one full period of the OLD TTL before making the change, because that is how long the existing copies may still be held. Only then move the record, and leave the short TTL in place until the change is visible everywhere. Raising it back immediately is the mistake that leaves a long tail of old answers behind, because caches that had not yet asked will take the new, long TTL when they do.
Lowering a TTL does not shorten the wait for a copy that already exists. It shortens the wait for the next change, and the next change is the only one it can help. The copies already out there still hold what they hold.
An empty answer is cached too
A record that does not exist is an answer, and it is cached like any other. RFC 2308 defines how long a resolver may hold a negative answer, and the period comes from the zone's own start of authority record rather than from the missing record.
The practical result is a trap. If a name is looked up before it exists, the "no such record" answer is kept, and creating the record afterwards does not clear it. The lookup keeps failing while the zone is perfectly correct, which reads as a propagation problem and is really a negative cache counting down.
Layers that look like DNS propagation
Three other caches are often mistaken for the domain name system, and all three are local to you.
Your operating system caches answers for a short period of its own, and your browser may hold one longer. A content delivery network keeps its own view of which edge answers for a name, and it does not necessarily re-read your zone when you change it. And a hosting panel that shows a record is showing you the zone rather than what any resolver thinks, which is the difference between the value you set and the value the world is serving.
When one machine sees a change and another does not, the domain name system is the last place to look rather than the first. A lookup from twenty resolvers is the test that separates your local cache from everybody else's.
How to tell when it is over
Run a lookup over all five regions and read the consensus figure. While it reports more than one answer set, something out there is still serving an older copy, and the lowest TTL tells you how long the quickest of them will take to ask again.
When every resolver returns the same set, the change has reached everywhere this tool can see. That is a smaller claim than "everywhere", and it is the honest one. It covers twenty resolvers in five regions, which is enough to tell you whether a record is settling or stuck, and it is not a census of the internet.