DNS TTL explained

The short version

A TTL is expressed in seconds. A value of 300 is five minutes; 3600 is one hour. While the cached answer remains valid, a recursive resolver can return it without asking the authoritative nameserver again.

That caching is good for speed and resilience, but it is also why users can temporarily see different answers after you change a record.

Lowering TTL does not clear old caches

If a resolver cached a record yesterday with a one-hour TTL, changing that record's TTL to five minutes today does not retroactively shorten the copy already sitting in the resolver's cache.

If you are planning an important migration, lower the TTL far enough in advance for old high-TTL copies to expire. After the migration has settled, you can raise it again if a longer cache period suits the service.

Why the TTL you see can count down

A recursive resolver can return the remaining lifetime of its cached answer rather than the original authoritative TTL. If the authoritative record says 3600 seconds and the resolver cached it 20 minutes ago, you might see roughly 2400 seconds remaining.

Different resolvers cache the same record at different times, so their remaining TTLs can differ even when they agree on the answer.

What about missing records?

DNS can also cache negative answers, such as a name that does not exist. The exact negative-cache lifetime is influenced by the zone's SOA data and resolver behaviour. That means creating a previously missing record can still appear delayed to a resolver that recently cached the negative answer.

Choosing a TTL

There is no single best TTL. Frequently changing records can benefit from shorter values, while stable records can often use longer values to reduce query load and improve cache efficiency. The useful choice depends on how quickly you need changes to become visible and how stable the service is.