Time-to-Live (TTL): The Cache Validity Clock

Caching enables DNS to scale, but caching introduces a fundamental problem: how long should cached data remain valid?

DNS records change. IP addresses get reassigned. Load balancers shift traffic. Servers fail and replacements come online. Organizations migrate to new infrastructure. Every cached record can become stale—pointing to the wrong server, or worse, to no server at all.

Yet if caches are invalidated too quickly, the benefits of caching evaporate. Short-lived caches increase query volume, latency, and infrastructure load. The Internet's DNS infrastructure cannot function if every record expires in seconds.

Time-to-Live (TTL) is the mechanism that balances these competing demands.

TTL is a field in every DNS record that specifies how long resolvers and clients may cache the record before it must be refreshed from an authoritative source. TTL is the lever that domain administrators use to tune the trade-off between freshness (how quickly changes propagate) and efficiency (how much caching reduces load and latency).

Time-to-Live is a 32-bit unsigned integer field present in every DNS resource record. It specifies the maximum number of seconds that the record may be cached by resolvers and clients before requiring revalidation.

TTL in the DNS Protocol:

Every Resource Record (RR) in a DNS response includes five components:

1. NAME — The domain name the record describes
2. TYPE — The record type (A, AAAA, MX, CNAME, etc.)
3. CLASS — Almost always IN (Internet)
4. TTL — Seconds the record may be cached
5. RDATA — The record-specific data (IP address, hostname, etc.)

The TTL field occupies bytes 7-10 of the standard RR format, as defined in RFC 1035. Being 32-bit unsigned, TTL can theoretically range from 0 to 4,294,967,295 seconds (~136 years), though practical values are far smaller.

TTL Countdown Mechanism:

When a resolver receives a DNS response, it stores the record along with its TTL value. The resolver then decrements the TTL over time as the record ages in cache:

Received: www.example.com → 93.184.216.34, TTL=3600

Time 0:    TTL remaining = 3600 seconds
Time 600:  TTL remaining = 3000 seconds  
Time 1800: TTL remaining = 1800 seconds
Time 3600: TTL remaining = 0 → Record expires, must refresh

As DNS responses flow through multiple caching layers, TTL values are progressively decremented to reflect time spent in transit and in each cache. This ensures that downstream caches never hold records longer than the original TTL permits.

The TTL Countdown Chain:

Consider a query path: Client → Local Resolver → ISP Resolver → Authoritative Server

1. Authoritative server returns record with TTL=3600
2. ISP resolver receives record, caches it, starts TTL countdown
3. After 60 seconds, client's local resolver queries ISP resolver
4. ISP resolver responds with TTL=3540 (3600 - 60 = time elapsed)
5. Local resolver caches with TTL=3540, starts its own countdown
6. After 30 seconds, client queries local resolver
7. Local resolver responds with TTL=3510 (3540 - 30)
8. Client caches with TTL=3510

The key principle: TTL always reflects remaining validity, not original validity.

Why TTL Countdown Matters:

If resolvers returned the original TTL without countdown, downstream caches could hold records far longer than intended:

• Authoritative sets TTL=300 (5 minutes)
• ISP resolver caches at t=0, returns original TTL=300 at t=280
• Local resolver caches with TTL=300, holds until t=580 (9.7 minutes from original)
• Client caches with TTL=300, holds until t=880 (14.7 minutes from original)

The record would be held 3x longer than authorized. TTL countdown prevents this runaway caching.

Minimum TTL Policies:

Some resolvers enforce minimum TTL floors, refusing to cache records below a threshold (e.g., 30 seconds). This protects against:

1. Extreme cache churn from very low TTLs
2. High query rates overwhelming resolver capacity
3. Potential abuse through TTL=0 (uncacheable) records

However, enforcing TTL floors delays propagation of legitimate changes, creating operational trade-offs.

TTL selection requires balancing two competing priorities that cannot be simultaneously optimized:

Freshness Priority (Low TTL):

• Changes propagate quickly across the Internet
• Failover to backup servers happens rapidly
• Incorrect cached records clear quickly
• Geographic load balancing can react to conditions

Efficiency Priority (High TTL):

• Reduced query load on authoritative servers
• Lower latency for clients (more cache hits)
• Reduced bandwidth consumption
• Lower costs (particularly for metered DNS services)
• Improved resilience during authoritative outages

The trade-off is inherent and inescapable. Every TTL selection represents a specific position on this spectrum.

Real-World TTL Selection Considerations:

1. How often does this record change?

• Static website with fixed IP: High TTL acceptable
• Load balancer with health checks: Low TTL needed
• CDN with geographic steering: Very low TTL required

2. How critical is rapid failover?

• Payment processing: Low TTL for immediate failover
• Documentation site: Higher TTL acceptable; brief outage tolerable

3. What's the cost of stale data?

• Points to decommissioned server: Users see errors
• Points to migrated server: Traffic goes to wrong datacenter
• Points to compromised/hijacked IP: Security incident

4. What's the query volume?

• High-traffic domain: Low TTL generates massive query load
• Obscure internal service: TTL impact minimal

