Skip to content
Webmaster Tools

DNS TTL

What a DNS TTL is, how resolvers count it down, sensible TTL values for A, MX and NS records, how to lower it before a migration, and how to see it with dig.

What it is

A TTL (time to live) is the number of seconds a resolver may cache a DNS record before it must ask the authoritative server again. Every record has one; it's the second column in a zone file. RFC 1035 defines it as a 32-bit value, and RFC 2181 limits it to 2147483647 seconds, though resolvers usually cap what they keep (often at a day or a week).

example.com.      3600  IN  A     203.0.113.10
www.example.com.   300  IN  CNAME example.com.
example.com.     86400  IN  MX    10 mail.example.com.

Here a resolver that fetches the A record keeps it for up to an hour, the CNAME for five minutes and the MX for a day.

How it works

Value Seconds Typical use
60-300 1-5 min Records about to change, failover, load balancers
3600 1 hour A good default for A, AAAA, CNAME and TXT
14400-86400 4-24 hours MX, NS and other records that rarely change
SOA minimum varies How long "doesn't exist" answers are cached (negative caching, RFC 2308)

A recursive resolver stores the record with a countdown. Ask it again 1,000 seconds later and it answers from cache with the remaining TTL (2600 instead of 3600). When the countdown hits zero it fetches a fresh copy. That's why a change isn't seen everywhere at once: each resolver's cache expires on its own schedule, at most one TTL after your change. Browsers, operating systems and some apps (notably the JVM) add their own caches on top.

Changing the TTL doesn't take effect early either: a resolver holding the old record keeps the old TTL too.

Common setups

  • Cloudflare: "Auto" TTL is 300 seconds; proxied (orange-cloud) records always use Auto.
  • Route 53: you set the TTL per record, except alias records, which use the target's.
  • Google Workspace and Microsoft 365 setup guides accept the default TTL (usually an hour) for MX and verification TXT records.

How to check it

Pick a record type in our DNS Lookup to see each answer. With dig, the number before IN is the TTL:

dig example.com A +noall +answer
dig @ns1.example.com example.com A +noall +answer

Ask the authoritative server (the second line) to see the configured TTL; ask a public resolver to see what's left of its cached copy. On Windows, nslookup -debug example.com prints the TTL.

Common mistakes

  • Changing an IP with a 24-hour TTL and expecting it to be live in minutes. Lower the TTL to 300 at least one old TTL before the change, make the change, then raise it again.
  • A TTL of 0 or a few seconds everywhere: more queries, slower page loads, and some resolvers raise it anyway.
  • Forgetting NS records: the TTLs set at the registry for delegation (often 1-2 days) govern name server moves, not your zone's values.
  • Forgetting negative caching: looking up a name before creating it caches "doesn't exist" for the SOA minimum.