The Field Guide

A TTL is a number attached to every DNS record, measured in seconds, that tells any resolver how long it may keep the answer before asking again.

That is the entire mechanism. A record with a TTL of 300 may be cached for five minutes. One with 86400 may be cached for a day. Nothing more complicated is happening.

Here is the part that catches almost everybody. When you change a record, the TTL that governs how long the old value survives is the one that was already published, not the one you just set.

If your record had a TTL of 86400 and you change both the value and the TTL to 300, resolvers that cached the old answer are still entitled to hold it for up to a day. They cached the old value along with the old instruction.

Which is why the trick is to lower it first

Lower the TTL a day before you plan to make the change. Wait for the old TTL to expire everywhere. Then make the actual change, which now propagates within minutes because the currently cached instruction is short.

Raise it again afterwards, once you are confident, because a permanently low TTL means more queries and slightly slower lookups for no benefit.

The reason a change appears to reach some people and not others is not that it is travelling. It is that different resolvers cached the old answer at different moments, so their copies expire at different moments.

Your machine may see the new value in seconds because it had never looked before. A colleague's may take an hour because theirs looked forty minutes ago. Neither is more correct.

What "propagation" actually describes

Nothing propagates outward from your nameservers. Resolvers pull, they do not receive. The phrase describes the period during which independently-timed caches happen to still be holding old answers, which is why nobody can give you an exact completion time.

The upper bound is knowable, though, and it is the previous TTL. Past that, every resolver that follows the rules has discarded the old value.

The full sequence, for any change that matters:

• A day or two before: lower the TTL on the records you intend to change, to 300 seconds.
• Wait out the old TTL. If it was 86400, wait a full day. This is the step people skip and then wonder why the change was slow.
• Make the change. It will now be visible almost everywhere within five minutes.
• Verify from outside, using a resolver you have never queried from, rather than from your own machine.
• Raise the TTL back after a day or two of confidence.

If more than the previous TTL has passed and the old value is still appearing, the problem is almost certainly not caching.

Check these, in order

• Did you edit at the right provider? Records live wherever your nameservers point, which is frequently not your registrar. Editing a zone at a provider that is no longer authoritative changes nothing at all, and the panel will happily accept it.
• Is there a second record? Two records for the same name produce unpredictable answers. This is the usual cause of a change that works intermittently.
• Is a CDN or proxy in front? If traffic passes through something like a proxy, the DNS change may be correct and the proxy may still be sending to the old origin.
• Is your own machine the problem? Operating systems and browsers cache separately from resolvers. Query a public resolver directly rather than trusting what your browser shows.

In roughly nine cases out of ten the answer is the first one: the zone being edited is not the zone being served.