Choosing the Right TTL for Your Records

Every DNS record carries a number that most people set once and forget: the Time To Live. This value, measured in seconds, tells every resolver on the Internet how long they can trust this answer before asking again.

TTL is a bet you're placing about the future. A short TTL says "things might change soon." A long TTL says "this is stable—trust it." Every second you add is confidence. Every second you remove is hedging.

Get this wrong in one direction, and you waste resources answering the same question millions of times a day. Get it wrong in the other direction, and you'll change an IP address on Saturday morning only to watch helplessly as users trickle over to the new server across the next 24 hours—some reaching the old, dead address well into Sunday.

The Trade-Off

Short TTLs (60-300 seconds) mean changes propagate in minutes. Update an IP address, and the world sees it almost immediately. But resolvers must query your nameservers constantly. More traffic. Slightly slower lookups because cached answers expire before users can benefit from them.

Long TTLs (3600-86400 seconds) mean your nameservers handle a fraction of the queries. Resolvers cache answers for hours or days. Users get instant responses from cache. But change something? You're committed. If you're pointing at the wrong server, you wait.

The optimal TTL depends on one question: how likely is this record to change, and how badly does it hurt if changes are slow?

TTL by Stability

Rock-Solid Infrastructure (86400-172800 seconds)

If it hasn't changed in months and won't change without serious planning:

• Dedicated servers that have held the same IP address since installation
• Mail servers running on stable infrastructure—email tolerates caching well
• Nameserver records (NS) that point to your authoritative DNS—these change maybe once every few years

A 24-48 hour TTL means resolvers barely touch your servers. The Internet trusts your answers.

Production Services (3600-7200 seconds)

Most production workloads live here:

• Cloud-hosted applications where you probably won't change IPs, but you could
• API endpoints that might need failover or load balancing adjustments
• CDN CNAMEs where the provider occasionally rotates infrastructure

One to two hours gives you flexibility without drowning in DNS queries.

Frequently Changing Resources (300-900 seconds)

• Development and staging environments where deployments happen constantly
• Dynamic DNS for connections with changing IP addresses
• Load balancer pools where you need to remove unhealthy servers quickly

Five to fifteen minutes means changes propagate fast enough to not block your workflow.

Failover-Critical Systems (60-300 seconds)

When minutes of downtime cost serious money:

• Disaster recovery where you need traffic at the backup datacenter immediately
• Health-check-driven DNS that automatically routes around failures

One to five minutes means most users reach the right place within a couple of TTL cycles.

The Pre-Migration Technique

Here's where TTL strategy actually saves you.

You're migrating a server next Saturday. Your A record has an 86400-second TTL—24 hours. If you change the IP address Saturday morning, some users won't see the new IP until Sunday morning. The old server is offline. Those users see errors.

The problem: once a resolver caches your record, it won't ask again until the TTL expires. You cannot reach into resolvers worldwide and clear their caches. This is the only leverage you have—and you must use it before you need it.

The solution: lower the TTL before you need it low.

1. One week before: Change the TTL from 86400 to 300 seconds. Don't touch the IP address yet.
2. Wait for the old TTL to fully expire: Every resolver that cached your record at 86400 seconds needs to age out. This takes the full original TTL period—24 hours minimum—but you're doing it a week early to be safe.
3. Perform the migration: Now every resolver is checking every five minutes. Change the IP, and the world sees it within minutes.
4. Verify: Confirm traffic is reaching the new server correctly.
5. Restore the TTL: Raise it back to 86400 seconds for efficient long-term operation.

The week of waiting feels excessive. It isn't. DNS caching is distributed across millions of resolvers worldwide, each with their own timing. And here's the uncomfortable truth: some resolvers ignore TTL values entirely, caching longer than you specified¹. The buffer isn't paranoia. It's acknowledgment that you're not fully in control.

TTL by Record Type

A and AAAA records: Varies entirely by infrastructure stability. A static dedicated server? 86400 seconds. A cloud instance? 3600 seconds.

CNAME records: You're pointing at someone else's infrastructure. Match or undercut their TTL—no point caching your pointer longer than they cache the destination. If your CNAME has an 86400-second TTL but the target A record has 300 seconds, your long TTL negates their short one.

MX records: Email infrastructure is stable by design. 86400 seconds is standard. Mail delivery tolerates caching gracefully.

TXT records: SPF and DKIM rarely change—86400 seconds. Verification tokens you'll delete soon? 3600 seconds or less.

NS records: Your authoritative nameservers almost never change. 172800 seconds (48 hours) or longer. When you do change nameservers, you'll plan it carefully regardless of TTL.

A Real Configuration

An e-commerce platform might set:

Before a datacenter migration, they'd lower www and api to 300 seconds one week out, migrate, verify, then restore.

Sources