TL;DR
- DNS is heavily cached. After you change a record, old answers can linger until their TTL expires in recursive resolvers, browsers, OS caches, and sometimes CDNs.
- “Propagation” isn’t a magic push; it’s caches aging out plus your DNS provider replicating changes to its anycast edge.
- Lower TTLs before big changes, verify at the authoritative source, and test multiple public resolvers (
1.1.1.1,8.8.8.8,9.9.9.9) to gauge spread. - Nameserver (NS) changes touch the parent zone (the registry) and can take longer than simple A/AAAA/TXT edits.
- Avoid downtime: plan TTL roll‑downs, keep old + new targets serving during the switch, and monitor.
The mental model (60 seconds)
Browser/OS cache → ISP/Recursive resolver cache → Authoritative DNS → (Your zone)
↑ │
└────────── TTL governs reuse ─────────┘
- A query rarely hits your authoritative DNS directly. Most users get answers from recursive caches that honor the TTL they saw earlier.
- Your DNS provider may also replicate changes across its global PoPs; that part is usually fast (seconds), but caches elsewhere still hold the old answer until TTL expiry.
What actually happens when you “change DNS”
- You update a record at your DNS provider.
- The provider updates your zone file and bumps the SOA serial.
- New queries that reach the authoritative will see the new answer immediately.
- Queries that hit caches keep seeing the old answer until TTL (or negative TTL) expires.
Negative caching: If a name didn’t exist (NXDOMAIN), resolvers may cache that non‑existence for the SOA’s negative TTL. Adding the record later may still look “missing” until that cache ages out.
Typical timelines (rules of thumb)
- A/AAAA/CNAME/TXT/MX record edits: visible to fresh resolvers instantly, cached resolvers after their remaining TTL (often 60s–3600s; sometimes longer).
- NS (nameserver) changes at registrar: depends on parent zone TTLs; many TLDs cache NS records for hours to ~48h.
- Glue records (nameserver A/AAAA) and DNSSEC (DS keys): plan extra time; wrong sequencing can cause outages.
Where caching happens (and what you control)
- Authoritative TTL (you set this): tells caches how long to reuse an answer.
- Recursive resolvers (ISPs, public DNS): obey TTL but won’t drop cached data early.
- OS/Browser cache: small per‑host caches may keep answers briefly regardless of TTL.
- CDNs / proxies: not DNS, but can cache HTTP or maintain their own origin address cache—often mistaken for “DNS still propagating”.
Plan a no‑stress change (TTL roll‑down)
- 24–48h before: lower the record’s TTL from, say,
3600to60. - Wait for the old higher TTL to expire everywhere (worst‑case wait = old TTL).
- Make the change (new IP, CNAME target, MX, etc.).
- Verify broadly. If stable, raise TTL back to something sane (e.g.,
300–3600).
For NS changes, lower TTLs on child‑zone NS records before you update the registrar; expect parent zone caches to honor their own TTLs regardless.
Verify correctly (don’t guess)
Check a specific resolver
# Ask Cloudflare’s resolver
dig A example.com @1.1.1.1 +nocmd +noall +answer
# Ask Google’s resolver
dig A example.com @8.8.8.8 +nocmd +noall +answer
# Ask Quad9
dig A example.com @9.9.9.9 +nocmd +noall +answer
Ask the authoritative nameserver directly
# First, discover authoritative NS
dig NS example.com +short
# Then query one of them explicitly
dig A example.com @ns1.yourdns.tld +nocmd +noall +answer
Trace the whole path
dig +trace example.com
Windows / PowerShell equivalents
nslookup -type=A example.com 1.1.1.1
Resolve-DnsName example.com -Server 1.1.1.1 -Type A
Look at the returned TTL to understand how long a cache will keep that answer.
Common scenarios & fixes
“I changed the A record but some users still hit the old IP.”
- Cause: Their resolver cached the old IP until TTL expiry.
- Fix: Wait out the TTL; next time roll down TTL in advance. Keep both origins up during cutover.
“Email bounced after MX change.”
- Cause: Remote MTAs still cached old MX; also, some providers cache target A records aggressively.
- Fix: Lower TTL on MX and target A/AAAA first. Keep old MX online at a higher priority value during transition.
“Swapped nameservers; the domain disappeared briefly.”
- Cause: NS change at registrar + parent zone TTL + missing/incorrect glue or DS (DNSSEC) record.
- Fix: Verify glue/DS first. Change NS only after new provider serves the full zone.
“Propagation checkers show different answers by region.”
- Cause: They’re querying from different recursive resolvers with different cache states.
- Fix: That’s normal. Focus on authoritative answers and watch TTLs drop.
“I flushed my machine but still see old data.”
- Cause: Your OS is clean, but your recursive resolver still holds the old answer.
- Fix: Query another public resolver or wait out the TTL.
Pitfalls & how to avoid them
| Pitfall | Why it hurts | Avoidance | |---|---|---| | High TTL during migrations | Long waits & split‑brain | Roll down TTL before changes | | Only changing CNAME, not its target’s TTL | Target still cached | Lower TTLs on all involved records | | Assuming TTL=0 forces immediate change | Caches may clamp to minimums | Use small but non‑zero TTL (e.g., 60s) | | Breaking NS/DNSSEC/glue order | Domain offline | Stage: publish zone → verify → update DS/glue → change NS | | Blaming DNS for CDN cache | Wrong layer | Purge CDN/origin cache; validate DNS separately |
Quick checklist
- [ ] Lower TTLs 24–48h in advance (e.g., 60s).
- [ ] Make changes; keep old + new serving during cutover.
- [ ] Verify at authoritative NS and multiple public resolvers.
- [ ] Watch TTL values to understand remaining cache time.
- [ ] For NS/DNSSEC/glue, follow the safe order and allow more time.
- [ ] After success, raise TTLs back up.
One‑minute adoption plan
- Identify the records you’ll change and their current TTLs.
- Roll TTLs down; calendar a change window after old TTLs age out.
- Make the change; monitor via
dig @1.1.1.1,@8.8.8.8, and the authoritative NS. - Keep both endpoints healthy during the window; update firewalls/allowlists as needed.
- Raise TTLs, document timings, and note lessons for next time.