Sidebar

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

  1. When a DNS resolver queries your record, it receives both the record data and its TTL value
  2. The resolver caches this information for the duration specified by the TTL
  3. During this period, the resolver answers queries from its cache without contacting nameservers
  4. 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:

  1. Go to your domain’s details page
  2. Click Edit to access domain settings
  3. Set the Minimum TTL value (default: 86400 seconds / 24 hours)
  4. Click Save Changes

Record-Level TTL

Each individual record can have its own TTL:

  1. When creating or editing a record, use the TTL dropdown
  2. 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:

  1. 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
  2. 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:

  1. Use online DNS checker tools that query multiple global resolvers

  2. Test from different networks (home, mobile, etc.)

  3. 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:

  1. Verify the change was saved successfully
  2. Check when the previous TTL was set
  3. Wait at least as long as the previous TTL value
  4. Test using DNS resolvers that haven’t cached the old record

TTL Not Being Respected

If TTL appears to be ignored:

  1. Some ISPs enforce minimum cache times regardless of your TTL
  2. Public DNS services may ignore extremely short TTLs
  3. DNS resolvers might apply their own caching policies
  4. Check if parent domain delegation has longer TTLs affecting propagation

Our use of cookies
We use a session cookie to maintain your login state when you create an account with us. This cookie is essential for the operation of our website and is used solely for authentication purposes. For more information, please read our privacy policy.