DNS TTL Best Practices: Optimal Values for Different Records

DNS TTL Best Practices: Optimal Values for Different Records

TTL (Time To Live) is one of the most important values in DNS. It controls how long resolvers and clients cache a record. Too high — painful migrations. Too low — unnecessary load on your authoritative DNS. This article covers recommended values per record type and the scenarios where they should be adjusted.

What TTL is

TTL is expressed in seconds and attached to every record in the zone:

example.com.  3600  IN  A  93.184.216.34

3600 is the TTL — any resolver caches the answer for one hour.

How TTL caching works

1. Client asks for the A record.
2. Resolver queries authoritative and gets back the record with TTL = 3600.
3. Resolver returns the answer to the client and stores it for 3600 s.
4. Within the hour every subsequent query is served from cache.
5. After TTL the record is evicted and the cycle repeats.

Recommended values

High vs low TTL trade-offs

High TTL (24h+)

Pros:

• Fewer queries to authoritative servers and lower load and bills.
• Fast answers from cache.
• Resilience to transient DNS provider issues.

Cons:

• Slow migrations — 24h before full convergence.
• Slow failover.
• Stale cached records after incidents.

Low TTL (60-300 s)

Pros:

• Fast migrations.
• DNS failover / GSLB works.
• Flexibility during incidents.

Cons:

• High authoritative load.
• Tighter availability dependency on auth DNS.
• Some resolvers ignore very low TTL (enforce 30-300 s minimum).

Migration strategy

Golden rule: lower TTL before, raise after.

1. T-48h: lower TTL to 300. Wait for the old high TTL to expire on resolvers.
2. T-0: change the record.
3. T+2h: verify with DNS Propagation.
4. T+24h: restore TTL to 3600.

TTL and failover

For DNS failover — switching a record to a backup IP — TTL defines the RTO. TTL = 300 means clients see the new IP within 5 min at most. TTL = 3600 means one hour. For critical systems use TTL = 60.

Caveat: some resolvers (Chrome DNS cache, ISP services) enforce a 30-60s minimum. Values below 60 are effectively useless.

Negative TTL (SOA minimum)

The SOA record's minimum field is the TTL for negative responses (NXDOMAIN, NODATA) per RFC 2308. Recommended: 300-3600.

example.com.  3600  IN  SOA  ns1.example.com. admin.example.com. (
    2026041401   ; Serial
    10800        ; Refresh
    3600         ; Retry
    604800       ; Expire
    3600         ; Minimum (negative TTL)
)

How to check TTL

dig A example.com
# response:
# example.com.  600  IN  A  93.184.216.34
dig SOA example.com

The number to the left of IN is TTL. It counts down for every second the record stays in a resolver's cache.

Common mistakes

TTL = 0

Disables caching. Your authoritative DNS gets hammered. Use at least 30-60.

Migrating with TTL = 86400

Never migrate without lowering TTL first. Clients will see different versions for 24 hours.

Mixed TTLs within an RRset

Per RFC 2181 all records in an RRset (same name + type) must share the same TTL. Violations cause undefined behaviour.

Low TTL on NS

NS rarely changes but strongly affects stability. Keep it at 24h+.

FAQ

How quickly does a TTL change take effect?

Not immediately. Until the old cache expires, the new TTL doesn't apply.

Can I set TTL = 10?

You can, but most resolvers round up to 30-60. Little practical gain.

What is the provider's Default TTL?

The fallback if you don't specify. Cloudflare Auto is typically 300, Route 53 default is 300.

Does TTL affect SEO?

Not directly. But a long outage caused by a misconfigured TTL can hurt crawling.

Conclusion

Keep it simple: steady state 3600-86400, migration 300, NS 86400. Always plan migrations with a 48h buffer and verify propagation via Propagation Checker. For critical services, enable DNS monitoring to catch unplanned TTL or record changes.