TTL in DNS explained: what that number really does

Next to every DNS record sits a small number labelled TTL. Most people leave it at the default and never think about it — which is fine until the day you need a change to take effect quickly. Understanding TTL turns DNS migrations from stressful to routine.

What TTL means

TTL stands for *time to live*, and it's measured in seconds. It tells any resolver that caches your record how long it may reuse that answer before checking with your authoritative nameserver again.

Type: A
Name: @
Value: 203.0.113.10
TTL: 3600

A TTL of 3600 means "you can trust this answer for one hour." After that, the resolver asks again.

The core trade-off

TTL is a balance between speed of change and efficiency:

• Low TTL (e.g. 300 = 5 minutes): changes take effect quickly, but resolvers ask more often, adding a little lookup traffic and latency.
• High TTL (e.g. 86400 = 24 hours): very efficient and fast for visitors, but any change you make lingers in caches for up to a day.

Common TTL values

• 300 (5 min) — for records you're about to change or that fail over.
• 3600 (1 hour) — a sensible everyday default for most records.
• 86400 (24 hours) — for records that essentially never change, like a stable MX or a long-lived A record.

The migration playbook

This is where TTL earns its keep. Say you're moving your site to a new server next week:

1. A few days before, lower the record's TTL to 300.
2. Wait for the old, higher TTL to fully expire so caches pick up the new low value.
3. On migration day, change the record. Because the TTL is now 300, the switch propagates in about five minutes.
4. Afterward, raise the TTL back to 3600 or higher for efficiency.

Plan the TTL drop in advance and a server move becomes a near-instant cutover instead of an anxious day of waiting.

TTL and troubleshooting

When a change "isn't working," TTL is usually the answer. If you set a record's TTL to 3600 and then edit it, expect up to an hour before every resolver catches up. Check what a resolver currently sees:

dig example.com +short
dig example.com +noall +answer

The second command shows the record *with* its remaining TTL, counting down — handy for knowing how much longer a cached answer will linger.

A subtle gotcha

Lowering a TTL doesn't take effect instantly either. Resolvers that already cached the record at the *old* high TTL will keep it until that expires. That's why you lower the TTL *ahead* of the change, not at the same moment — you have to give the old value time to age out first.

The short version

• TTL is how long resolvers cache a record, in seconds.
• Default to 3600 for most records.
• Drop to 300 a few days before a planned change, then raise it again after.
• When a change seems stuck, it's almost always TTL caching, not a real failure.

In Nxeon's DNS panel you can set the TTL per record, so you can pre-stage a low TTL before a migration and cut over cleanly when the time comes.