TTL: what it controls and what it does not
TTL is the cache lifetime for a record. It shapes how long old values persist after a change, not how fast new ones propagate.
Every DNS record has a TTL, and every TTL-related propagation isn’t working ticket comes back to the same misunderstanding. TTL is the cache lifetime, not a propagation timer.
A short TTL doesn’t make the change happen faster at the authoritative server; it makes resolvers re-query sooner after their current cache expires. Lowering the TTL after a change has been made is too late to help that change. Setting TTL properly before a change is what shapes the propagation experience for users.
What TTL is, in motion
sequenceDiagram
autonumber
participant Auth as Authoritative server
participant Resolver
participant User
User->>Resolver: A record for example.com?
Resolver->>Auth: query
Auth-->>Resolver: 203.0.113.10, TTL 3600
Note over Resolver: caches for 3600 seconds
Resolver-->>User: 203.0.113.10
Note over Auth: You change the A record to 198.51.100.42
User->>Resolver: A record for example.com? (within the TTL)
Resolver-->>User: 203.0.113.10 (stale, from cache)
Note over Resolver: TTL expires
User->>Resolver: A record for example.com?
Resolver->>Auth: query (cache expired)
Auth-->>Resolver: 198.51.100.42, TTL 3600
Resolver-->>User: 198.51.100.42 (now current)
The authoritative server serves the new value the moment you save. Resolvers that had the old value cached continue to serve the old value for up to the TTL of the old record. New resolvers querying for the first time see the new value immediately.
What TTL controls
Two things, exactly:
- How long resolvers cache the record. A resolver receiving TTL 3600 holds for an hour.
- How long after a change it takes for caches to expire. If you change a record whose old TTL was 3600, downstream caches keep returning the old value for up to an hour after the change.
The key insight: TTL controls how long the old value can persist, not how fast the new value propagates.
Common TTL values
| Value | Use case |
|---|---|
| 60 sec | Below most resolver floors; overkill, adds load |
| 300 sec (5 min) | Standard cutover TTL during active migrations |
| 3600 sec (1 hour) | Common operational default; reasonable middle ground |
| 86400 sec (24 hours) | Stable records (MX of a long-stable provider, SOA, NS) |
| 604800 sec (1 week) | Records that essentially never change |
The pre-flight TTL drop
Practice: checking TTL before a cutover
You’re preparing for a mail migration next Thursday. Current MX has a high TTL. Walk through the pre-flight check.
What this is NOT
- “TTL controls propagation.” TTL controls cache lifetime. Propagation is the effect of caches expiring. The TTL that matters for a specific change is the old TTL on the old record.
- “Setting TTL to 1 second means changes are instant.” Most resolvers floor at 30-60 seconds; sub-30s TTLs don’t deliver what they imply, and they put load on the authoritative server.
- “After I set TTL low, the next change will propagate fast.” Only if the low TTL has been in place long enough for downstream caches to have picked it up.
Decision walkthrough
After the cutover, restore TTL to 3600 (or higher) so the authoritative server isn’t fielding queries every 5 minutes for a record that won’t change for months.