--- title: DNS propagation is a myth: what's actually happening when your record 'takes 48 hours' description: Nothing propagates. DNS changes don't spread across the internet — caches expire, one resolver at a time, on a timer you set yourself. Once you see it that way, migrations stop being scary: here's the TTL playbook, the myths that refuse to die, and the checks that tell you the truth. canonical: https://watchfor.io/blog/dns-propagation-myths --- # DNS propagation is a myth: what's actually happening when your record 'takes 48 hours' 2026-08-23 · WatchFor Team · Networking · dns, networking, monitoring Nothing propagates. DNS changes don't spread across the internet — caches expire, one resolver at a time, on a timer you set yourself. Once you see it that way, migrations stop being scary: here's the TTL playbook, the myths that refuse to die, and the checks that tell you the truth. 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: 1. **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. 2. **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. 3. **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. 4. **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](/dns-propagation-checker) does exactly this on a world map, and a plain [DNS lookup](/dns-checker) 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](/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. --- Canonical page: https://watchfor.io/blog/dns-propagation-myths · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt