DNS routing and TTL

DNS turns a name into an address. A TTL (time to live) tells resolvers how long they may cache that answer. Together they decide how fast a traffic change reaches users. Routing policies let DNS choose between answers. A change is only as fast as the slowest cache.

The big idea

A TTL works like a "best before" date on a cached answer. Once the date passes, the resolver asks again. Until then, it keeps the old answer, even if the server has changed its mind.

The date analogy breaks in one place. Some caches ignore the date. Browsers and mobile stacks can hold answers longer than the TTL says, so DNS failover is eventual, not instant.

Routing policies

Walking through a failover

Suppose the record's TTL is 300 seconds. At 14:00:00 you flip the record from the primary to the secondary. A client fetched the old answer at 13:59:50.

1. The client's cache holds the old answer until 13:59:50 + 300 s = 14:04:50.
2. Between 14:00:00 and 14:04:50, that client still goes to the primary.
3. After 14:04:50, the client asks again and gets the secondary.

So a 300-second TTL gives up to about five minutes of old answers, plus any cache that ignores the TTL. A "five-minute failover" is really a window. Clients that cached for 30 minutes before the flip stay on the old path for 30 minutes.

TTL strategy

• Short TTL (30 to 60 seconds) for records you will fail over or shift by weight. The cost is more DNS queries.
• Long TTL (300 to 3600 seconds) for stable names, such as a CDN hostname. This means less DNS traffic and slower change.

Common mistakes

• Using a long TTL on a record you may need to fail over. Lower it before the risk, not during the outage.
• Calling DNS failover instant. It is eventual, and some clients ignore TTLs.
• Putting a CNAME at the zone apex. Use an alias record instead.

Check yourself

1. A record has a TTL of 300 seconds. A client cached the old answer at 13:59:50, and you flip the record at 14:00:00. When does that client stop using the old address? At 14:04:50, when its cached answer expires.
2. Why lower the TTL a day before a planned cut? Caches that fetched the old record expire sooner, so the new answer reaches clients faster.

Key takeaways

• A TTL sets how long resolvers keep an answer. It is the floor of your failover time.
• Routing policies choose the answer. Health checks decide which answers are healthy.
• Lower TTLs before planned changes, and assume some clients stay sticky anyway.

Further learning

Next, see how traffic is protected before it reaches your load balancers in TLS, WAF and CDN.