DNS TTL - Time To Live

Optimize DNS caching for your performance and flexibility needs.

TTL (Time To Live) is a value in seconds that indicates how long a DNS record can be cached by DNS resolvers. It's a crucial parameter that affects the speed of change propagation and resolution performance.

A short TTL (e.g., 300 seconds) allows rapid changes but increases load on your DNS servers and latency for users. A long TTL (e.g., 86400 seconds) improves performance but delays modification propagation.

Understanding and managing TTL is essential for server migrations, deployments, and incident management. A good balance between stability and flexibility depends on your specific needs.

How TTL Works

TTL controls DNS record caching:

Value in seconds: TTL is expressed in seconds. 3600 = 1 hour, 86400 = 24 hours. It's the maximum caching duration.
Hierarchical caching: Records are cached at multiple levels: ISP, recursive resolvers, browsers. TTL affects all these levels.
Decrement: TTL decrements over time in cache. A record cached with TTL 3600 will have TTL 3000 after 10 minutes.
Per record: Each DNS record has its own TTL. You can have different TTLs for A, MX, TXT depending on needs.

TTL Impact

TTL choice has important consequences:

Propagation speed: A long TTL delays change propagation. After modification, old records remain cached until expiration.
Performance: A long TTL reduces DNS queries, improving resolution latency and reducing load on DNS servers.
Resilience: A long TTL allows caches to work even if your DNS servers are temporarily unavailable.
Flexibility: A short TTL allows rapid changes, useful for incidents or migrations. Trade-off with performance.

TTL Strategies

Adopt a TTL strategy suited to your needs:

Standard TTL: For stable records, use 3600-86400 seconds (1-24 hours). Good performance/flexibility balance.
Pre-migration: Before a planned migration, reduce TTL to 300 seconds 24-48h in advance. Caches will be purged when you change IP.
During incident: When a problem requires rapid IP change, you're limited by current TTL. Hence the value of a reasonable TTL.
Post-migration: Once migration is stable, restore a longer TTL to optimize performance.

TTL Configuration Examples

Here are TTL configuration examples:

; Standard TTL (1 hour)
example.com.     3600  IN  A     93.184.216.34

; Long TTL for stable records (24h)
example.com.     86400 IN  NS    ns1.provider.com.
example.com.     86400 IN  MX    10 mail.example.com.

; Short TTL for flexibility (5 min)
api.example.com. 300   IN  A     192.0.2.1

; Check current TTL
$ dig example.com A +noall +answer
example.com.  3542  IN  A  93.184.216.34
# The 3542 indicates seconds remaining before cache expiration

; In a BIND zone, default TTL
$TTL 3600
@ IN SOA ns1.example.com. admin.example.com. (
    2024010101 ; Serial
    7200       ; Refresh
    3600       ; Retry
    1209600    ; Expire
    86400 )    ; Negative TTL

TTL appears after the name and before the class (IN). The dig command shows remaining TTL in the queried resolver's cache. $TTL defines the default TTL for the zone.

TTL Best Practices

Manage your TTLs effectively:

Avoid extremes: A 60-second TTL overloads your DNS. A 1-week TTL makes migrations impossible. 1-24h is generally optimal.
Plan migrations: Reduce TTL several days before a planned migration. Otherwise, you'll wait up to 24h for full propagation.
Differentiate by use: Long TTL for MX and NS (stable), medium TTL for A (may change), short TTL for dynamic environments.
Document: Note your standard TTLs and reasons for exceptions. Useful during late-night incidents.

TTL Checklist

TTL defined for each record type
Reasonable TTL (avoid <60s or >1 week)
TTL reduction procedure before migration documented
Current TTL verified before urgent changes
Propagation monitoring after changes
TTL restored after migrations

Frequently Asked Questions - TTL

What TTL should I choose by default?

3600 seconds (1 hour) is a good default. Short enough to propagate changes in a few hours, long enough for good performance. Adjust based on your specific needs.

Why doesn't my DNS change propagate?

Caches keep the old record until TTL expiration. If the old TTL was 86400, wait up to 24h. Some caches also ignore very short TTLs.

Can I force immediate propagation?

No, you don't control external caches. You can clear your own cache (ipconfig /flushdns on Windows) but not those of ISPs or other users.

Is a TTL of 0 possible?

Technically yes, but many resolvers ignore TTL=0 and use a minimum (30-60s). This also generates enormous load on your DNS servers.

Does TTL affect SEO?

Not directly, but a very short TTL can slightly increase DNS resolution latency, which may impact load time. The effect is generally negligible.

How do I see a record's TTL?

Use dig example.com A +noall +answer. The number between the name and IN is the remaining TTL in the queried resolver's cache.

Master TTL for Your DNS

TTL is an important lever to balance performance and flexibility of your DNS infrastructure. A good TTL choice facilitates migrations, improves performance, and gives you control during incidents.

Adopt a consistent TTL strategy, plan reductions before migrations, and monitor propagation of your changes. MoniTao can help verify that your DNS modifications propagate correctly.

Useful Links

Ready to Sleep Soundly?

Start free, no credit card required.

Create My Account See pricing