DNS TTL and Propagation Explained
dns ttl explained · dns propagation time · how long dns changes take
What DNS TTL means, realistic propagation timelines, lowering TTL before migrations, and verifying updates with DNS Checker vs propagation maps.
By DN01 Network Team
TTL (Time To Live) tells resolvers how long they may cache an answer. DNS propagation is not instant teleportation — it is old caches expiring and new queries picking up updated authoritative data.
DN01 DNS Checker shows current answers from our resolver path — ideal for confirming your change published. Regional propagation maps compare many resolvers worldwide over time; use both mindsets during cutovers.
Operators who skip the low-TTL planning step often open «DNS is broken» tickets when the authoritative zone is already correct — propagation delay is the real culprit.
Planning a low-TTL window
Drop TTL to 300 seconds 24–48 hours before a change on stable records. Make the change at authoritative DNS. Verify with DNS Checker. Raise TTL again after stability returns.
Some registrars ignore low TTL minimums — read their docs. SOA refresh/retry timers matter for zone transfers but not public resolver caches the same way TTL does.
Apply TTL drops to every record type you plan to change (A, MX, TXT) — lowering only A while MX stays at 86400 leaves mail routing on stale caches longer than web.
Why different tools show different answers
Recursive resolvers cache independently. Your laptop, office DNS, and 8.8.8.8 may disagree until TTLs expire. Authoritative NS should agree immediately — query them with DIG @ns1.example.com if in doubt.
Changing nameservers adds registrar glue propagation on top of record TTL — allow up to 48 hours for full global convergence even with low TTL.
Corporate DNS forwarders may cache longer than public resolvers — test from the DNS Checker (external path) when internal and external users report different behavior.
TTL values by scenario
Steady production: 3600–86400 seconds on stable records reduces query load. Pre-migration window: 300–600 seconds on records you will edit. Emergency rollback: lowest allowed TTL, then revert record values and wait one full prior-TTL cycle.
Very low TTL (60s) increases query volume and can trigger rate limits on some DNS APIs — balance speed against provider quotas.
After nameserver migration, TTL on individual records matters only once the world queries the new NS set — confirm registrar delegation first with WHOIS and DIG type NS.
Verification during propagation
Run the DNS Checker immediately after publishing at authoritative DNS — if answers are still wrong there, propagation is not the problem. If authoritative is correct but recursive is stale, wait TTL and re-test.
Log query time and TTL in incident tickets — «still old after 5 minutes» with TTL 3600 is expected; «still old after 2 hours» with TTL 300 warrants escalation.
Use DIG against each authoritative nameserver when siblings disagree — one stale secondary NS can serve mixed answers until SOA serial and zone transfer catch up.
Frequently asked questions
- Is propagation the same as TTL?
Related but not identical. TTL drives cache expiry; propagation describes the global convergence as caches refresh.
- Can I flush Google DNS cache?
Public resolvers do not offer per-user flush. Wait for TTL or query authoritative NS directly.
- What TTL do CDNs use?
Often low for orange-cloud proxied names; origin may differ. Check both in DNS Checker when debugging.
- Does lowering TTL speed up nameserver changes?
It helps record updates after NS cutover; registrar NS glue still has its own convergence timeline.
- What is a safe TTL for email records?
Match web TTL strategy — lower MX/TXT before mail migrations, then restore higher TTL after validation.