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:

Time Elapsed	TTL Remaining
Initial cache	3600 (1 hour)
After 5 minutes	3300
After 30 minutes	1800
After 59 minutes	60
After 1 hour	Cache expired - fetch new record

Cascade Effect

TTL affects every level of DNS caching:

Cache Level	Behavior
Authoritative Server	Returns record with TTL 3600
ISP Resolver	Caches for up to 3600 seconds
Corporate DNS	Caches for up to remaining TTL
User’s Computer	Caches for up to remaining TTL
Browser	May cache for shorter period

TTL Values Explained

Common TTL Values

TTL (seconds)	Human Readable	Use Case
60	1 minute	During active changes
300	5 minutes	Migration preparation
600	10 minutes	Frequently changing records
1800	30 minutes	Moderate change frequency
3600	1 hour	Standard for most records
7200	2 hours	Stable records
14400	4 hours	Rarely changing records
43200	12 hours	Very stable records
86400	24 hours	Maximum recommended

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:

Provider	Minimum TTL
Cloudflare (Free)	300 seconds (proxied)
Cloudflare (Pro+)	60 seconds
AWS Route 53	0 seconds (no minimum)
GoDaddy	600 seconds
Namecheap	60 seconds
Azure DNS	1 second

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

Record Type	Recommended TTL	Rationale
A / AAAA	3600	Balance between caching and flexibility
CNAME	3600	Usually points to stable targets
MX	3600-14400	Email routing should be stable
TXT (SPF/DKIM/DMARC)	3600	Changes are planned, not urgent
NS	86400	Nameservers rarely change
SOA	3600-86400	Zone metadata, rarely queried
SRV	3600	Service discovery, moderate stability
CAA	3600-86400	Certificate policy, rarely changes
PTR	3600-86400	Reverse DNS, usually stable

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.