You changed a DNS record… but some people still see the old site. Or your SSL certificate fails only in certain regions. This is usually “DNS propagation,” but the real mechanism is caching—and the most important setting is TTL (Time To Live).
What “DNS propagation” really means
DNS is distributed. Your authoritative DNS provider publishes records, but user devices usually ask a recursive resolver (often your ISP, Google DNS, Cloudflare, or your company). Resolvers cache answers so they don’t have to ask the authoritative servers every time.
What is TTL?
TTL (Time To Live) is the cache lifetime (in seconds) for a DNS answer. If a record has TTL 3600, a resolver can reuse the cached answer for up to an hour before checking again.
TTL example
- You change an A record at 12:00
- A resolver cached the old record at 11:30 with TTL 3600
- That resolver may keep serving the old record until 12:30
Why DNS changes look inconsistent
- Different resolvers have different cache states.
- Device caches (OS/browser) may store results briefly.
- CDNs may have their own logic depending on record type.
- Negative caching can cache “does not exist” (NXDOMAIN).
How to reduce downtime during DNS changes
- Lower TTL before a planned migration (e.g., 300 seconds).
- Wait at least one old TTL period after lowering it.
- Make the change (A/AAAA/CNAME), then monitor.
- After stable, raise TTL again if you prefer.
How to confirm you’re seeing the new record
Use DNS queries from multiple networks/resolvers. On this site, start with DNS Lookup and check the exact record type you changed (A, AAAA, CNAME, TXT, MX).
Related troubleshooting
- If HTTPS is failing after a change: SSL Checker
- Want privacy? Learn about DNS leaks: DNS/WebRTC/IPv6 Leaks
- Need IP basics: Public vs Private IP