DNS propagation explained

You updated an A record, pointed it at a new server, and refreshed the site. On your laptop it works. A colleague across the country still sees the old page. Someone on their phone gets a mix of both depending on the minute. Nothing is broken. This is DNS propagation, and understanding it turns a confusing wait into a predictable one.

There is no single DNS

It is tempting to picture "the DNS" as one big database you update and everyone reads. In reality there are thousands of independent resolvers — the ones run by Cloudflare, Google, your ISP, your office, your phone carrier — and each keeps its own cache. When you change a record at your authoritative nameserver, none of those caches find out immediately. They keep serving the answer they already have until it expires.

That is the whole mechanism. "Propagation" is not your change being pushed outward. It is the old answer being forgotten, cache by cache, at different times.

TTL is the timer that controls everything

Every DNS record carries a TTL, a time-to-live measured in seconds. When a resolver looks up your record, it is allowed to cache the answer for that many seconds before it has to ask again. A TTL of 300 means caches let go after five minutes. A TTL of 86400 means they can hold the old value for a full day.

This is why two people see different things at the same moment: their resolvers cached your record at different times, so their timers expire at different times. It is also why the delay is bounded. Once the longest relevant TTL has passed since your change, every cache that had the old value has had to refetch it.

The practical lesson: lower the TTL before you plan a change. Drop it to 300 seconds a day ahead, make the change, confirm it, then raise it back. The day-ahead part matters because the old TTL governs how long the old value lingers.

What a propagation checker actually shows

A propagation checker queries the same record against several independent resolvers at once and lays their answers side by side. The point is not geography — most public resolvers run on anycast networks, so you are not really sampling specific countries. The point is that each resolver has its own cache with its own timer. Comparing them tells you how far along the "old answer being forgotten" process is.

Reading the results is straightforward:

All resolvers agree on the new value: the change has propagated. You are done.
Some show the new value, some show the old one: the change is in flight. The laggards are still inside their cached TTL window. Wait and recheck.
A resolver returns NXDOMAIN or no record: either the record genuinely does not exist, the domain is mistyped, or — for a brand-new domain or record — that resolver simply has not been asked yet.

Use the DNS Propagation Checker right after an A-record migration, a nameserver switch, or adding an SPF, DKIM, or DMARC TXT record. If you want to see every record type a domain publishes in one shot rather than compare resolvers, the DNS Lookup tool is the companion.

Special cases worth knowing

Nameserver (NS) changes are the slow ones. Changing which nameservers are authoritative for your domain involves the TLD's records, which often carry TTLs of a day or two, and registrars can add their own delay. Plan for up to 48 hours rather than minutes.

Negative answers get cached too. If a resolver looked up a record before it existed and got "no such record," it caches that absence for the period set by your zone's SOA record. So a brand-new record can appear "missing" on a resolver that asked too early, even though the record is live at the source.

Your browser and OS cache as well. Before blaming DNS, remember the local layers: your operating system and browser keep their own short-lived caches. A propagation checker queries resolvers directly and skips those, which is exactly why it can show the new value while your own browser still shows the old one.

The short version

DNS does not push changes; caches forget old answers on their own schedule, and the TTL is that schedule. If you lowered the TTL ahead of time, propagation is a matter of minutes. If you did not, it is a matter of however long the old TTL was. A propagation checker just lets you watch independent caches catch up so you know when the wait is over instead of guessing.