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:
- You update an A record on your authoritative name server. Change is live immediately on the authoritative server.
- A resolver that cached the old record will keep serving it until its cached TTL expires.
- When the TTL expires, the resolver re-queries the authoritative server and gets the new value.
- Different resolvers cached the record at different times — so they expire at different times.
- 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 value | Cache duration | Propagation time |
|---|---|---|
| 300 (5 minutes) | 5 minutes | ~5–15 minutes globally |
| 3600 (1 hour) | 1 hour | ~1–2 hours globally |
| 86400 (24 hours) | 24 hours | Up to 48 hours globally |
| 172800 (48 hours) | 48 hours | Up 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 300Day of migration: Make the record change (A record, nameserver, etc.)After migration is stable: Raise TTL back to 3600 or 86400If 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
| Factor | Effect |
|---|---|
| TTL value | The primary control — lower TTL = faster propagation |
| Resolver caching behavior | Some resolvers respect TTL exactly; some cache slightly longer |
| ISP resolver refresh rates | Corporate and ISP resolvers may have minimum cache times regardless of TTL |
| Geographic distribution | Resolvers 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 change | Propagation | |
|---|---|---|
| When it happens | Instantly when you save the change | Over TTL expiry period globally |
| Who sees it first | Direct queries to your authoritative server | Nobody until their cached TTL expires |
| How to verify | Query your authoritative server directly: dig @ns1.yourns.com example.com | Use a multi-location checker tool |
To verify the authoritative server has your change immediately, query it directly:
dig @ns1.example.com example.com ATo check what the global resolvers are currently serving:
dig @8.8.8.8 example.com A # Google's resolverdig @1.1.1.1 example.com A # Cloudflare's resolverCommon propagation problems
| Problem | Cause | Fix |
|---|---|---|
| Change not visible after 24+ hours | TTL was high when change was made | Wait; check with direct authoritataive query to confirm change is live |
| Different users see different values | Different resolvers have different cache ages | Normal during propagation; resolves when all TTLs expire |
| Change reverted after seeming to work | Old record returned by resolver that re-cached before TTL expired | Check authoritative server is correctly updated |
| ”Propagation stuck” in one region | Regional ISP resolver ignoring TTL | Contact 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.