TTL: The Most Important Number You Ignore

Next to every DNS record is a number most people never touch: the TTL. It quietly decides how long every resolver on the planet is allowed to remember your answer — which means it decides whether your next server migration takes thirty seconds or two days. It's the difference between a clean cutover and an afternoon of “it works for me but not for them.”

What TTL actually is

Every DNS record carries a TTL expressed in seconds. When a resolver looks up your record, it keeps the answer in its cache for that many seconds and serves it to everyone who asks in the meantime, without bothering your authoritative nameservers again. When the TTL expires, the next query triggers a fresh lookup.

A TTL of 3600 means “cache this for an hour.” A TTL of 300 means five minutes. 86400 is a full day. That single number is a deal you're striking with the entire internet about how stale your data is allowed to get.

The caching chain

Your record isn't cached in one place — it's cached at every hop between a user and your nameservers, each honouring the TTL independently:

“Propagation” is a myth

People say they're “waiting for DNS to propagate,” as if the new record is being pushed out across the world. It isn't. The moment you save a change, your authoritative nameservers serve the new value to anyone who asks. What you're actually waiting for is the old value to age out of every resolver that cached it before your change — and the longest any of them will hold it is exactly the TTL that was in effect when they cached it. There's no global push, no propagation queue. Just caches counting down.

The migration playbook

This is the whole reason TTL matters operationally. When you know a change is coming — moving to a new host, switching mail providers, repointing an A record — do this:

1. Lower the TTL first. At least a full TTL-length before the change (ideally a day ahead), drop the record's TTL to 300. This itself only takes effect once the old, higher TTL expires — which is why you do it early.
2. Wait out the old TTL. If the record was at 86400, give it a day so every cache has picked up the new 300-second value.
3. Make the change. Now any stale answer can only live five minutes.
4. Verify, then raise it back. Once you're confident, return the TTL to something efficient (3600–86400) so you're not paying for needless queries.

Why not just run everything at TTL 60?

Tempting, but there are real costs to a permanently tiny TTL:

• Query volume. Lower TTL means resolvers ask your nameservers far more often. For a busy domain that's real load (and, on metered authoritative DNS, real money).
• Latency. A cache miss means the user waits for a full recursive lookup before the page even starts loading. Higher TTLs mean more cache hits and snappier first connections.
• Resolver floors. Many big resolvers quietly clamp absurdly low TTLs up to a minimum (often 30–60s anyway), so a TTL of 1 buys you nothing but noise.

The sweet spot for stable records is 3600 (an hour) or higher, dropping to 300 only around planned changes.

Common TTL values

What FatDig shows you

The DNS Records table on the Advanced Dig lists the TTL for every record it finds, right beside the type and value. It's worth a glance before any change: if your A record is sitting at 86400 and you're planning to move hosts tomorrow, that number is telling you to lower it today — otherwise some visitors could keep hitting your old server for a full day after the cutover.