DNS Propagation Explained
DNS propagation is not a wave spreading across the internet but caches expiring one by one, and TTL decides how long that takes.
When you change DNS settings, you expect a swift update, but DNS changes do not spread instantly or evenly. DNS "propagation" is not a single wave of change; it is a gradient of expiring caches. The same site can appear differently across devices and networks until the cached copies run out.
How DNS caching works
DNS lookups depend on caches to speed up results. When a device looks up a domain, the network's recursive resolver fetches the answer from the authoritative name server and keeps a copy. How long that copy counts as valid is set by the Time-To-Live (TTL) field on the DNS record, measured in seconds and chosen by whoever manages the zone.
So when you change a record, the new value appears only as each resolver's cached copy expires and it asks your authoritative DNS server again. Negative answers are cached too: if a resolver was told a name did not exist, it can keep that answer for the lower of the SOA record's MINIMUM field and the SOA record's own TTL, so a brand-new record may also take a while to appear.
Nameserver changes are slower than record changes. Here the update goes through your registrar to the registry of your top-level domain, and resolvers also cache the old delegation. Cloudflare, for example, tells users that registrars can take up to 24 hours to process a nameserver update.
Why one device sees the old site
Caches sit at several points: the browser, the operating system, the home router, the ISP's or public resolver. Each keeps its own copy under its own timer, so visitors on different networks, or even two devices in the same room using different resolvers, may see different things at the same moment. A colleague in another city may already see the new site while you still see the old one. Clearing the browser or operating system cache only affects that one device. The upstream recursive resolver still holds its cached answer until the TTL expires.
How to check and plan a change
You can query public resolvers such as Google Public DNS (8.8.8.8) or Cloudflare's 1.1.1.1 with command-line tools like dig or nslookup, and compare the answer with your authoritative name server:
dig example.com A @8.8.8.8
dig example.com A @1.1.1.1
nslookup example.com 8.8.8.8Online lookup tools that query resolvers in many locations give a wider view, since each resolver caches independently. Google Public DNS and Cloudflare's 1.1.1.1 also offer web tools to flush a specific name from their caches; Google advises flushing the main domain first if the registrar or DNS hosting changed. These tools and their menu labels can change over time.
To make a planned move faster, lower the TTL on the records you will change well ahead of time, then wait at least as long as the old TTL so every cached copy carrying the long value has expired. After that, make the change: it should be picked up within roughly one new, short TTL. Once everything works, raise the TTL again. On Cloudflare, the Auto setting is 300 seconds and unproxied records can be set as low as 60 seconds on non-Enterprise plans.
No DNS update becomes visible everywhere faster than the longest remaining cached copy, so a promise like "it will propagate in exactly 24 hours" is not something anyone can guarantee. If some visitors still see the old site, the next troubleshooting step is to find which resolver or network has not yet queried the authoritative name server again.
