What Is TTL in DNS? Time To Live Explained

What Is TTL?

TTL (Time To Live) is a value in DNS records that specifies how long a record should be cached by DNS resolvers. It's measured in seconds and tells resolvers "you can keep using this cached answer for this many seconds before you need to check for updates."

The Basics

• TTL stands for "Time To Live"
• Measured in seconds
• Controls how long DNS records are cached
• Lower TTL = faster propagation but more DNS queries
• Higher TTL = slower propagation but better performance
• Every DNS record has a TTL value

Example

example.com.    3600    IN    A    192.0.2.1
                 ↑
                TTL = 3600 seconds = 1 hour

This A record can be cached for up to 1 hour before resolvers should query the authoritative server again.

How TTL Works

The Caching Process

1. DNS query received — Resolver receives query for example.com
2. Cache checked — Is there a cached, non-expired response?
3. If cache hit — Return cached response, decrement TTL
4. If cache miss — Query authoritative nameserver
5. Response received — Record with TTL (e.g., 3600 seconds)
6. Response cached — Store with TTL countdown timer
7. Timer counts down — 3600... 3599... 3598...
8. Timer reaches zero — Cache entry expires, next query fetches fresh data

TTL Countdown

When a resolver caches a record, the TTL starts counting down:

Cascade Effect

TTL affects every level of DNS caching:

TTL Values Explained

Common TTL Values

The Trade-offs

Low TTL (60-300 seconds):

• Pros: Fast propagation, quick recovery from mistakes
• Cons: More DNS queries, higher load on authoritative servers, slightly slower resolution

High TTL (3600-86400 seconds):

• Pros: Fewer DNS queries, faster resolution from cache, reduced server load
• Cons: Slow propagation, harder to recover from errors, longer migration windows

DNS Provider Minimums

Some DNS providers enforce minimum TTL values:

Choosing the Right TTL

By Record Stability

Stable records (rarely change):

; NS records - nameservers rarely change
example.com.    86400    IN    NS    ns1.provider.com.

; MX records - email routing is usually stable
example.com.    14400    IN    MX    10 mail.example.com.

Moderately stable (occasional changes):

; A records for production sites
www.example.com.    3600    IN    A    192.0.2.1

; TXT records for email authentication
example.com.    3600    IN    TXT    "v=spf1 include:_spf.google.com ~all"

Frequently changing:

; Development/staging environments
dev.example.com.    300    IN    A    192.0.2.50

; Load-balanced or failover services
api.example.com.    300    IN    A    192.0.2.100

By Scenario

Normal operation:

• Use 3600 seconds (1 hour) as a default
• Good balance between caching and flexibility

Before planned migration:

• Lower to 300 seconds 48-72 hours in advance
• Allow old TTL to expire
• Make changes with fast propagation

During active incident:

• Changes won't propagate faster than current TTL
• Plan ahead for critical services

After migration:

• Raise TTL back to 3600+ seconds
• Reduce DNS query load
• Improve resolution speed

TTL for Different Record Types

Recommended TTL by Record Type

Special Considerations

A records for web servers:

; Production - higher TTL for performance
www.example.com.    3600    IN    A    192.0.2.1

; Staging - lower TTL for flexibility
staging.example.com.    300    IN    A    192.0.2.50

CNAME records:

; CDN endpoint - moderate TTL (CDN handles failover)
cdn.example.com.    3600    IN    CNAME    example.cdn.cloudflare.net.

; Third-party service - match their recommendation
mail.example.com.    3600    IN    CNAME    sendgrid.net.

Email records:

; MX - stable, higher TTL is fine
example.com.    14400    IN    MX    10 mail.google.com.

; SPF - changes are planned
example.com.    3600    IN    TXT    "v=spf1 include:_spf.google.com ~all"

Changing TTL Values

Pre-Change Checklist

Before modifying TTL:

1. Document current TTL — Know what you're changing from
2. Understand the impact — Lower TTL means more queries
3. Plan for old TTL expiration — Changes aren't instant
4. Verify change propagated — Check multiple resolvers

The Two-Phase Approach

