TTLs and caching

Every DNS answer carries a time-to-live (TTL) in seconds. It tells resolvers how long they may reuse the answer without asking again. A TTL is a trade-off. A long TTL reduces load on authoritative servers and makes lookups faster. A short TTL lets you change where a name points, and users see the change sooner.

A TTL is a limit on staleness, not a promise. Once you change a record, the old answer keeps circulating until every cache holding it expires.

Walking through it

Suppose api.example.com points at an old load balancer with a TTL of 3600 seconds (one hour). You cut over to a new address. Here is what happens:

1. The authoritative server returns the new address immediately.
2. Resolvers that cached the old answer a minute before the change keep returning it for up to an hour.
3. Resolvers that looked it up later, after the old answer expired, get the new address.

So the worst case for users is the old TTL, measured from the last lookup before your change. A resolver that cached the record one second before the change still serves the old address for a full hour.

change time        T = 0
last lookup before T = T - 1 s   (cached with TTL 3600)
worst-case cutover = T - 1 + 3600 s ≈ 1 hour after the change

Lower the TTL before the change

The standard migration plan has three steps:

1. Lower the TTL to a short value, such as 300 seconds, at least one old-TTL period before the change. Wait for the old long TTL to expire everywhere, so the short value is actually in use.
2. Make the change. Worst-case staleness is now about 5 minutes.
3. Raise the TTL again once the cutover is stable, to reduce load.

Skipping step 1 is the most common mistake. Changing the record and lowering the TTL at the same moment only helps future lookups, not the ones already cached.

Not every cache honors the TTL

Some resolvers enforce a minimum TTL, so a 30-second setting may be served as 300 seconds. Some clients, notably certain JVM and older language runtimes, cache DNS results for the lifetime of the process unless configured otherwise. Connection pools can keep a socket to the old IP long after DNS moved.

So a DNS change alone doesn't always move traffic. Application restarts or pool recycling may be required, and it's worth testing a cutover with the real clients.

Common mistakes

• Lowering the TTL and changing the record in the same minute, then expecting users to see the change quickly.
• Keeping a very low TTL permanently. It multiplies lookups and load on your authoritative servers.
• Assuming every client re-resolves on every connection.

Check yourself

• Why does lowering the TTL have to happen before the change? Answer: caches that already hold the long TTL keep it until it expires, so the short value only applies to lookups made after the old one expires.
• Why might a 30-second TTL still take minutes to take effect? Answer: some resolvers enforce a minimum TTL, and some clients cache the answer for the life of a process or connection.

Key takeaways

• A TTL caps staleness, measured from the last cached lookup.
• Lower the TTL one old-TTL period before a migration, then change the record.
• Some resolvers and clients ignore small TTLs or cache forever, so test real cutovers.

Further learning

Next, see traffic steering and anycast for using DNS answers to route users to different places.