How long does DNS propagation actually take?

DNS propagation is not a single time — it's a distribution. For a record with a 300-second (5-minute) TTL, the median user sees the change within 5 minutes. But some resolver populations — especially ISP default resolvers that override TTLs with 24-hour minimums — can take hours or even days. Google Public DNS and Cloudflare 1.1.1.1 honor TTLs strictly and typically propagate within the TTL window. ISP resolvers (Comcast, AT&T, Deutsche Telekom) often ignore short TTLs and impose their own minimum cache durations (1–24 hours). The geographic resolver hierarchy adds another layer: a user in Tokyo querying through a local ISP resolver that forwards to a regional cache may see the old record long after users in Virginia on Google DNS see the new one. For a 300-second TTL record: Google DNS/Cloudflare users see it in under 5 minutes; Quad9/OpenDNS users in 5–15 minutes; ISP resolver users in 1–48 hours depending on the ISP's cache policy. The worst case for global propagation is typically 48 hours — but for 95%+ of users, changes propagate within the TTL window when using public resolvers.

Why do some users see my DNS change immediately while others don't?

The discrepancy comes from the resolver hierarchy. When you change a DNS record at your authoritative nameserver, that change does not 'push' to every resolver — resolvers pull it by making queries when their cached copy expires. Three factors create the time spread: (1) Resolver cache policy — Google DNS and Cloudflare respect your TTL; many ISP resolvers override short TTLs with their own minimum (often 300–3600 seconds for A records, 86400 seconds for NS records). (2) Geographic topology — a resolver in Singapore may cache the record 5 seconds after the resolver in Virginia, starting their TTL countdowns at different times. (3) Recursive resolver chains — when an ISP resolver forwards to an upstream resolver (common in carrier-grade NAT deployments), the cached copy lives at both levels, and the upstream resolver may have its own TTL override policy. The solution: reduce your TTL to 60–300 seconds at least 24 hours before a planned DNS change (so the old TTL expires everywhere), make the change, then restore the TTL after propagation confirms. This 'pre-warming' technique is standard practice for DNS migrations.

Which DNS resolvers propagate changes the fastest?

