DNS records don't "propagate" in the sense of a broadcast spreading across the internet. Your authoritative server has the new record the moment you save the change. Every resolver that cached the old record will keep returning it until the cache entry expires. What feels like propagation delay is actually cached data aging out in many places at once.
TTL is the only number that matters
Every DNS record has a TTL (Time To Live), measured in seconds. When a resolver fetches a record, it keeps the answer for that many seconds before asking the authoritative server again. Typical TTLs:
| TTL | Practical meaning | Common use |
|---|---|---|
| 60–300s | 1–5 minute cache | Production services that need fast failover |
| 1800s (30 min) | Half-hour cache | Balanced default |
| 3600s (1h) | One-hour cache | Modest sites, medium traffic |
| 86400s (24h) | One-day cache | Static infrastructure, cost-sensitive |
| 172800s (48h) | Two-day cache | Registrar-bundled DNS defaults — rarely ideal |
The "48 hours" figure people quote for DNS propagation comes from the default TTL at many registrar-bundled DNS providers. Lower the TTL and propagation is measured in minutes, not days.
Why different people see different answers
When you change a record, three populations of resolvers exist:
- Those that never cached the old value. They'll hit your authoritative server and get the new record on first query.
- Those with a fresh cache of the old value. They'll keep returning the old record for up to
TTLseconds. - Those with no cache because the TTL already expired. Same as group 1.
Since different resolvers cached the old record at different moments, their expiry clocks are staggered across the TTL window. That's why a change "propagates" over a window equal to the TTL, not instantly.
The CDN edge-caching layer on top
Most modern sites sit behind a CDN (Cloudflare, Fastly, CloudFront). The CDN operates its own DNS layer: edge POPs cache your records independently, subject to their own refresh rates. A DNS change on your side may take the CDN's edge cache window to propagate even after your TTL elapses.
Cloudflare's edge DNS refresh is ~30 seconds. Route 53 is effectively TTL-bound. CloudFront behavior varies by distribution config.
Checking propagation in real time
Rather than waiting and guessing, probe the new hostname from multiple regions simultaneously. isitdown.io probes from US East, US West, Europe, and Asia in parallel — if three regions resolve to your new IP and one resolves to the old, you can watch the propagation finish in real time instead of waiting out a generic "48 hours". See multi-region website checks for the probe architecture.
Lowering TTL before a migration
The standard pre-migration dance:
- At least
old_TTLhours before the migration, lower the TTL to 60–300s on the records you'll change. - Wait for the old TTL to fully elapse. (Otherwise the 60s TTL itself gets cached under the 3600s TTL.)
- Make the DNS change. Propagation now completes in 60–300s instead of hours.
- After you're confident the new record is stable, raise the TTL back up.
This is boring, unglamorous, and almost never skipped by production teams because skipping it causes the "why did our DNS change take 4 hours instead of 5 minutes" incident.
What you can't control
- ISP-level DNS caches with custom policies. Some ISPs override TTLs on their recursive resolvers, caching more aggressively to save upstream bandwidth. You can't make these honor short TTLs; users on those ISPs may see the old record for much longer than your TTL suggests.
- Browser-level DNS caches. Chrome and Firefox maintain process-level DNS caches, often for a few minutes, on top of the OS resolver. A hard reload usually doesn't bypass this.
- OS-level resolver caches. macOS and Windows cache aggressively. A flush-dns command forces a refresh — see the down-for-everyone diagnostic for the exact commands per OS.
FAQ
What's the fastest a DNS change can propagate?
If your TTL was 60 seconds at the time of the change, propagation finishes in 60 seconds plus any CDN / edge caching (typically another 30–60 seconds).
Does DNSSEC slow propagation?
Not meaningfully. DNSSEC adds signature validation but doesn't change the TTL-based cache model. DNSSEC failures can cause resolution failures that look like propagation problems but are actually signature validation issues.
Why do tools like whatsmydns show inconsistent results?
Those tools query a fixed set of public resolvers. Different resolvers cache records independently, so some will have the new record while others still have the old — exactly the expected behavior during a propagation window.
Do all record types propagate at the same speed?
Yes — the TTL mechanism is uniform across A, AAAA, CNAME, TXT, MX, and others. Compound changes (CNAME chains, NS delegations) involve multiple lookups, each subject to its own cache, so they can take longer to appear fully consistent.