Every tutorial says “wait 24 to 48 hours for DNS to propagate.” As of June 2026 that is almost always wrong for the thing people actually do most: editing a record on a domain that already works. Cloudflare, Route 53, NS1, and Google Cloud DNS push edits to their own edge in well under five minutes. What you then wait on is not “propagation” — it is the leftover TTL on whatever resolver cached the old value. If your record still won’t resolve 30 minutes after an edit, you have a misconfiguration, not a propagation problem, and this article shows you how to prove it in a few dig commands.
TL;DR — realistic timelines (as of June 2026)
| Change you made | Realistic wait | Hard upper bound |
|---|---|---|
| Edit an existing A / CNAME / TXT record | Seconds to a few minutes | The old record’s TTL (often 300–3600s) |
| Cloudflare proxied record (orange cloud) | Under 2 minutes typically | 300s (Cloudflare’s fixed proxied TTL) |
| Lower TTL, then edit 24h later | 1× your new TTL | New TTL (e.g. 300s) |
| Point an existing domain at new nameservers | A few hours | ~24h (ICANN registry SLA) |
| Brand-new domain, first nameservers | 30 min to a few hours | ~24h |
The single biggest lever is the TTL of the record you are replacing. You cannot make a cached resolver drop a value early; you can only have set a short TTL before the change. Everything below is about telling cache lag apart from real breakage.
Why “propagation” is the wrong word
There is no global push that fans your record out to the whole internet. Authoritative nameservers just answer queries with your record plus a TTL. A resolver (your ISP’s, 1.1.1.1, your laptop) caches that answer and reuses it until the TTL counts down to zero, then re-queries. So the longest anyone can be stuck on a stale value is the TTL that was live before your edit. With modern providers defaulting to 300-second TTLs, that ceiling is five minutes, not two days.
The famous 24–48 hours only applies to one case: changing which nameservers are authoritative for the domain. That edit lives at the registry, and ICANN requires registries to process it within 24 hours. In practice .com and .net usually push it in a few hours.
How to tell cache lag from a real problem
You probably have a cache-lag situation (just wait) if:
- The domain works for you but not for a friend in another country, or vice versa.
- A checker like whatsmydns.net shows the new value in some regions and the old value in others.
dig +short yoursite.comreturns the new IP from one resolver and the old IP from another.
You probably have a misconfiguration (stop waiting, go fix it) if:
- Every public resolver still returns the old value 30+ minutes after the edit.
dig NS yoursite.comshows nameservers you are not editing.- Your host dashboard says “pending verification” but
digshows the verification record is already correct.
Step by step
-
Note the exact time you made the change. The clock starts there, not when you noticed something was off.
-
Read the old TTL — that’s your worst case.
digprints it as the number before the record type:
dig yoursite.com A
# ;; ANSWER SECTION:
# yoursite.com. 3600 IN A 151.101.1.195
# ^^^^
# TTL in seconds — the old value can stay cached this long- Run
digtwice and watch the TTL count down — this is the trick most people miss. If the number drops on the second query, you are reading a cached answer and the countdown tells you exactly how much longer the stale value lives. If it stays identical, you are hitting an authoritative server directly (which always returns the full TTL):
dig +noall +answer yoursite.com A
# yoursite.com. 287 IN A 151.101.1.195 <- 287s left on this cache
sleep 5
dig +noall +answer yoursite.com A
# yoursite.com. 282 IN A 151.101.1.195 <- counting down, so it IS cached- Compare your resolver against public ones. If
+shortagrees across all three, your local view is fully updated:
dig +short yoursite.com # your local resolver
# 76.76.21.21
dig +short @1.1.1.1 yoursite.com # Cloudflare public resolver
# 76.76.21.21
dig +short @8.8.8.8 yoursite.com # Google public resolver
# 76.76.21.21- Confirm which nameservers actually answer for the domain. The number-one cause of “my edits do nothing” is editing the zone at your registrar while traffic is served by Cloudflare or Route 53:
dig NS yoursite.com +short
# adi.ns.cloudflare.com.
# kim.ns.cloudflare.com.
# -> edit the zone in Cloudflare's dashboard, NOT at your registrar-
Run a multi-region check at whatsmydns.net or dnschecker.org. Each row is one global resolver. Count the red dots; don’t just scan for green. These tools query each resolver fresh, so a region still red after the TTL window is suspicious.
-
If the host says “pending verification,” check what it’s actually looking for. When
digalready returns the expected value, the lag is on the host’s side, not DNS:
# Confirm the exact record the host wants (Vercel example)
dig +short TXT _vercel.yoursite.com
# "vc-domain-verify=yoursite.com,abc123"
# Or confirm an A-record / CDN endpoint is live
curl -sI https://yoursite.com | head -3If the record is correct, click “re-check” / “refresh” in the host dashboard instead of waiting.
- New domain or nameserver swap? This is the genuinely slow case. Verify the registry has accepted your nameservers:
whois yoursite.com | grep -i 'name server'
# Name Server: ADI.NS.CLOUDFLARE.COM
# Name Server: KIM.NS.CLOUDFLARE.COMIf whois still shows the old nameservers, the registry has not processed the change yet — that’s the up-to-24-hour wait, and nothing you do speeds it up.
- Flush your own cache only when just your machine is stuck:
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Linux (systemd-resolved)
sudo resolvectl flush-caches
# Windows (Admin PowerShell)
ipconfig /flushdnsPlan ahead: lower TTL before a migration
The clean way to avoid any perceived “propagation” wait is to drop the TTL before you cut over:
- 24–48 hours before the migration, set the record’s TTL to 300 (or as low as your provider allows — Cloudflare’s minimum for unproxied records is 60s).
- Wait for the old high TTL to fully age out, so resolvers are now caching for only 300s.
- Make the real change. Resolvers pick it up within one short TTL.
- Once the new target is stable, raise the TTL back to 3600 or 86400 to cut query volume.
Cloudflare proxied (orange-cloud) records are a special case: their TTL is fixed at 300s (“Auto”) and you cannot lower it, which is fine because the edge updates within a couple of minutes anyway.
Common pitfalls
- Editing at the registrar when nameservers point at Cloudflare. Cloudflare ignores the registrar zone entirely; your edits go nowhere. Run
dig NSfirst. - Not lowering TTL before a planned migration. A 86400 TTL means a full day of stale caching for some resolvers.
- Trusting your browser. Browsers and the OS cache DNS aggressively. Flush DNS or test in a private window before concluding anything.
- Assuming every host delay is DNS. Often the record is fine and the host is mid-SSL-issuance or running its own domain-verification poll on its own clock.
- Expecting a brand-new domain to work in 60 seconds. First-time registry propagation is the real slow path — 30 minutes to a few hours is normal.
FAQ
- Is “24 to 48 hours” ever true?: Only when you change a domain’s nameservers (especially a brand-new domain). For editing records on a domain that already resolves, expect minutes, bounded by the old record’s TTL.
- How do I know if I’m seeing a cached value or the live one?: Run
dig +noall +answer yoursite.comtwice a few seconds apart. If the TTL number drops, you’re reading a cache and the number is the seconds left until it refreshes. - Can I force a change to propagate faster?: No. You cannot evict a value from someone else’s resolver early. The only lever is having set a low TTL before the change. You can flush your own machine’s cache, but not the global internet’s.
- Why does it show in one country but not another?: Different resolvers cached the old value at different moments, so their TTL countdowns end at different times. They all converge once the longest old TTL expires.
- Should I keep TTL low forever?: No. Low TTL means many more DNS lookups. After a migration is stable, raise it back to 3600 or 86400.