Ask why a DNS change isn't visible yet and someone will say it: "it's still propagating — can take 24 to 48 hours." It's the most repeated sentence in DNS, and it paints a picture of your record slowly rippling out across the internet, server by server, on a schedule nobody controls.
That picture is wrong in every detail. Nothing propagates. Your change was live globally the moment your authoritative nameserver saved it. What you're waiting for is something much more boring and much more controllable: caches expiring — thousands of independent resolvers, each holding the old answer until its own countdown hits zero.
The countdown is the TTL, and you set it. Which means "propagation time" isn't weather — it's a parameter.
The myths, one by one
Myth 1: "DNS takes 24–48 hours." A record with a 300-second TTL is fully refreshed everywhere in five minutes — every resolver that cached the old answer discards it within 300 seconds of caching it. The 48-hour figure survives from an era of day-long default TTLs, plus one real case it still applies to: changing nameservers, because the NS/DS records at your registrar's parent zone carry their own long TTLs (often 24–48h) that you don't control. Changing an A record ≠ changing nameservers. The first is minutes; the second genuinely deserves the scary number.
Myth 2: "The change spreads from server to server." Resolvers never talk to each other. Each one independently asks your authoritative server when — and only when — its own cache entry dies. There's no ripple, no propagation wave, no order. That's also why your phone sees the new site while your laptop shows the old one: two different resolvers, two different countdowns.
Myth 3: "Flushing my DNS fixes it for everyone." ipconfig /flushdns clears your machine's cache. Your ISP's resolver, your office router, Google's 8.8.8.8 — all still counting down. Flushing locally is how you check sooner; it changes nothing for users.
Myth 4: "TTL 0 means instant changes for free." Two problems. Some resolvers refuse to honor very low TTLs and silently clamp them upward (common floors: 30–300s), so you don't reliably get what you asked for. And every cache miss is a round trip to your authoritative server — TTL is also your protection against resolver latency and your authoritative provider's outage. A record at TTL 30 is re-resolved constantly; if your DNS provider blips for two minutes, users feel it immediately. At TTL 3600, most of them ride it out on cache.
Myth 5: "It's done — I checked and it works for me." You checked one resolver: yours. The honest question is "what fraction of the world's resolvers still hold the old answer?" — which is only answerable by querying many of them, from many places.
The negative cache — the trap nobody warns you about
Here's the one that burns people: resolvers cache failures too. If you query a name before creating the record — easy to do when testing — resolvers cache the NXDOMAIN ("doesn't exist") answer. How long? Not your record's TTL (there isn't one yet), but the negative TTL derived from your zone's SOA record — often much longer than you'd guess.
So the sequence "test the URL → see it fail → create the record → test again" can leave you staring at a failure that persists long after the record exists. Create first, query second — and if you're bitten, that's the rare case where testing against a different resolver (dig @1.1.1.1) instantly shows the truth.
The migration playbook
Since TTL is a parameter, a zero-drama DNS cutover is just scheduling:
- Days before: lower the TTL of the records you'll change — from 3600/86400 down to 300. Crucially, wait at least one old TTL after lowering: caches holding "3600" keep it for up to an hour regardless of what you've changed since.
- Migration moment: update the record. Within ~5 minutes, effectively every resolver has the new answer. Keep the old backend running through this window — traffic arrives at both.
- After confirming: raise the TTL back up (3600+). Low TTLs are a migration tool, not a lifestyle — the cache is what makes DNS fast and resilient.
- Nameserver changes: treat separately. Keep the zone data identical on old and new nameservers during the transition, because you can't control when each resolver switches — with identical data, it doesn't matter.
Watching it actually happen
Two kinds of visibility turn "I think it worked" into "it worked":
- A propagation check across many resolvers shows the old/new answer split around the world in real time — the honest version of myth 5. Our free DNS propagation checker does exactly this on a world map, and a plain DNS lookup against a specific resolver settles any single-resolver dispute.
- A DNS monitor with expected records keeps watching after you've moved on: it asserts that a name returns the values you intend, and alerts with the exact diff when the answer changes — catching the expired domain, the botched zone edit by a teammate, or the hijacked record you'd otherwise learn about from users. That's DNS monitoring — set the assertion once, at migration time, and it guards the record forever.
The next time someone shrugs "it's propagating," you know the real story: a fleet of countdown timers you configured yourself, expiring on schedule. Set them short before you need speed, set them long when you need resilience — and check many resolvers, not one, before declaring victory.