How DNS Propagation Works

DNS propagation is the time it takes for DNS record changes to spread across resolvers worldwide. Learn why propagation isn't instantaneous, how TTL controls it, and practical steps to reduce propagation time before migrations.

DNS propagation is the period of time between when you update a DNS record and when all resolvers worldwide stop serving the old value and start serving the new one.


TL;DR DNS propagation is not a broadcast — DNS changes don’t push out to the world. When you update a DNS record, only your authoritative name server is updated immediately. Resolvers worldwide cache your old record for however long its TTL (Time To Live) says. Until that TTL expires, they keep serving the old value to anyone who asks. A record with TTL 86400 can take up to 24 hours to propagate globally. The fix: lower your TTL to 300 seconds at least 24–48 hours before any planned change, then raise it again after the migration is stable.


What is DNS propagation?

DNS propagation is the time it takes for a DNS record change — made on your authoritative name server — to be reflected across all recursive resolvers globally.

The term “propagation” is slightly misleading. DNS changes don’t actively propagate outward. Instead, resolvers hold cached copies of DNS records for the duration of the record’s TTL. When the TTL expires, the resolver re-queries the authoritative server and gets the updated value.

The authoritative server is updated instantly. The delay is entirely due to cached copies in resolvers worldwide that haven’t expired yet.


Why DNS propagation takes time

When a user queries a domain, they almost never contact your authoritative name server directly. Their DNS resolver (ISP, corporate DNS, 8.8.8.8, 1.1.1.1) caches the answer and serves it from cache for subsequent requests — until the TTL expires.

The propagation timeline:

  1. You update an A record on your authoritative name server. Change is live immediately on the authoritative server.
  2. A resolver that cached the old record will keep serving it until its cached TTL expires.
  3. When the TTL expires, the resolver re-queries the authoritative server and gets the new value.
  4. Different resolvers cached the record at different times — so they expire at different times.
  5. Full propagation = the time until the last resolver’s cached copy has expired.

TTL: the key variable

TTL (Time To Live) is the number of seconds a resolver is allowed to cache a DNS record before re-querying the authoritative server.

TTL valueCache durationPropagation time
300 (5 minutes)5 minutes~5–15 minutes globally
3600 (1 hour)1 hour~1–2 hours globally
86400 (24 hours)24 hoursUp to 48 hours globally
172800 (48 hours)48 hoursUp to 72+ hours globally

A resolver that cached your record 23 hours and 59 minutes ago with TTL 86400 will serve the old value for another 1 minute. A resolver that just cached it will serve the old value for nearly 24 hours. This is why propagation time equals roughly the remaining TTL of the longest-cached copy worldwide.


How to reduce propagation time

Step 1: Lower TTL before the change (24–48 hours in advance)

Change your record’s TTL to 300 seconds (5 minutes) at least 24–48 hours before your planned migration. This gives all existing cached copies time to expire and be replaced with the new low-TTL record.

Before migration (48h early): TTL 86400 → change to TTL 300
Day of migration: Make the record change (A record, nameserver, etc.)
After migration is stable: Raise TTL back to 3600 or 86400

If you skip this step and change the record while the old TTL is still 86400, some resolvers will serve the old value for up to 24 hours.

Step 2: Make the DNS change

Once the low TTL has had time to propagate (24–48 hours), change the actual record value (the IP address, nameserver, or CNAME target). With TTL 300, the new value should be globally visible within 5–15 minutes.

Step 3: Verify across multiple resolvers

Use tools like dnschecker.org or WhatsMyDNS.net to check your record’s value across 20+ resolvers in different countries simultaneously.

Step 4: Raise TTL after stabilization

Once the migration is confirmed stable, raise the TTL back to 3600 or 86400 to reduce load on your authoritative server and improve resolution performance for users.


What affects propagation speed

