DNS propagation isn't a thing — here's what's actually happening
The phrase 'DNS propagation' is misleading. There's no synchronous global update. What you're actually waiting for is a million independent caches to expire — and that timing depends on choices made by you, your registrar, and every resolver in between.
You change a record at your registrar. Your colleague checks the new value an hour later — still seeing the old one. Their phone, on cellular, sees the new one fine. You google "how long does DNS propagation take" and the first answer says "up to 48 hours." That's not really an answer.
The 48-hour figure isn't wrong, but the framing is. DNS doesn't "propagate." There's no central registry pushing updates outward in waves. What's actually happening is much simpler — and once you understand it, the timing becomes predictable rather than mysterious.
The system is just caches all the way down
When your colleague's laptop resolves example.com, it doesn't talk to the authoritative nameserver you configured at your registrar. It talks to the stub resolver in their OS, which talks to a recursive resolver their network has been told to use (usually their ISP's, or a public one like 1.1.1.1 or 8.8.8.8), which may forward to another recursive resolver, and so on, until somebody finally has to ask the authoritative nameserver.
Every link in that chain caches the answer. The TTL — time-to-live — on the record tells each cache how long it's allowed to keep the answer before re-asking.
The TTL you see at your registrar is a hint, not a contract. Recursive resolvers can choose to honour it, cap it (some ISPs floor TTLs at 5 minutes regardless of what authoritatives say), extend it (rare), or pre-fetch records before they expire to keep their cache warm. There's no enforcement.
So when you change a record:
- The authoritative nameserver starts serving the new value immediately.
- Caches that don't have the old value yet ask the authoritative and get the new one.
- Caches that do have the old value keep serving the old one until their entry expires.
- When their entry expires, the next user who asks triggers a fresh lookup. They get the new value. The cache is now warm with the new answer.
There's no broadcast. There's no "propagation." Each cache flips independently when its specific copy of the record happens to expire.
Why your colleague sees the old value, but their phone sees the new one
They're using different recursive resolvers.
The laptop is probably using the corporate DNS (or whatever DHCP gave them on the office wifi). That resolver fetched example.com 20 minutes ago — its cache says "valid for another 40 minutes."
The phone, on cellular, is using the carrier's recursive resolver. That resolver hadn't fetched example.com recently — its first query after you made the change went straight to the authoritative server and got the new value.
Both behaviours are correct. They're just different caches at different points in their lifecycle.
What "up to 48 hours" actually means
It's the maximum TTL most resolvers will honour, not a clock that starts when you make a change.
In practice, here's what governs how fast each cache flips:
If your record was at TTL 60, every cache anywhere in the world flips to the new value within 60 seconds of its own next query. Felt-time: nearly instant.
If your record was at TTL 86400 (a day), most caches flip within a day of when they last asked — but a cache that asked 23 hours and 59 minutes ago will keep serving the old value for another 24 hours from now. That's where "up to 48 hours" comes from: in the absolute worst case, the last cache flips approximately twice the TTL after your change.
The TTL trick everyone learns once
If you know you're going to change a record, lower the TTL first — wait for the old TTL to expire — then make the change.
Lowering TTL from 86400 to 60 means:
- Now: all caches still hold the old value with up to 24 hours left.
- Within 24 hours: all caches re-ask, get the same record but with TTL 60. Their next expiry is in 60 seconds.
- 24 hours from step 1: every cache anywhere has at most 60 seconds of staleness left.
- Now you change the record. Within 60 seconds, every cache flips.
This is the standard playbook for migrations where downtime matters. Your registrar's UI usually exposes TTL right next to the record value.
What our DNS Propagation tool actually shows you
The DNS Propagation Checker queries four large public resolvers in parallel — Cloudflare, Google, Quad9, AdGuard — and shows what each one currently returns for the record types you ask about.
If all four agree, every major recursive on the public internet probably agrees too — those four together cover a meaningful chunk of global query volume. If one disagrees, you've found a cache that hasn't flipped yet, and you can predict it will catch up within its remaining TTL.
The tool can't show you what your colleague's specific resolver is returning — that's a query you'd run from their machine. But for a global "did the change land yet" check, comparing four big public resolvers is usually decisive.
Things that look like propagation but aren't
The browser's own DNS cache. Chrome and Firefox cache resolver answers separately from the OS. chrome://net-internals/#dns lets you flush it. If you just made a change and one tab won't see it, that's almost always the answer.
The OS resolver cache. ipconfig /flushdns on Windows, sudo killall -HUP mDNSResponder on macOS, systemd-resolve --flush-caches or sudo resolvectl flush-caches on Linux.
A CDN's edge cache. If you're behind Cloudflare or another CDN, the CDN's own DNS resolution at its origin pull layer is a separate cache from the recursive your end-users see. CDNs typically respect TTLs but their cache is its own thing.
Negative caching. If you queried subdomain.example.com before it existed, the resolver may have cached the NXDOMAIN with its own (often longer) TTL. Adding the record after won't be visible until the negative cache expires. RFC 2308 governs this; default is up to 3 hours.
The takeaway
There's no propagation. There's a tree of caches, each one independently flipping when its TTL expires. If you set a low TTL ahead of time, the worst case is roughly 1×TTL. If you didn't, the worst case is roughly 2×TTL.
When in doubt: query the same record from a few different recursive resolvers, compare the answers, and you'll see exactly where in the cache lifecycle each one is.