TTL Settings
This guide explains how to configure and optimize Time-to-Live (TTL) settings for your DNS records in the UK DNS Privacy Project authoritative DNS service.
Understanding TTL
TTL (Time-to-Live) is a value specified in seconds that determines how long DNS resolvers should cache your DNS records before requesting fresh data from authoritative nameservers.
How TTL Works
- When a DNS resolver queries your record, it receives both the record data and its TTL value
- The resolver caches this information for the duration specified by the TTL
- During this period, the resolver answers queries from its cache without contacting nameservers
- Once the TTL expires, the resolver discards the cached data and requests fresh information
Configuring TTL Values
The UK DNS Privacy Project allows you to set TTL at two levels:
Domain-Level Default TTL
This sets the default TTL for any records that don’t specify their own value:
- Go to your domain’s details page
- Click Edit to access domain settings
- Set the Minimum TTL value (default: 86400 seconds / 24 hours)
- Click Save Changes
Record-Level TTL
Each individual record can have its own TTL:
- When creating or editing a record, use the TTL dropdown
- Options include:
- Auto: Uses the domain’s default TTL
- 1 minute: 60 seconds
- 5 minutes: 300 seconds
- 30 minutes: 1800 seconds
- 1 hour: 3600 seconds
- 6 hours: 21600 seconds
- 12 hours: 43200 seconds
- 1 day: 86400 seconds
- 1 week: 604800 seconds
TTL Strategy Guide
Different TTL values are appropriate for different situations:
Short TTL (60-300 seconds)
Best for:
- Records that change frequently
- During planned DNS changes
- Testing new configurations
- Emergency changes
Advantages:
- Changes propagate quickly
- Easier to revert problematic changes
- Less downtime during migrations
Disadvantages:
- Increased load on nameservers
- Potentially slower DNS resolution
- Higher query volume
Medium TTL (1800-3600 seconds)
Best for:
- Balanced approach for most records
- Subdomains with moderate change frequency
- Most production websites
Advantages:
- Reasonable propagation time
- Good balance of performance and flexibility
- Moderate nameserver load
Disadvantages:
- Changes take up to an hour to fully propagate
- Some resolvers may ignore very short TTLs
Long TTL (86400+ seconds)
Best for:
- Stable records that rarely change
- Root domain records
- MX and nameserver records
- Infrastructure that doesn’t change often
Advantages:
- Improved performance
- Reduced load on nameservers
- Better resilience if nameservers experience issues
Disadvantages:
- Changes take longer to propagate
- Difficult to quickly correct mistakes
- Potential extended downtime during migrations
Best Practices
Planning DNS Changes
When planning changes to existing records:
-
Reduce TTL in advance:
- Lower the TTL to 300 seconds (5 minutes) or less
- Wait for the original TTL period to pass completely
- Make your DNS changes
- Return to normal TTL after changes propagate
-
Staged approach for critical services:
- Day 1: Reduce TTL from 86400 to 3600 seconds
- Day 2: Reduce TTL from 3600 to 300 seconds
- Day 3: Make DNS changes
- Day 4: Increase TTL to 3600 seconds
- Day 5: Restore normal TTL (86400 seconds)
TTL Recommendations by Record Type
Record Type | Recommended TTL | Rationale |
---|---|---|
NS | 86400+ seconds | Nameserver changes are rare and critical |
SOA | 86400 seconds | Contains zone administration information |
A/AAAA (apex) | 3600+ seconds | Main domain IP addresses |
A/AAAA (www) | 3600 seconds | Primary website addresses |
A/AAAA (dynamic) | 300 seconds | Addresses that change frequently |
MX | 3600+ seconds | Email delivery is critical |
TXT (SPF/DKIM) | 3600 seconds | Email authentication records |
CNAME | 3600 seconds | Aliases to other domains |
SRV | 3600 seconds | Service location records |
PTR | 86400 seconds | Reverse DNS lookups rarely change |
Impact on DNS Propagation
TTL directly affects how quickly DNS changes propagate across the internet:
Propagation Time
- Theoretical maximum: Equal to the previous TTL setting
-
Practical reality: Some resolvers may:
- Ignore extremely short TTLs
- Apply minimum caching times regardless of TTL
- Have their own maximum cache times
Measuring Propagation
To check if your DNS changes have propagated:
-
Use online DNS checker tools that query multiple global resolvers
-
Test from different networks (home, mobile, etc.)
-
Use command-line tools:
dig +trace example.com dig @8.8.8.8 example.com # Google DNS dig @1.1.1.1 example.com # Cloudflare DNS
Performance Considerations
Client Impact
Longer TTLs generally improve performance for your users:
- Faster resolution: DNS queries are answered from cache
- Reduced latency: No need to query authoritative nameservers
- Better resilience: Sites remain reachable even if nameservers have issues
Server Impact
TTL settings also affect your nameservers:
- Query volume: Short TTLs increase the number of queries
- Server load: Higher query volumes increase load on nameservers
- Bandwidth usage: More queries consume more bandwidth
Finding the Balance
For optimal performance, balance these considerations:
- Use longer TTLs for stable infrastructure
- Use shorter TTLs only where needed
- Consider traffic patterns and peak loads
- Monitor query statistics in your domain dashboard
Advanced TTL Scenarios
Disaster Recovery
For domains with disaster recovery planning:
- Keep TTL relatively short (1800-3600 seconds)
- This allows redirection to backup infrastructure if needed
- Document TTL settings in your disaster recovery plan
Service Migration
When migrating services to new infrastructure:
- Gradually reduce TTL as migration approaches
- Execute migration during low-traffic periods
- Progressively increase TTL after confirming stability
Troubleshooting TTL Issues
Changes Not Propagating
If DNS changes aren’t visible:
- Verify the change was saved successfully
- Check when the previous TTL was set
- Wait at least as long as the previous TTL value
- Test using DNS resolvers that haven’t cached the old record
TTL Not Being Respected
If TTL appears to be ignored:
- Some ISPs enforce minimum cache times regardless of your TTL
- Public DNS services may ignore extremely short TTLs
- DNS resolvers might apply their own caching policies
- Check if parent domain delegation has longer TTLs affecting propagation