Google Public DNS (8.8.8.8) and Cloudflare (1.1.1.1) are the fastest — both honor TTLs strictly and query authoritative nameservers directly without upstream forwarding, meaning changes propagate within the TTL window (typically 60–300 seconds for short TTLs). Quad9 (9.9.9.9) is close behind at TTL + 0–5 minutes. OpenDNS (208.67.222.222) honors TTLs but adds a small processing delay (1–3 minutes). ISP default resolvers are the slowest — many ignore TTLs below their configured minimum (often 300–3600 seconds), and some cache negative responses (NXDOMAIN) for up to 4 hours regardless of the SOA negative TTL. The worst offenders among major ISPs: Comcast/Xfinity (minimum 300s, sometimes overrides to 3600s), Deutsche Telekom (minimum 3600s for A records), BT/EE (minimum 900s). For fastest global propagation: use a 60-second TTL, verify with Google DNS and Cloudflare first (they'll show the change within 60 seconds), then check Quad9 and OpenDNS (within 5 minutes), and expect ISP resolver populations to trail by 1–24 hours depending on the ISP.

Does reducing my TTL to 1 second make DNS propagation instant?

No. Even with a TTL of 1 second, real-world propagation has a floor determined by resolver behavior. (1) Not all resolvers honor sub-30-second TTLs — many enforce a minimum of 30–60 seconds regardless of what you set. (2) Query latency — a recursive resolver still needs to traverse the DNS hierarchy to your authoritative nameserver, which takes 20–200ms per cold query. (3) Negative caching — SOA minimum TTL controls how long resolvers cache NXDOMAIN responses; setting a 1-second positive TTL but a 3600-second negative TTL creates asymmetric propagation where the record resolves quickly but 'host not found' errors persist for an hour. (4) DNS query load — a 1-second TTL means every resolver queries your authoritative nameserver every second for every user behind it. At scale this can overwhelm your nameserver. Practical minimum: 30 seconds for critical infrastructure with resilient authoritative DNS, 60–300 seconds for general use.

How do I check DNS propagation globally?

Use multiple vantage points. Command-line: dig +short A example.com @8.8.8.8 (Google), @1.1.1.1 (Cloudflare), @9.9.9.9 (Quad9), @208.67.222.222 (OpenDNS). Web tools: dnschecker.org queries from 30+ locations, whatsmyDNS.net from 20+ locations. API: Google DNS-over-HTTPS (dns.google/resolve?name=example.com&type=A) gives you Google's current cached answer. The key insight: don't just check one resolver. If Google DNS shows the new IP but your ISP's resolver doesn't, the problem is your ISP's cache policy, not your DNS configuration. For migrations: test from the specific geographic regions your users are in — a record that resolves correctly from Virginia may still show the old value from Mumbai because the resolver caches are independent.

DNS Propagation

How Long Until Your DNS Change Goes Live? — Resolver-by-Resolver Timing Model

Published: 2026-07-13 | jslet Research | 9 min read

Executive Summary

You change the A record for api.example.com from 203.0.113.10 to 203.0.113.20. Your browser shows the new IP. The deployment dashboard says green. Then the Slack messages start: "API is down" from Singapore. "Getting connection refused" from Frankfurt. "Works fine here" from Virginia.

This is DNS propagation. It's not a single number. It's a distribution — shaped by your TTL setting, by the cache policies of the 8 major resolver populations between your users and your authoritative nameserver, and by the geographic topology of the DNS hierarchy itself. The user on Google DNS in Virginia sees the change in 60 seconds. The user on a Deutsche Telekom resolver in Berlin might wait 24 hours. Both are correct from their vantage point.

This tool models that distribution. Input your record's TTL and record type, select the resolver populations relevant to your user base, and get the per-resolver propagation time range — with the underlying cache policy data that drives the math. Use it before your next DNS cutover to know exactly which users will see the change when, and which ones need a lower TTL.

Propagation Time Calculator

Model the distribution of propagation times across 8 resolver populations. All calculations client-side — your DNS configuration never leaves your browser.

Record TTL (seconds) Common: 60 (fast cutover), 300 (standard), 3600 (default), 86400 (24h)

Record Type

TTL Reduction Window (did you lower the TTL before the change?)

Estimated Propagation by Resolver

Adjust the TTL slider above to see per-resolver propagation estimates.

The 8 Resolver Populations That Determine Your Propagation Time

DNS propagation is not a network phenomenon — it's a cache invalidation problem. Each resolver population has its own cache policy. Some honor your TTL. Some override it. Some ignore it entirely for certain record types. Understanding who does what is the difference between a 5-minute cutover and a 48-hour outage for half your users.

Tier 1: TTL-Honoring Public Resolvers (Fastest)

Google Public DNS 8.8.8.8 · 8.8.4.4

Cache policy: Strictly honors TTL. No minimum override. No maximum clamp for records with TTL < 6 hours. Authoritative-only resolution — Google DNS does not forward to upstream resolvers, it walks the DNS hierarchy from root to authoritative for every cold query.
Propagation: TTL + 0–60 seconds (cold query traversal time). For a 300s TTL record: 5–6 minutes maximum.
Global anycast: Queries route to the nearest Google edge node, but the cache is shared globally — a user in Tokyo and a user in Virginia querying the same record within the TTL window get the same cached answer.
Market share: ~10% of global DNS queries. Dominant among technically literate users, developers, and Android devices (default on many OEM builds).

Honors TTL Strictly

Cloudflare 1.1.1.1 1.1.1.1 · 1.0.0.1

Cache policy: Strictly honors TTL. Cloudflare's resolver infrastructure is built on the same anycast network as their CDN — queries hit the nearest of 330+ edge locations. Cache is per-edge-location, not global, which means a user in Mumbai may see the cached record expire at a slightly different time than a user in London (the TTL countdown started when each edge independently cached it).
Propagation: TTL + 0–90 seconds (edge location variance).
WARP nuance: Users on Cloudflare WARP (their consumer VPN) use 1.1.1.1 as their resolver by default but with an additional caching layer at the WARP egress point. This can add 30–60 seconds of propagation delay vs native 1.1.1.1 users.

Honors TTL Strictly

Tier 2: Mostly-Honoring Resolvers (Slight Lag)

Quad9 9.9.9.9 · 149.112.112.112

Cache policy: Honors TTL but adds threat-intelligence filtering. Every query passes through Quad9's blocklist (IBM X-Force + 18 other threat feeds). This filtering adds 5–50ms to each cold query but does not affect cache expiration. For hot (cached) queries, the filtering is on the cached answer — no additional latency.
Propagation: TTL + 0–5 minutes. Minimum effective TTL of 30 seconds enforced.
DNSSEC: Quad9 validates DNSSEC by default. If your zone has broken DNSSEC configuration, Quad9 returns SERVFAIL — and caches that SERVFAIL for the negative TTL. This is a common but misdiagnosed cause of "propagation failure."

Honors TTL (min 30s)

OpenDNS / Cisco Umbrella 208.67.222.222 · 208.67.220.220

Cache policy: Honors TTL for most record types. Small processing delay (1–3 minutes) due to their content filtering pipeline. Umbrella (enterprise) users may have additional policy-based cache overrides configured by their admin.
Propagation: TTL + 1–5 minutes.
NXDOMAIN handling: OpenDNS replaces NXDOMAIN with a search results page for non-existent domains on the free tier unless the user opts out. This does not affect propagation of real records but can cause confusion when testing.

Honors TTL (+1–3 min)

Tier 3: ISP Resolvers — The Wild West (Slowest)

Comcast / Xfinity 75.75.75.75 · 75.75.76.76

Cache policy: Enforces a minimum TTL of 300 seconds for A/AAAA records, even if the authoritative nameserver sets a lower value. SOA minimum TTL is respected but with a floor of 600 seconds for negative caching. Comcast's resolver infrastructure is regional (not anycast) — resolvers on the East Coast are independent from West Coast, so propagation is geographic.
Propagation: Max(your TTL, 300s) + 0–15 minutes (regional cache variance).
Market share: ~30 million subscribers. Largest single ISP resolver population in the US.

Overrides TTL < 300s

Deutsche Telekom Varies by region

Cache policy: Enforces a minimum TTL of 3,600 seconds (1 hour) for A/AAAA records. This is the most aggressive override among major ISPs. The Telekom resolver fleet uses a hierarchical caching architecture — edge resolvers forward to regional resolvers which forward to central resolvers. Each tier has its own cache. A record change must expire from all three tiers sequentially.
Propagation: Typically 1–24 hours for A record changes. NS record changes can take 48+ hours.
Impact: This is the primary reason "DNS propagation takes up to 48 hours" persists as industry folklore. For Deutsche Telekom users — ~45 million subscribers across Germany and Central Europe — it genuinely can take that long.

Overrides TTL < 3600s

BT / EE (UK) Varies by region

Cache policy: Minimum TTL of 900 seconds (15 minutes) for A/AAAA records. DNSSEC-validating. Regional cache architecture — independent resolver clusters serving different UK regions.
Propagation: Max(your TTL, 900s) + 0–10 minutes.

Overrides TTL < 900s

General ISP Default Resolvers (Catch-all model)

Cache policy: Most Tier 2/3 ISPs worldwide run BIND or Unbound with default configurations. BIND's default minimum TTL is 300 seconds. Unbound defaults to honoring TTL with no minimum override but applies a 86400-second maximum. However, many ISPs customize these defaults upward to reduce upstream query volume. A safe modeling assumption: ISP resolvers enforce a minimum TTL of 300–900 seconds for A/AAAA records, 3600 seconds for MX and NS records, and 600–3600 seconds for negative caching.
Propagation: Max(your TTL, 300–900s) + 0–30 minutes.

Variable — assume 300–900s min

The DNS Resolver Hierarchy — Why "Propagation" Is a Cache Invalidation Problem

DNS is not a push protocol. When you change a record at your authoritative nameserver, that nameserver does not notify anyone. It waits. Resolvers come to it when their cached copy expires and they need a fresh answer. The time between "you made the change" and "every resolver has the new answer" is the propagation window — and its length is determined entirely by cache policies, not by network physics.

Step 1: Authoritative nameserver update (t=0). Your DNS provider (Route 53, Cloudflare DNS, DNSMadeEasy) updates the zone file and increments the SOA serial. The change is live on the authoritative nameservers. Nothing else has happened yet.

Step 2: Recursive resolver cold query. A user types your domain. Their configured resolver (ISP, Google DNS, etc.) has no cached answer or the cached answer has expired. It starts at the DNS root, follows the delegation chain (.com → example.com → api.example.com), and queries your authoritative nameserver. It gets the new record. TTL countdown starts at this moment — for this resolver only.

Step 3: Cached serving. While the TTL is counting down, the resolver serves the cached answer without querying upstream. Other users behind the same resolver get the same cached answer. If the record was cached before your change (step 0), the resolver continues serving the old value until its cache expires.

Step 4: Cache expiration and refresh. When the TTL expires, the resolver discards the cached record. The next query triggers a fresh lookup — which now gets the new record. Repeat for every independent resolver in your user population.

The key insight: Propagation is the time between steps 1 and 4, summed across all resolver populations. Each resolver's timer started when it last cached the record — not when you made the change. If a resolver cached the old record 30 seconds before your change with a 3600-second TTL, it will serve the old value for 59 minutes and 30 seconds after your change. This is why the "pre-warming" technique works: lower the TTL to 60 seconds at least 24 hours before the change, wait for the old long TTL to expire everywhere, then make the change. Every resolver now has a 60-second stale window, not a 3600-second one.

The Pre-Warming Technique — How to Make DNS Changes Instant for 95% of Users

The standard playbook for a zero-downtime DNS migration:

24+ hours before cutover: Reduce the TTL on the record(s) you plan to change to 60–300 seconds. Wait at least the old TTL duration — if the old TTL was 86400 (24 hours), you wait 24 hours. This ensures every resolver that cached the old record with the old long TTL has expired it and re-cached with the new short TTL.
At cutover time: Make the DNS change. Resolvers with the short TTL will refresh within 60–300 seconds.
After propagation confirms: Restore the TTL to its original value (or a value appropriate for your operational needs). The restored TTL only takes effect after the current short TTL expires.

This technique works because you're not fighting the old cache — you expired it before the change. The only remaining variable is the resolver's minimum TTL policy (if any). On Google DNS and Cloudflare, a 60-second TTL means 60-second propagation. On Comcast, it means 300 seconds (their minimum). On Deutsche Telekom, it means 3600 seconds (their minimum). Pre-warming eliminates the old-cache variable but cannot override ISP minimum TTL policies.

When pre-warming doesn't help: NS record changes (delegation changes). The parent zone's NS records have their own TTLs set by the registry, independent of your zone. Changing nameservers for example.com involves updating the .com zone's NS records — which have a 2-day TTL at the registry level. No amount of pre-warming your own zone can accelerate the registry's NS TTL. Nameserver migrations are inherently 24–48 hour processes.

📜 Copyright & Attribution

Sharing & Reprinting: You may share excerpts (up to 200 words) with a mandatory, do-follow link back to the original article URL. Full reproduction, translation, or adaptation requires prior written permission.

Resolver Data Disclaimer: ISP DNS resolver behaviors described in this article reflect publicly observable cache policies as of July 2026. ISP resolver configurations change without notice. Always test your specific domain's propagation from your actual user locations before and after DNS changes. Contact: research@jslet.com.