FactorEffect
TTL valueThe primary control — lower TTL = faster propagation
Resolver caching behaviorSome resolvers respect TTL exactly; some cache slightly longer
ISP resolver refresh ratesCorporate and ISP resolvers may have minimum cache times regardless of TTL
Geographic distributionResolvers in different regions expire at different times
Negative TTL (NXDOMAIN)Failed lookups (domain not found) are also cached — defined in the SOA record

Propagation vs. authoritative change

 Authoritative changePropagation
When it happensInstantly when you save the changeOver TTL expiry period globally
Who sees it firstDirect queries to your authoritative serverNobody until their cached TTL expires
How to verifyQuery your authoritative server directly: dig @ns1.yourns.com example.comUse a multi-location checker tool

To verify the authoritative server has your change immediately, query it directly:

Terminal window
dig @ns1.example.com example.com A

To check what the global resolvers are currently serving:

Terminal window
dig @8.8.8.8 example.com A # Google's resolver
dig @1.1.1.1 example.com A # Cloudflare's resolver

Common propagation problems

ProblemCauseFix
Change not visible after 24+ hoursTTL was high when change was madeWait; check with direct authoritataive query to confirm change is live
Different users see different valuesDifferent resolvers have different cache agesNormal during propagation; resolves when all TTLs expire
Change reverted after seeming to workOld record returned by resolver that re-cached before TTL expiredCheck authoritative server is correctly updated
”Propagation stuck” in one regionRegional ISP resolver ignoring TTLContact ISP; use alternative public resolvers (8.8.8.8, 1.1.1.1)

Frequently asked questions

How long does DNS propagation take? DNS propagation time equals the TTL of the record that was changed. A record with TTL 86400 (24 hours) can take up to 24–48 hours to propagate globally, because some resolvers may have cached the old value near the start of the 24-hour window. A record with TTL 300 (5 minutes) propagates in 5–15 minutes. The fix is to lower TTL before making changes.

Why does DNS propagation take so long? DNS propagation isn’t a broadcast — changes don’t push out to the world. Resolvers cache your DNS records for the TTL duration and re-query the authoritative server only when the cache expires. Different resolvers cached the record at different times, so they expire at different times. The longest-cached copy determines the maximum propagation time.

Can I speed up DNS propagation? Yes — by lowering the TTL before making changes. Set TTL to 300 (5 minutes) at least 24–48 hours before your planned change. This ensures all cached copies expire quickly. For emergency changes when TTL is already high, you can’t do much except wait — or contact major ISPs to manually flush their caches.

Is DNS propagation the same everywhere? No. Different resolvers worldwide have different cached copies at different ages. A resolver that queried your record 5 minutes ago with a 1-hour TTL will see the update in 55 minutes. A resolver that queried 5 minutes after you changed the record sees the new value immediately. “Propagation complete” means all resolvers’ caches have expired and re-fetched.

How do I check DNS propagation? Use an online tool like dnschecker.org or WhatsMyDNS.net — they query your domain from 20+ resolvers in different countries simultaneously and show which ones have the new value. From the command line: dig @8.8.8.8 yourdomain.com A to check Google’s resolver, and dig @ns1.yourdomain.com yourdomain.com A to verify the authoritative server directly.

Does lowering TTL affect performance? A lower TTL means resolvers re-query your authoritative server more frequently, increasing its query load. For high-traffic domains, a TTL of 300 can generate significantly more authoritative queries than 86400. This is why you lower TTL temporarily before migrations, then raise it again after stabilization.

What is negative TTL in DNS? Negative TTL is how long resolvers cache a “domain not found” (NXDOMAIN) response. It’s defined in the SOA record’s minimum TTL field. If you delete a record and then immediately recreate it, resolvers that cached the NXDOMAIN response will keep returning “not found” until the negative TTL expires.

What happens to traffic during DNS propagation? During propagation, different users are routed to different servers depending on which DNS record their resolver is serving. This is why it’s important to keep the old infrastructure running until propagation is complete — users still hitting the old record should be able to reach the old server, while users with the new record reach the new server.

stay up to date

Subscribe to our Newsletter

Get the latest product updates, event highlights, and tech industry insights delivered to your inbox.