DNS TTL, Set Right

What TTL Controls and Common Values

Every DNS record carries a TTL value, defined in RFC 1035 as a 32-bit integer representing seconds. When a resolver fetches your A record with a TTL of 3600, it caches that answer for one hour. During that hour, every visitor whose resolver used the same cache gets the stored answer without contacting your nameserver again. After the TTL expires, the next query triggers a fresh lookup.

Common defaults cluster around a few values. Many providers set 300 seconds (five minutes) for records that change often and 86400 seconds (24 hours) for stable records. The SOA record's minimum field acts as a floor — resolvers will not cache below it. In practice, 3600 (one hour) is a reasonable all-purpose setting: fast enough for routine changes, high enough to avoid unnecessary query load on your nameservers.

When to Lower or Raise Your TTL

Lower your TTL before you make a change, not at the same time. If your TTL is 86400 and you change your A record, some resolvers will serve the old address for up to 24 hours. The standard approach is to reduce the TTL to 300 seconds at least 24 hours ahead of the planned change, make the switch, confirm it works, and then raise the TTL back once the new record is stable.

Raise your TTL when your records are stable and you want to reduce DNS query volume. Higher TTLs also provide mild resilience: if your nameserver goes temporarily offline, cached records continue serving visitors until the TTL expires.

The calculator on this page lets you enter your current TTL and planned change date, then tells you exactly when to lower the value and when it is safe to restore it. That timing removes the guesswork from migrations and hosting changes.

A TTL of zero is valid but tells resolvers not to cache the record at all. This is useful during active troubleshooting but creates high query volume and should not be left as a permanent setting.