5. What's the resolver behavior?

• ISP resolvers may enforce TTL floors
• Enterprise resolvers may have aggressive caching
• Browser/OS caches may have independent caps

Experienced DNS administrators apply established TTL patterns based on record purpose and operational requirements. Understanding these patterns helps make informed configuration decisions.

Pattern 1: Differentiated TTL by Record Type

Different record types typically have different change frequencies, warranting different TTLs:

Pattern 2: TTL Based on Infrastructure Stability

Pattern 3: TTL Reduction Before Changes

The most common operational TTL pattern is the pre-change reduction sequence:

1. Normal operation: TTL=3600 (high cache efficiency)
2. 48 hours before change: Reduce TTL to 300
3. Wait 48+ hours: Ensure old high-TTL records expire globally
4. Execute DNS change: Old records cleared, new records propagate quickly
5. Verify change complete: Monitor DNS responses from multiple vantage points
6. Restore high TTL: Return to TTL=3600 after stable

Why wait longer than the original TTL?

Resolvers may have cached the record at any point during the previous TTL period. If the original TTL was 24 hours and you lowered it 12 hours ago, resolvers who cached 12 hours ago still have 12 hours remaining on their cached copy with the old TTL value.

Pattern 4: Anycast and CDN TTLs

CDN providers often recommend or require very low TTLs (30-60 seconds) because they perform geographic traffic steering and health-based routing. The CDN's edge servers change constantly, and client connections need to follow the steering.

However, this creates high query volumes that CDN providers absorb as part of their service infrastructure.

DNS caching doesn't just apply to successful responses—it also applies to negative responses indicating that a domain or record type doesn't exist. Negative caching prevents repeated queries for non-existent resources and is governed by the SOA MINIMUM field.

Types of Negative Responses:

1. NXDOMAIN — The queried domain name does not exist

   • Example: nonexistent.example.com returns NXDOMAIN
   • Indicates no records of any type exist for this name

2. NODATA — The domain exists but has no records of the requested type

   • Example: example.com exists but has no AAAA record
   • Returns empty answer section with SOA in authority

How Negative TTL Works (RFC 2308):

Negative responses include the SOA record for the zone in the authority section. The negative cache TTL is the minimum of:

• The SOA record's TTL
• The SOA MINIMUM field value

This ensures negative responses don't persist longer than the zone administrator intends.

Why Negative Caching Matters:

1. Typo protection — Users mistype domains constantly. Without negative caching, each typo generates repeated queries to authoritative servers.

2. Attack mitigation — Attackers may flood queries for random, non-existent subdomains (NXDOMAIN attacks). Negative caching limits the damage.

3. Behavioral optimization — Some applications check multiple domain patterns (e.g., _dmarc.example.com, _domainkey.example.com). Negative caching prevents repeated misses.

Historical Note on MINIMUM Field:

Before RFC 2308 (1998), the SOA MINIMUM field specified the default TTL for all records in the zone. RFC 2308 redefined it specifically as the negative cache TTL. Some legacy documentation and configurations may reflect the older interpretation—modern DNS universally follows the RFC 2308 semantic.

A TTL of zero has special meaning in DNS: the record should not be cached and must be re-queried for every use. While technically valid, TTL=0 is controversial and its behavior varies across implementations.

What TTL=0 Means:

• The record is valid only for the current transaction
• Resolvers should not store the record for subsequent queries
• Every client request should trigger a fresh resolution

When TTL=0 Might Be Used:

1. Real-time traffic steering — Load balancers that need per-query decisions
2. Dynamic DNS — Records that change with every query (though unusual)
3. Testing scenarios — Ensuring fresh data during development

The Problem with TTL=0 in Practice:

Alternative Approaches to TTL=0:

Rather than using TTL=0, consider these alternatives:

Browser and OS TTL Floors:

Even if your authoritative server returns TTL=0, clients may not honor it:

• Chrome: Minimum cache 60 seconds by default (configurable)
• Firefox: Configurable cache duration
• Windows DNS Client: May enforce minimum caching
• macOS: May apply minimum caching policies

The only truly reliable way to force per-query resolution is at the application level, bypassing system resolver caches entirely.

Understanding TTL behavior in practice requires observing actual DNS responses across different resolvers and time periods. Several tools and techniques help network engineers verify TTL configuration and propagation.

Command-Line TTL Observation:

Windows PowerShell TTL Observation:

# Using Resolve-DnsName to observe TTL
Resolve-DnsName -Name www.example.com -Type A

# Output includes TTL field
Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
www.example.com                                A      3241  Answer     93.184.216.34

# Query specific server
Resolve-DnsName -Name www.example.com -Type A -Server 8.8.8.8

Multi-Location TTL Propagation Testing:

Online tools test DNS propagation from global vantage points:

• whatsmydns.net — Shows DNS resolution from ~20 global locations
• dnschecker.org — Similar global propagation view
• dig web interface (digwebinterface.com) — Web-based dig from various locations

These tools are essential for verifying that DNS changes have propagated globally after TTL expiration.