Phase 1: Lower TTL (prepare for change)

; Current state
example.com.    3600    IN    A    192.0.2.1

; Lower TTL 48 hours before migration
example.com.    300     IN    A    192.0.2.1

Wait 48+ hours for old TTL to expire everywhere.

Phase 2: Make the actual change

; Now change the IP (with low TTL, propagates quickly)
example.com.    300     IN    A    198.51.100.1

Phase 3: Restore normal TTL (after verification)

; After confirming change is successful
example.com.    3600    IN    A    198.51.100.1

How to Check Current TTL

Using dig:

# Query with +ttl flag to see remaining TTL
dig example.com A

# Look for the TTL value in the ANSWER section
;; ANSWER SECTION:
example.com.    2847    IN    A    192.0.2.1
                 ↑
            Remaining TTL (in seconds)

Query authoritative directly for original TTL:

# Find authoritative nameserver
dig NS example.com +short

# Query authoritative directly
dig @ns1.provider.com example.com A

Best Practices for MSPs

1. Standardize Default TTL

Establish a standard TTL for client domains:

• Recommended default: 3600 seconds (1 hour)
• Document exceptions and reasons
• Apply consistently across clients

2. Lower TTL Before Any Migration

Make this a standard procedure:

• Lower TTL 48-72 hours in advance
• Wait for old TTL to expire
• Then make the change
• Raise TTL after verification

3. Document TTL in Client Records

In your documentation system:

• Record standard TTL for each domain
• Note any records with non-standard TTL
• Track TTL changes for migrations

4. Monitor for Inconsistent TTL

Watch for common problems:

• Accidentally low TTL increasing DNS costs
• Accidentally high TTL causing slow propagation
• Mixed TTL values causing confusion

5. Use Unified DNS for TTL Management

Managing TTL across multiple clients and providers is complex. Unified DNS provides:

• Current TTL values for all records at a glance
• Easy bulk TTL updates
• Pre-migration TTL reduction workflows
• Documentation sync to Hudu

6. Educate Clients on TTL

Help clients understand:

• Why DNS changes aren't instant
• Why you lower TTL before migrations
• Why normal operation uses higher TTL
• How TTL affects their experience

Frequently Asked Questions

What TTL should I use for most records?

3600 seconds (1 hour) is a good default for most records. It provides reasonable caching while allowing changes to propagate within a few hours.

Should I use the lowest possible TTL?

No. Very low TTLs (under 300 seconds) increase DNS query volume, potentially slowing resolution and increasing costs. Only use very low TTLs during active migrations or for genuinely dynamic records.

Why don't my changes appear immediately even with low TTL?

When you lower TTL, the old (higher) TTL is still cached by resolvers. You must wait for the old TTL to expire before the new low TTL takes effect. This is why you should lower TTL before making changes, not at the same time.

Do all DNS resolvers respect TTL?

Most do, but some resolvers have minimum TTL settings that override very low values. Some ISP resolvers are known to cache longer than specified. This is why "up to 48 hours" is often quoted for propagation.

What's the maximum TTL I should use?

86400 seconds (24 hours) is generally the maximum recommended. Longer TTLs provide diminishing returns and make emergency changes very slow to propagate.

Does TTL affect website performance?

Indirectly, yes. Higher TTL means more cache hits, which means faster DNS resolution. However, the difference is typically milliseconds and rarely noticeable to users.

Can I set different TTL for different records on the same domain?

Yes! Each record can have its own TTL. This is useful for having stable records (high TTL) alongside dynamic records (low TTL).

How does TTL interact with DNSSEC?

DNSSEC signatures have their own validity periods. When using DNSSEC, ensure signature validity periods are longer than the record TTL to prevent validation failures.

Get Started with Unified DNS

TTL management is critical for smooth DNS operations. Unified DNS lets you view, modify, audit, and backup all DNS records with their TTL values — making pre-migration TTL changes easy across multiple providers and clients.

Unified DNS is live — try it free for a month with code FREETRIAL2026 at billing setup. No commitment. Or request a demo for a walkthrough.