DNS propagation

A resolver that asked before your change holds the old answer until its TTL expires. It does not learn about the change and has no reason to ask again early.

Resolvers around the world cached at different moments, so they expire at different moments. There is no coordinated cutover.

Operating systems and browsers keep their own caches in front of the resolver, adding another layer with its own lifetime.

Some resolvers enforce a minimum caching period of their own, ignoring a very short TTL you published.

The sum is a tail: most clients see the change within the TTL, and a minority take noticeably longer.

The change is not travelling between servers. Your authoritative nameservers hold the new record the moment your provider publishes it, and anyone asking them directly gets it immediately.

Internal replication between your own nameservers is normally seconds, not hours. When it is not, that is a fault rather than propagation.

Registrar changes are the exception that genuinely is slow: changing which nameservers are delegated to a domain is governed by the parent zone's TTL, which you do not control.

So 'wait 48 hours' is a rule of thumb covering the worst case, not a description of a mechanism.

Lower the TTL well in advance — at least the current TTL before the change — so every cached copy expires into a short-lived one.

Make the change, confirm it at your own nameservers immediately, then watch public resolvers converge.

Restore the normal TTL afterwards.

Keep the old destination serving during the window. Whatever the TTL says, some clients will arrive at the old address for longer than expected, and an old server that still answers correctly makes the tail invisible.

`dig @8.8.8.8 example.com A +short` and the same against other public resolvers show what each one currently returns.

`dig example.com A` without a server shows what your own resolver holds, including the remaining TTL, which tells you how long that copy has left.

`dig @ns1.example.net example.com A` queries your authoritative server and bypasses caching entirely; this is the answer that proves the change was actually published.

Flushing a local cache affects only that machine. It does not help anyone else and does not shorten anything.