“Waiting for DNS to propagate” is the most common description of something that does not happen. There is no propagation in DNS. Nothing is pushed anywhere. Understanding what is actually going on turns a mysterious waiting period into an arithmetic problem you can predict and control.

Nothing Travels

When you change a record, exactly one thing happens: your authoritative nameservers start returning a new answer. That change is complete the moment the zone reloads, which is usually seconds. Any resolver that asks after that gets the new value immediately.

What varies is when each resolver next bothers to ask, and that is governed entirely by the TTL of the answer it cached before you made the change. A resolver holding a record with a 3600 second TTL will keep serving the old value for up to an hour, and no action on your end reaches inside its cache. You are not waiting for something to spread. You are waiting for copies to expire.

This is why checking from eight locations gives eight different answers during the window, and why the pattern looks random. Each of those resolvers cached at a different moment, so each expires at a different moment. The propagation checker on mrdns.com is really a cache-expiry checker, and reading it that way makes the staggered results obvious.

The TTL That Matters Is the Old One

Here is the part that trips people up. Lowering a record’s TTL right before you change it does nothing useful, because resolvers are still holding the copy they fetched under the previous, longer TTL.

; Monday: the value resolvers have cached
www.example.com.    86400    IN    A    203.0.113.10

; Friday: lowered TTL and changed the address at the same time
www.example.com.      300    IN    A    203.0.113.55

A resolver that cached on Monday holds the old address for a full day regardless of what Friday’s record says, because it will not re-ask until its copy expires. The 300 second TTL only starts applying to whatever it fetches next.

The sequence that works is to lower the TTL first, wait at least the old TTL so every cached copy expires and gets replaced by a short-lived one, and only then change the value. Now the maximum staleness is 300 seconds. Raise the TTL again once the change has settled.

For a planned migration that means starting a day or two ahead. Doing it the other way around and then waiting is the origin of most “DNS is still propagating” complaints.

Negative Answers Cache Too

If someone queries a name before it exists, the NXDOMAIN gets cached. The lifetime of that negative answer comes from the zone’s SOA record, specifically the minimum field, per RFC 2308:

example.com.  IN  SOA  ns1.example.com. hostmaster.example.com. (
                  2026081101   ; serial
                  7200         ; refresh
                  3600         ; retry
                  1209600      ; expire
                  3600 )       ; minimum, caps negative caching

A large minimum means that a name someone checked prematurely stays broken for them long after you create it. An hour is reasonable. The multi-day values that appear in copied-and-pasted zone files are not, and they produce the particularly confusing case where a brand new hostname works for most of the world and not for the one person who tried it early.

The Other Places Answers Hide

Delegation TTLs are longer than record TTLs and get overlooked. If you change nameservers, the parent zone’s NS records govern how long resolvers keep asking your old provider, and those are often set to a day or two by the registry. The records at your new provider can be perfect while resolvers continue to consult the old one.

CNAME chains expire independently. Each link has its own TTL, so the effective staleness is set by whichever link is longest, and updating the target does nothing for a resolver still holding the alias.

Then there is everything below the resolver: the stub resolver on the client, the browser’s own cache, and any corporate forwarder in between. Chrome caches independently of the operating system, which is why a page can stay stubbornly wrong on one machine after dig on the same machine returns the new value.

How to Check Properly

Query the authoritative server directly to confirm the change is live, then query a public resolver to see what the cached world still believes:

dig @ns1.example.com www.example.com A +norecurse
dig @8.8.8.8 www.example.com A

The TTL in the second answer counts down toward zero, and it tells you precisely how much longer that resolver will serve the old value. That number is the actual answer to “how long until this is done”, and it is available immediately rather than after waiting to find out. If you want the same view without a terminal, the lookup tool shows the returned TTL alongside the record.