DNS Propagation: Why Changes Take Time (and How to Verify)

Say "DNS propagation" to ten engineers and you will get two different definitions. Half will describe it as the time a DNS change takes to spread around the world, as though the change sets off from your server and travels outward over the next few hours. The other half will tell you flatly that propagation does not exist.

Both are describing the same thing. The first group is describing it from the outside — what you observe while you wait. The second group is describing the mechanism, and the mechanism is cache expiry.

Your change is instantaneous in exactly one place: the authoritative nameservers for your zone. They return the new value from the moment you save it. Every other system in the world is holding a copy of the old value with an expiry timer attached, and nothing is going to interrupt that timer. Propagation is the period during which those timers run out, in an order nobody controls.

There is no broadcast

Nothing pushes DNS changes anywhere. There is no queue of resolvers waiting to be informed.

When you save a record, the only notification that happens is the one your DNS provider sends to its own secondary servers, so that all of your authoritative nameservers agree with each other. That is a different problem from propagation, and it is normally solved within seconds.

After that, the change spreads only by attrition. Each resolver holding the old answer keeps serving it until its TTL runs out, then asks again, receives the new value, and caches that instead.

Why two people see different answers

Because their caches have different ages. It really is that simple, and it explains why two people in the same office can be looking at the same domain and disagreeing.

One requested the record an hour ago and cached it with a one-hour TTL, so it flips in the next few minutes. Another asked five minutes ago and will hold the old value for nearly another hour. A third is on a mobile network that runs DNS through its own forwarding layer and cached the answer yesterday.

None of them are wrong. They are reading different snapshots, and the disagreement is the system working exactly as designed. Try it on DNS Checkers Check DNS Propagation

The "propagation map" problem

If you have used a propagation checker, you have probably seen a world map with dozens of pins turning green one by one. It is a satisfying animation, and it is also where a lot of people learn something slightly false.

A genuinely global check would need probes in hundreds of networks across dozens of countries. Some services do maintain fleets like that, and they are expensive. Others query a handful of well-known public resolver addresses and plot the results on city pins. The queries are real, but the geography is decorative: many large public resolvers answer from anycast addresses, which means the same IP is served from many locations at once, and the city attached to the pin tells you nothing about where the answer came from.

That does not make the results useless. Comparing several independent resolvers is genuinely the most useful thing you can do after a change. It just means the honest label is "public resolvers queried from this server", not "what users in eleven countries see". We label it that way on purpose.

How to check a change properly

The order matters more than the tooling.

1. Confirm what you changed, and confirm it in the panel rather than from memory. Record the exact name, type and value.
2. Check the authoritative answer first. Ask the nameservers that carry your zone directly. If the new value is not there, nothing downstream will ever show it, and you should stop looking at caches.
3. Only then compare public resolvers. Differences here mean caches at different ages, which is expected during the TTL window.
4. Note the TTL you set. That number tells you how long the full change will take.
5. Check the value you expect, not the one you remember. A surprising number of "propagation problems" turn out to be a typo that was faithfully propagated.

Only once the authoritative answer is correct and the TTL window has passed should you start suspecting anything else.

Negative caching: the ghost that outlasts the change

There is one more cache with a timer you did not directly set, and it catches people repeatedly.

When a resolver asks for a name and is told it does not exist, it caches that refusal. The length of time comes from the zone's SOA record, not from any individual record, and on zones with generous timers it can be a day or more.

So if you asked about your new subdomain before you created it, resolvers may keep insisting it does not exist well after the record is live at the authoritative server. From your side the record is obviously there. From theirs it is not, and they are not going to look again until the negative cache expires.

The same applies to adding a new record type to a name that already exists. The name resolves fine for A records, but the TXT record you just added appears to be missing. It is negative caching, and the fix is patience rather than another edit.

Measuring the window instead of guessing

If you know the TTL you set, you can predict the window rather than wait blindly for it.

Say you lowered the TTL of a record to 300 seconds an hour before the change, and every resolver you checked was reporting 300. When you then change the value, your worst case is five minutes: no cache anywhere can hold the old answer longer than that, because none of them was permitted to store it for longer.

Now say you changed the value without lowering the TTL first, on a record still carrying an 86400. Your window is up to twenty-four hours, and no amount of checking will shorten it. This is the situation where people spend a whole day refreshing a browser and conclude that DNS is broken, when the system is simply being patient on their behalf.

Writing the window down — the record, the TTL, when the TTL was lowered, when the value changed, and the time after which you can reasonably expect consistency — turns an anxious wait into a scheduled check.

When it is not propagation at all

Because propagation is the usual explanation, it is also the usual excuse. A few problems get mislabelled this way almost every time.

If the authoritative answer itself is wrong, that is not propagation — that is a mistake, and waiting will not help. If your host is behind a CDN or proxy and the proxy caches content, you may be seeing stale HTML rather than stale DNS. If one machine is wrong and everything else is right, check that machine's local cache, its VPN, and any local hosts file entries before blaming the internet. And if a single service cannot reach you while everything else can, suspect that service's DNS filtering rather than your zone.

The pattern is the same each time: compare the authoritative answer against what the complaining resolver says. If the authoritative answer is right and the resolver is wrong, you are waiting on a timer. If the authoritative answer is wrong, you have work to do.

What to tell the people waiting

If a change is visible to customers, someone will ask why it is not live yet. A short, specific answer prevents a lot of unhelpful speculation.

"It will resolve that way for everyone within about an hour" is a useful sentence when you have lowered the TTL and know your window. "It depends on each resolver's cache" is technically true and practically useless.

It also helps to say what you have already confirmed. That the authoritative servers are serving the new value, and that the remaining delay is cache expiry rather than a mistake, is the most reassuring thing you can report — because it tells people the work is done and only the timer is outstanding.

And if the change touches mail or a public API, tell the affected parties directly rather than relying on them noticing. A one-line note in advance costs nothing and prevents a support thread at exactly the wrong moment.

What to do while you wait

The useful move is to stop refreshing. Reloading your browser tells you about your browser's cache, not the world's.

If you need certainty, query resolvers you have not queried before, since their caches are less likely to match yours. If a specific machine is stubborn and the TTL has definitely expired, flush that machine's local cache — that is the one cache you are actually allowed to empty. And if a service depends on the change, keep the old endpoint answering until the window has passed; there is no cost to running both for an hour. Try it on DNS Checkers Flush DNS Guide

Document what you changed and when, too. A timeline turns "DNS is being weird" into a question with an answer, and it is the difference between debugging and guessing.