Understanding DNS Propagation
4 min read
## Understanding DNS Propagation
You update a DNS record, save it, and wait. Minutes or hours later, some people see the new value while others still see the old one. This is DNS Propagation — the gradual spread of DNS changes across the global network of resolvers and caches.
Understanding propagation helps you plan migrations, set realistic expectations, and avoid emergency troubleshooting during launches.
## Why DNS Changes Are Not Instant
The internet relies on thousands of DNS resolvers operated by ISPs, cloud providers, and organizations worldwide. These resolvers cache answers to reduce load on authoritative nameservers and speed up responses for users.
When you change a DNS record at your provider, only your authoritative nameserver knows the new value immediately. Every cached copy elsewhere — in ISP resolvers, corporate DNS servers, operating system caches — still holds the old value until it expires.
The expiry time is controlled by TTL (Time to Live), a value you set on each DNS record.
## How TTL Controls Propagation
Every DNS record carries a TTL in seconds. When a resolver caches the answer, it stores the TTL along with it. The resolver will not re-query until the TTL expires.
Example: if your A record has `TTL 86400` (24 hours) and you change the IP address, resolvers that cached the old record just before your change will serve the old value for up to 24 hours.
**TTL and propagation time are directly related:**
| TTL Setting | Max Propagation Time |
|-------------|---------------------|
| 300 (5 min) | ~10–15 minutes |
| 3600 (1 hour) | ~1–2 hours |
| 86400 (24 hours) | ~24–48 hours |
The often-cited "48-hour propagation" comes from domains with 24-hour TTLs, plus the fact that some resolvers refresh slightly after TTL expiry.
## Reducing Propagation Time Before a Migration
The best practice for DNS migrations is to **lower TTLs in advance**:
1. At least 24–48 hours before the planned change, lower TTLs on the affected records to 300 seconds (5 minutes)
2. Wait for the old high-TTL cache to expire across resolvers
3. Make the DNS change
4. After the migration is stable (hours or days), raise TTLs back to 3600 or higher
If you lower TTLs and make the change immediately, you gain nothing — resolvers still hold the old value under the old TTL until it expires.
## What Actually Propagates
"Propagation" is a bit of a misnomer. DNS changes do not actively push to every resolver. Instead, each resolver independently re-queries when its cache expires. Propagation is really **cache expiry across the world** — a passive, decentralized process.
The chain of DNS lookups:
1. User's device checks its local OS DNS Cache (TTL)
2. OS cache checks the ISP or configured resolver (e.g. `8.8.8.8`)
3. Resolver checks its own cache
4. If expired, resolver queries the Authoritative DNS Server nameserver
5. Authoritative server returns the current value with the current TTL
Until step 3's cache expires, users see the old value regardless of what you changed on the authoritative server.
## NS Record Propagation (Nameserver Changes)
Changing your nameservers at the registrar is a special case. When you point a domain to new NS records, propagation involves:
1. The registry (e.g. Verisign for `.com`) updating its zone with your new NS records — typically within minutes
2. The old nameserver's NS record TTL expiring on resolvers — can take 24–48 hours
During the NS transition period, some resolvers query the old nameservers and some query the new ones. Keep both nameservers active and serving identical records during the transition.
## Monitoring Propagation
**Online tools:**
- [whatsmydns.net](https://www.whatsmydns.net) — check a record from dozens of global locations simultaneously
- [dnschecker.org](https://dnschecker.org) — similar geographic spread
- Google's [Toolbox DNS check](https://toolbox.googleapps.com/apps/checkmx/) — email-focused
**Command-line queries:**
```bash
# Query Google's public resolver
dig @8.8.8.8 example.com A
# Query Cloudflare's resolver
dig @1.1.1.1 example.com A
# Query your authoritative nameserver directly
dig @ns1.yourprovider.com example.com A
# Check TTL remaining in a cached response
dig example.com A +ttlunits
```
By querying multiple resolvers, you can see which ones have the new value and which are still serving cached data.
## Common Propagation Misconceptions
**"Propagation is stuck."** Propagation is not a process you can unblock. If a resolver still shows old data, it is because the TTL has not expired. The only action is waiting (or flushing caches where you control the resolver).
**"Flushing DNS fixes propagation."** Flushing your local DNS Cache (TTL) (with `sudo dscacheutil -flushcache` on macOS or `ipconfig /flushdns` on Windows) only clears *your device's* cache. It has no effect on upstream resolvers. After flushing locally, your device will query its configured resolver — which may still return cached data if *its* TTL has not expired.
**"48 hours is always the rule."** The 48-hour figure assumes 24-hour TTLs. With 5-minute TTLs, nearly all resolvers see your change within 15 minutes. Modern, well-configured domains with hourly TTLs propagate in 1–2 hours.
## SOA Record and Negative Caching
When a record does not exist, resolvers cache the *absence* too — this is called negative caching. The SOA record contains a `MINIMUM` field that sets the negative cache TTL. This matters if you add a new subdomain: resolvers that recently got a "not found" answer will serve that negative response until the negative TTL expires.
## Best Practices Summary
- Keep production DNS TTLs at 3600 seconds (1 hour) for steady-state
- Lower to 300 seconds 24–48 hours before any planned migration
- Query multiple public resolvers to confirm propagation progress
- Never rely on a single resolver's response to judge global state
- After a migration, raise TTLs back to reduce query load
For migration-specific guidance, see DNS During Domain Migration. To diagnose propagation issues, check DNS Troubleshooting Guide.