DNS Propagation Myths — DNS Panopticon

The short answer

DNS changes do not travel outwards from your provider. Your authoritative servers start serving the new record as soon as the change is published, usually within seconds. What people call "propagation" is recursive resolvers around the world each holding an older copy in cache until its TTL runs out. Different resolvers fetched the record at different times, so they expire at different times.

That means the worst-case wait is set by the TTL that was published before the change, not by the new one, and not by a fixed "24 to 48 hours."

Common myths

Myth	What actually happens
Every DNS change takes 24 to 48 hours	A record change is visible to a resolver as soon as its cached copy expires. With a 300 second TTL that is five minutes. The 48 hour figure comes from name server changes, where the TLD's NS records are often cached for one to two days.
Lowering the TTL speeds up the change	Only if you lower it in advance. Resolvers that cached the record under the old TTL keep it for that long. Lower the TTL at least one old TTL before the change.
Propagation checkers show the whole internet	They query a few dozen public resolvers. Your users' ISP resolvers, corporate resolvers and browsers have their own caches.
Flushing my computer's cache fixes it for everyone	It only clears your machine. You cannot flush a public or ISP resolver, though some (Cloudflare, Google) offer a purge form for single names.
A new subdomain needs to propagate	A name nobody has asked for is not cached, so it resolves at once. The exception is a resolver that recently got NXDOMAIN for it, which keeps that negative answer for the zone's negative TTL.

Why some resolvers still show the old answer

The old TTL. A resolver that fetched the record a minute before your change keeps it for the full old TTL.
Negative caching. If someone looked up the name before it existed, the NXDOMAIN is cached for the SOA minimum or the SOA TTL, whichever is lower (RFC 2308). See negative caching.
TTL floors and caps. Some resolvers enforce a minimum or maximum TTL, so the timing will not match your setting exactly.
Serve-stale. Resolvers that implement RFC 8767 may keep answering with expired data when they cannot reach your servers.
Other caches. Operating systems, browsers, and long-running applications such as JVMs can hold answers beyond the DNS TTL.
A name server change. Until the delegation in the TLD expires from cache, some resolvers ask your old provider. If the old provider still serves the zone, they get the old records.

Checking where a change has reached

First confirm the authoritative answer, then compare it with resolvers and watch the remaining TTL count down:

Command	What it shows
dig +norecurse @ns1.example.net www.example.com A	What your authoritative server serves now
dig @1.1.1.1 www.example.com A	Cloudflare's cached answer; the TTL column is the time left before it refetches
dig @8.8.8.8 www.example.com A	The same for Google Public DNS
dig +norecurse @a.gtld-servers.net example.com NS	The delegation a .com resolver will follow after a name server change

Planning a change

Lower the TTL on the records you will change, then wait for at least the old TTL.
Make the change and confirm it on every authoritative server.
Keep the old target (server, IP, or old DNS provider) running until the old TTL has passed again.
Raise the TTL back once you are sure you will not need to roll back.

Moving DNS providers covers the longer plan for a name server change.

How DNS Panopticon helps

Domain Visualizer shows each record's TTL as the resolver returned it. If you choose a second resolver, it compares their answers and reports a resolver variance finding when they differ, which is often a cache that has not expired yet. Visualizer keeps a scan result for 24 hours by default and marks it as cached, so it is not a tool for watching a change land minute by minute. Use the commands above for that.