TTL, Caching & Propagation
Plan cutovers without surprise downtime.
Learning objectives
- Explain TTL in plain language
- Plan a DNS cutover with minimal downtime
- Predict why “it works on my machine” after a change
TTL = “how long to trust this answer”
Every DNS record has a TTL in seconds. Caching resolvers store the answer until TTL expires. Lower TTL = faster updates visible globally, but more DNS queries.
| TTL | Human | Typical use |
|---|---|---|
| 300 | 5 minutes | Before a planned migration |
| 3600 | 1 hour | Normal production records |
| 86400 | 24 hours | Stable records, rarely changed |
Propagation is not magic — it is cache expiry
When someone says “DNS hasn’t propagated,” they usually mean some resolvers still have the old cached value. There is no single global DNS switch.
Worked example — zero-downtime IP change
Workshop Co. moves their website from 203.0.113.10 to 203.0.113.50:
- Day −2: Lower TTL on
wwwand apex A records to 300 seconds. - Day 0: Bring up the new server; test via
/etc/hostsor direct IP. - Cutover: Change A records to
203.0.113.50. - Wait at least one old TTL cycle (check from multiple networks).
- Day +2: Raise TTL back to 3600 if desired.
Use dig @8.8.8.8 www.workshopco.ca to query a specific resolver. Compare with dig @1.1.1.1. Different answers = different cache states.
Try it yourself
You change an A record at 2:00 PM. Old TTL was 3600. New TTL is 300.
- When is the earliest most resolvers might still return the old IP?
- Why did lowering TTL before the change matter?
Answers
- Up to ~3:00 PM for resolvers that cached right before the change (old 3600s TTL). After lowering TTL beforehand, worst case shrinks to ~5 minutes post-change for resolvers that picked up the 300s record.
- Resolvers that cached the old record with TTL=3600 would hold it an hour unless you waited for that hour to pass after lowering TTL first.
Scenario
You fixed DNS but your colleague still sees the old site on office Wi‑Fi. Your phone on LTE sees the new site. Most likely cause?
Answer
Office recursive resolver still has cached old A record. Wait for TTL or flush if they control that resolver; verify with dig against office DNS vs public 1.1.1.1.