TTL is usually discussed as a performance setting. It is more useful to think of it as the length of time you are committing to live with a mistake, because that is what it controls.
The trade
| Long TTL (hours to a day) | Short TTL (minutes) | |
|---|---|---|
| Query load on your nameservers | Low. | High. |
| Resolution latency for users | Lower — more cache hits. | Slightly higher. |
| Time for a change to take effect | Slow. | Fast. |
| Time to undo a mistake | Slow. This is the cost that matters. | Fast. |
| Resilience if your nameservers go down | Better — cached answers keep working. | Worse — caches empty quickly. |
That last row is the genuine argument for longer TTLs and it is rarely made. If your authoritative servers become unreachable, every resolver holding a valid cached answer continues to serve your users. A long TTL is an outage buffer.
Values that hold up
- 3600 (1 hour) — a sound default for most records. Long enough to be cheap, short enough that a mistake is an hour rather than a day.
- 300 (5 minutes) — during a planned change, and for records that genuinely move, such as dynamic DNS hostnames.
- 86400 (1 day) — for records that essentially never change: NS, MX at a stable provider, a long-lived CAA policy.
- Under 60 — rarely worth it. Many resolvers enforce a floor, so you pay the query load without reliably getting the agility.
Planning a cutover
T-48h Lower TTL on the records being moved to 300.
(Must be at least one CURRENT TTL before the change.)
T-24h Verify the short TTL is being served:
dig +noall +answer A www.example.com
T-0 Make the change.
T+5m Verify against the authoritative servers, then several
public resolvers.
T+24h Raise the TTL back.The step that gets skipped
Lowering the TTL at the same time as making the change achieves nothing for that change. Resolvers holding the old record were told to keep it for the old duration, and they will. The reduction has to lead the change by at least one full old-TTL period, which is why "we will lower the TTL when we do the migration" is a plan with a hole in it.
Verifying properly
Check the authoritative server first — that tells you whether you published what you meant to. Then check public resolvers, which tells you what the world is getting.
# what you published dig +noall +answer @ns1.example.com A www.example.com # what the world sees for r in 1.1.1.1 8.8.8.8 9.9.9.9; do echo "== $r"; dig +noall +answer @$r A www.example.com done
A discrepancy between the two is expected during the TTL window and is a problem afterwards. A discrepancy between your own authoritative servers is always a problem — it means a zone transfer has not happened, and the SOA serial is where to look.