DNS propagation is a myth

DNS propagation isn't a real transport mechanism. No protocol pushes your change out to resolvers around the world. What actually happens is that cached answers expire on their own schedule, and until they do, a resolver keeps handing back whatever it cached last, regardless of what the authoritative server now says.

What a DNS change actually does

Update a record at the authoritative name server and the change is live there immediately. There's no queue, no batch job, no multi-day rollout on the authoritative side. The only reason anyone downstream sees the old answer afterward is caching: every recursive resolver between the authoritative server and the end user stores the answer for the record's TTL, in seconds, and only asks again once that window closes.

That's the whole mechanism the myth-busting posts already cover well: shorten the TTL before a planned change, and the visible delay shrinks to match. It's also where the story usually stops, and where it misses a second, separate delay that has nothing to do with the TTL you set.

The part the TTL explanation skips: negative caching

Resolvers don't just cache records that exist. They cache the fact that a name doesn't resolve. An NXDOMAIN or NODATA response gets stored too, under a negative TTL drawn from the zone's SOA MINIMUM field, defined in RFC 2308, and that value is often set well above the positive TTL you're used to tuning.

That produces two failure modes the single-TTL explanation doesn't predict. Create a brand-new subdomain, and any resolver that had already queried it before you added the record cached a negative answer, one that keeps returning "no such host" until the SOA minimum window closes, not until your record's own TTL would suggest. Delete a record, and there's a two-stage delay: the old positive answer expires on its own TTL first, then a fresh NXDOMAIN gets cached on top of it under the SOA minimum, so the name can look briefly gone, come back to a stale answer through a different resolver, and only settle into a consistent NXDOMAIN once both windows have run out.

Neither of those looks like a normal TTL countdown from the outside. They both look like the record is stuck, which is usually read as evidence the myth is wrong and propagation really does take a while. It's still cache expiry, just two different caches expiring on two different clocks.

Three ways to check it, and what each one actually proves

"Has it propagated" isn't one question. These three checks answer three different ones:

• dig +trace <name>: walks the full delegation path from the root down to your authoritative server and shows what each hop currently answers. It proves the authoritative chain is configured correctly, right now. It never touches a resolver's cache, so it can't tell you what any real user's DNS is currently serving.
• dig <name> @<your-nameserver>: queries your authoritative server directly, bypassing every cache in between. It confirms the change is actually live at the source, useful when a trace is slow or the edit is only seconds old. It answers the same narrow question as +trace: is the source right, not what does the world see.
• A public resolver panel: such as whatsmydns.net, queries a fixed set of public resolvers spread across regions and shows a live snapshot of what each one currently has cached. This is the closest proxy to "will my users see this," but it's a sample of resolvers, not an exhaustive one, and it can't see the one resolver that matters most: the specific ISP resolver an actual visitor is stuck behind, some of which cap or extend TTLs in ways that don't follow the record at all.

Run all three and you can confirm the authoritative record is correct and see a broad, current snapshot of cache state elsewhere. What none of them can do is confirm a single specific reader's resolver, browser cache, or OS-level DNS cache has caught up, because that state is private to their machine and their network path.

Why verifying a change isn't a one-time step

Because two separate expiry clocks are involved, and because some resolvers don't honor TTL strictly, the honest answer to "is it propagated yet" is a distribution across a resolver population converging over time, not a single moment you can check the day after a change and close the ticket on.

WebPixie's DNS monitoring checks records daily against the authoritative server directly, with public resolvers used only as a fallback when the authoritative server itself doesn't answer. That ordering matters for exactly this reason: querying the authoritative server first means a check is comparing against the actual source of truth, not against whatever a resolver may still be holding onto from before your change. The same snapshot-and-diff approach covers detecting DNS record changes generally, and pairs with a broader question of what DNS monitoring catches beyond propagation specifically. Treating a DNS change as verified once and done is the same mistake as treating propagation as a wait time instead of a cache: both ignore that the underlying state keeps moving until every cache involved, positive and negative, has actually expired.