The internet's DNS system is a distributed database. When you look up a domain, your operating system queries a recursive resolver (typically operated by your ISP, Google, Cloudflare, or another public provider). That resolver caches the answer for a period defined by the record's TTL (Time to Live). While the cached answer is valid, the resolver returns it without querying the authoritative nameserver. This is why DNS changes don't take effect instantaneously: resolvers worldwide continue serving the old answer until their cached TTL expires.
Key Takeaways
- DNS propagation is not a technical process — it's just cached data expiring at different rates in different resolvers worldwide
- TTL (Time to Live) directly controls propagation speed: a 300-second TTL means changes propagate in ~5 minutes; a 86400-second TTL means up to 24 hours
- Lower your TTL before a planned migration (1 hour or less), then restore it after the change is stable
- Nameserver changes always take longer than A record changes — the registrar's nameserver TTL is typically 24–48 hours and outside your control
- Use the DNS Lookup tool to query multiple resolvers and confirm which ones have picked up your new record
The DNS Resolution Chain
When a browser needs to resolve www.example.com, the process:
- Browser checks its local cache. If the record is cached and not expired, it uses it.
- OS checks its resolver cache (and /etc/hosts on Linux/Mac). Same logic.
- Query goes to the configured recursive resolver (your ISP, 8.8.8.8, 1.1.1.1, etc.).
- If the resolver has a cached answer, it returns it — regardless of what the authoritative nameserver says right now.
- If not cached (or TTL expired), the resolver follows the chain: root servers → TLD servers (.com, .net) → authoritative nameserver for
example.com. - The authoritative nameserver returns the current record with its TTL. The resolver caches it for that TTL duration.
Step 4 is the propagation issue. Different resolvers have different cache states. A resolver that cached your old A record 1 hour ago (with a 24-hour TTL) won't fetch the new record for another 23 hours — regardless of when you made the change.
How TTL Controls Propagation Speed
| TTL value | Propagation window | When to use |
|---|---|---|
| 60–300 seconds (1–5 min) | Near-instant globally | Active migration period; pre-change lowering |
| 3600 seconds (1 hour) | ~1 hour maximum | Production default for most records |
| 21600 seconds (6 hours) | ~6 hours maximum | Stable records that change rarely |
| 86400 seconds (24 hours) | Up to 24 hours | Highly stable records (MX, SPF) |
The key insight: propagation time = the remaining TTL on the cached old record in each resolver at the moment you make the change. If your record has a 3600-second TTL and a resolver cached it 30 minutes ago, it will serve the old answer for another 30 minutes.
This means the propagation time is bounded by the TTL in effect before you make the change — not the TTL you set on the new record. Setting your new record's TTL to 60 seconds doesn't help if the old record's TTL was 86400.
The Pre-Migration TTL Reduction Strategy
The standard approach for zero-downtime DNS migrations:
- 24–48 hours before the migration: Lower the TTL on the records you'll be changing to 300 seconds (5 minutes) or less. Wait for the old TTL to expire everywhere.
- At migration time: Make the DNS change. Because the TTL is now 300 seconds, most resolvers pick up the new record within 5 minutes.
- After the migration is stable: Raise the TTL back to a production value (3600 or higher).
Skipping step 1 — going straight to a change with a high TTL — means you might have users hitting the old server for up to 24 hours after the migration.
Nameserver Changes vs Record Changes
A critical distinction: updating an A record at your existing nameserver is different from changing nameservers entirely.
A record changes (same nameserver): Propagation is controlled entirely by your record's TTL. With a TTL of 300 seconds, changes propagate globally in minutes.
Nameserver changes (pointing the domain at a new DNS provider): The nameserver records (NS records) are stored at the TLD registry (.com, .net, etc.), not at your nameserver. Their TTL is typically 24–48 hours and is set by the registry — you can't change it. Even if your new nameserver has all records ready instantly, it takes 24–48 hours for most resolvers to see the new nameservers, because they query the TLD registry for NS records.
This is why "it can take up to 48 hours" is the common advice — it applies specifically to nameserver migrations, not to simple record changes.
How to Check Propagation Status
During a migration, you want to know which resolvers have picked up the new record and which are still returning the old one. Options:
Command line (dig). Specify a resolver explicitly to check what it returns:
dig @8.8.8.8 example.com A # Google's resolver
dig @1.1.1.1 example.com A # Cloudflare's resolver
dig @208.67.222.222 example.com A # OpenDNS resolverIf these return different IP addresses, propagation is still in progress — different resolvers are serving different answers.
ByteWaveNetwork DNS Lookup. Queries the authoritative nameservers directly and returns the current record values — bypassing resolver caches. Useful to confirm your new record is live at the authoritative source before propagation completes.
Global propagation checkers. Services like dnschecker.org query resolvers in multiple countries and report whether each sees the old or new value — useful for confirming global propagation completion.
Query DNS Records Directly
Free, no signup. The DNS Lookup tool queries authoritative nameservers for any record type (A, AAAA, MX, TXT, NS, CNAME) and shows current values with TTLs.
Try DNS Lookup Free →Affiliate disclosure: Some links on this page may be affiliate links. We only mention tools we've personally used and have an honest opinion about. Affiliate revenue helps keep ByteWaveNetwork's tools free and maintained. We are not paid by any of the tools compared in this article for favorable coverage.