When you create a DNS record, you're not just specifying where traffic should go, you're also controlling how long other DNS servers should remember that answer before checking again. This caching duration is the TTL (Time To Live) value, and it has significant implications for how quickly changes propagate, how much load your DNS servers handle, and how resilient your domain is during infrastructure changes.
Most registrars set a default TTL value for new records, typically 3600 seconds (one hour). This default represents a reasonable balance for general use, but understanding when and why to override it lets you optimize DNS behavior for your specific needs.
What TTL Actually Controls
TTL values are measured in seconds and appear in every DNS record. When a DNS resolver queries your domain and receives an answer, it caches that answer for the TTL duration. During that time, the resolver serves the cached answer without re-querying your authoritative DNS servers.
Example DNS record with TTL:
example.com. 3600 IN A 192.0.2.1
The "3600" means DNS resolvers can cache this A record for one hour. If someone queries example.com five minutes later from the same resolver, they get the cached answer instantly without generating another DNS query.
DNS operates through multiple layers of caching. When a user's computer queries a domain:
- It checks its own local cache first
- If not cached locally, it queries the configured DNS resolver (often the ISP's or a public resolver like Google's or Cloudflare's)
- The resolver checks its cache
- If not cached, the resolver queries authoritative nameservers for your domain
- The authoritative server responds with the record and TTL value
- The resolver caches the response for the TTL duration
- The user's computer also caches it (often for the TTL duration or less)
Every cache along this path respects the TTL value, which means changing a DNS record doesn't instantly affect all users, they continue seeing the old value until their cached copy expires.
Why 3600 Seconds Makes Sense as a Default
The hour-long TTL standard emerged as a practical compromise between competing concerns.
Reasonable propagation time: When you change a record with a 3600-second TTL, most users see the change within an hour. This is fast enough for most updates while not being so short that it creates excessive DNS traffic.
Reduced DNS query load: Higher TTL values mean fewer queries hitting your authoritative DNS servers. Each query costs bandwidth and processing. With a one-hour TTL, you receive at most one query per resolver per hour for each record, rather than potentially dozens of queries per minute with very short TTLs.
Resilience during DNS server issues: If your authoritative DNS servers experience problems, longer TTLs mean cached records continue serving users even while your DNS infrastructure is unavailable. A one-hour cache provides a reasonable buffer.
Simple to reason about: One hour is intuitive. You can easily estimate how long changes will take to propagate and plan accordingly. More exotic TTL values require calculation to understand their impact.
Balance of flexibility and efficiency: An hour is short enough that planned changes don't require extensive advance preparation, but long enough to avoid creating excessive DNS load during normal operations.
For most DNS records serving stable infrastructure, 3600 seconds hits the sweet spot where you rarely need to think about TTL at all.
When to Use Longer TTLs
While 3600 seconds works well as a default, some scenarios benefit from longer TTL values.
Highly stable infrastructure: If your website IP address hasn't changed in years and you don't anticipate changes, a longer TTL reduces DNS query volume without downside. Records pointing to well-established infrastructure can safely use TTLs of 86400 seconds (24 hours) or even longer.
High-traffic domains: Popular websites generate enormous DNS query volumes. Every query costs money (at some DNS providers) and creates load. Increasing TTL from 3600 to 7200 or 10800 seconds halves or thirds your query volume without significantly impacting change propagation for stable records.
Reducing DNS infrastructure load: If your authoritative DNS servers handle many queries, longer TTLs reduce load. This is particularly relevant if you're approaching rate limits or capacity constraints.
Third-party service records: Records pointing to external services that rarely change (like CNAMEs to CDN providers or hosted services) can use longer TTLs. The service provider handles infrastructure changes on their end without requiring your DNS updates.
Example long-TTL configuration:
example.com. 86400 IN A 192.0.2.1
www.example.com. 43200 IN CNAME example.com.
These records use 24-hour and 12-hour TTLs respectively, suitable for infrastructure you expect to remain stable.
The tradeoff: Longer TTLs make planned changes propagate more slowly. If you later need to update a record with an 86400-second TTL, some users might see the old value for up to 24 hours after you make the change. For truly stable infrastructure, this tradeoff is acceptable because changes are rare and can be planned well in advance.
When to Use Shorter TTLs (Temporarily)
Short TTLs are rarely optimal for permanent configuration but extremely valuable during specific operations.
Before planned infrastructure changes: When you know you'll be changing IP addresses, migrating hosting providers, or updating service endpoints, reduce the TTL to 3600 seconds (or your registrar's minimum) several days before the change. This ensures that when you make the actual change, propagation happens within an hour rather than potentially taking a full day.
During migrations: While actively migrating between systems, maintain short TTLs. If something goes wrong and you need to roll back, short TTLs mean the rollback takes effect quickly rather than leaving some users hitting the wrong infrastructure for hours.
Testing new infrastructure: When pointing DNS at new servers for the first time, short TTLs let you quickly correct mistakes. If the new server doesn't work properly, you can point DNS back to the old server and recovery happens within an hour.
Active troubleshooting: During DNS-related incident response, short TTLs provide flexibility to try different solutions quickly without waiting hours for each change to propagate.
Gradual traffic shifting: Some advanced deployments change TTL to 300 seconds and repeatedly update DNS records to gradually shift traffic from old to new infrastructure, monitoring for issues at each step.
The critical follow-up: After completing changes and verifying everything works correctly, restore TTL to normal values (3600 seconds or higher). Leaving TTL at 300-600 seconds permanently creates unnecessary DNS query load and provides no benefit once you're past the change window.
The Two-Phase Change Strategy
For important infrastructure changes, a two-phase approach minimizes disruption:
Phase 1: TTL Reduction (48-72 hours before the change)
Lower the TTL on affected records to 3600 seconds. Wait at least 48 hours, this allows any caches holding your record with the old, longer TTL to expire. After this wait period, all cached copies of your record will have the new, shorter TTL.
Update the DNS record to point to new infrastructure. With TTL at 3600 seconds, propagation completes within an hour for most users.
Phase 3: TTL Restoration (24-48 hours after verifying success)
Once the change is stable and working correctly, restore TTL to its original longer value. This reduces DNS query load back to normal levels.
Example timeline for migrating a website:
- Day -3: Lower A record TTL from 86400 to 3600
- Day -2: Wait, monitoring to ensure service is stable
- Day 0: Update A record to point to new server IP
- Day 0-1: Monitor new server, verify everything works
- Day 1: Restore A record TTL to 86400
This approach provides fast propagation for the actual change while maintaining efficient DNS operation before and after.
Per-Record TTL Strategy
Different records in your DNS zone serve different purposes and may warrant different TTL values.
Website A records (example.com, www): Use 3600 seconds as default. Increase to 7200-86400 for very stable hosting. Temporarily decrease when planning changes.
Email MX records: These typically change infrequently. 3600 seconds works well, or increase to 7200-10800 for established email infrastructure. Email is critical, so having slightly longer TTLs provides resilience if DNS servers have issues.
Email authentication (SPF, DKIM, DMARC): These TXT records rarely change once configured. 3600-7200 seconds is appropriate. Shorter TTLs provide no benefit since these records typically don't need rapid updates.
Subdomains for specific services: Assess based on stability. A blog hosted externally might use 7200 seconds. A frequently updated staging environment might use 3600 seconds.
CNAME records to external services: Match the service's recommendation if they provide one, otherwise use 3600 seconds. Services that handle their own infrastructure changes don't benefit from your short TTLs.
Verification TXT records: These can use 3600 seconds since they're typically only queried during active verification processes. Some you'll delete after verification completes anyway.
example.com. 86400 IN A 192.0.2.1
www.example.com. 43200 IN CNAME example.com.
mail.example.com. 7200 IN A 192.0.2.2
example.com. 7200 IN MX 10 mail.example.com.
example.com. 3600 IN TXT "v=spf1 mx ~all"
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine"
staging.example.com. 3600 IN A 192.0.2.10
blog.example.com. 7200 IN CNAME blogging-service.example.com.
This configuration uses longer TTLs for stable infrastructure and shorter TTLs for records that might change more frequently or need flexibility.
Understanding Propagation Beyond TTL
TTL values control caching behavior, but actual propagation time involves more factors.
Previous TTL matters: If your record had a TTL of 86400 seconds and you change both the TTL and the record's value simultaneously, some DNS servers might still cache the old value for up to 24 hours because they cached it before your TTL reduction took effect. This is why you lower TTL first and wait before making the actual change.
Negative caching: When DNS queries fail (record doesn't exist), the "no such record" response is also cached, typically for a shorter duration specified in your domain's SOA record. If you create a new record that previously didn't exist, propagation depends on both negative cache timeout and your new record's TTL.
Client-side caching: Operating systems and applications often implement their own DNS caching with different TTL behavior. Browser DNS caches, operating system resolver caches, and application-level caches all affect how quickly users see changes even after DNS resolvers have updated.
Some resolvers ignore TTL: While rare, some DNS resolvers don't fully respect TTL values, caching longer than specified or implementing their own caching policies. Most major DNS providers (Google, Cloudflare, ISPs) respect TTL properly, but edge cases exist.
Practical expectation: Even with short TTLs, plan for up to twice the TTL duration for complete propagation to account for various caching layers and edge cases. A 3600-second TTL means planning for 2 hours until all users see changes.
TTL and DNS Provider Pricing
Some DNS hosting providers charge based on query volume. TTL values directly impact costs with these providers.
Query volume calculation: If your domain receives 1 million hits per day and each hit requires a DNS query (assuming no caching), that's about 694 queries per minute. With a 3600-second TTL, each resolver queries your authoritative servers at most once per hour, dramatically reducing actual query volume.
Doubling TTL from 3600 to 7200 seconds cuts your DNS query volume roughly in half, potentially saving significant money with query-based pricing.
Free tier considerations: Many DNS providers offer free tiers with query limits. Optimizing TTL values helps you stay within free tier limits rather than having to upgrade to paid plans.
When using domain registration with included DNS hosting: Most registrars include DNS hosting without per-query charges. In these cases, TTL optimization for cost savings isn't relevant, focus on technical considerations instead. TTL Mistakes and How to Avoid Them
Setting TTL too low permanently: Some people set 300-second TTLs "just in case" they need to make changes quickly. This creates unnecessary DNS load and provides no benefit during the 99% of time when you're not actively making changes. Use appropriate TTLs and lower them only when needed.
Not lowering TTL before planned changes: Making a change to a record with an 86400-second TTL without first lowering the TTL means some users see old values for up to 24 hours. Plan ahead.
Forgetting to restore TTL after changes: After completing a migration with short TTL, forgetting to increase it back to normal values means permanently elevated DNS query volume. Set a reminder to restore TTL once changes are verified stable.
Using different TTLs inconsistently without reason: If your A record has a 300-second TTL but your CNAME pointing to it has an 86400-second TTL, the long CNAME TTL negates the short A record TTL benefit. Keep related records' TTLs coordinated.
Assuming TTL is propagation time: TTL is the cache duration, but propagation also depends on previous TTL values and various caching layers. Plan for longer than TTL when timing changes.
Monitoring TTL Strategy Effectiveness
After implementing a TTL strategy, verify it's working as intended.
Query your DNS to confirm TTL values:
The response shows the TTL value in the answer section. Verify it matches what you configured.
Monitor DNS query volume: If your DNS provider offers query analytics, watch how TTL changes affect query volume. Increasing TTL should show measurable query reduction.
Track propagation during changes: When making DNS changes with reduced TTL, monitor how long it actually takes for changes to propagate completely. Tools like whatsmydns.net show how different global DNS servers resolve your domain.
Watch for issues during low-TTL periods: When you temporarily reduce TTL, monitor your DNS servers' performance. If you see problems, you might be hitting rate limits or capacity constraints that suggest your baseline TTL should be higher.
Advanced TTL Patterns
Progressive TTL reduction: For very high-stakes changes, reduce TTL in stages. Start at 86400, reduce to 7200 after a few days, then to 3600 a few days later, then make the change. This provides multiple safety windows.
Different TTLs for geographic load balancing: Some advanced DNS setups use different TTLs for different geographic regions based on infrastructure stability and change frequency in each region.
Monitoring-driven TTL: Some sophisticated systems adjust TTL dynamically based on current infrastructure health. If systems are running perfectly, TTL increases. If issues are detected, TTL automatically decreases to enable faster failover if needed.
TTL as part of incident response runbooks: Document TTL adjustment as a step in incident response procedures. When an incident begins, one of the first actions is reducing TTL on affected records to enable faster response.
TTL Best Practices Summary
Start with 3600 seconds for most records: This default handles the majority of situations well without requiring constant attention.
Increase TTL for stable, high-traffic infrastructure: Records that rarely change and serve significant traffic benefit from TTLs of 7200-86400 seconds.
Temporarily decrease TTL before planned changes: Lower to 3600 seconds at least 48 hours before making infrastructure changes, then restore TTL after verifying success.
Coordinate TTL across related records: Records that work together (like A records and CNAMEs pointing to them) should have similar TTLs to ensure consistent behavior.
Document your TTL strategy: Note why specific records have specific TTL values so future you (or other team members) understands the reasoning.
Review TTL settings periodically: As infrastructure matures and stabilizes, gradually increase TTLs. As systems become more dynamic, shorter TTLs might be appropriate.
Monitor actual propagation times: Test how long changes actually take to propagate with your TTL settings to refine your change planning.
Making TTL Work for You
TTL values are a simple numerical setting with significant impact on DNS behavior. Understanding the tradeoffs, propagation speed versus query load, flexibility versus efficiency, lets you choose appropriate values for different scenarios.
The goal isn't finding a single perfect TTL value. Different records warrant different TTLs based on how stable they are, how critical they are, and how frequently they might need changes. A thoughtful TTL strategy uses longer values for stable infrastructure to reduce load and shorter values temporarily when changes are planned to enable fast propagation.
Most importantly, TTL should be something you consciously choose based on your specific needs, not just accept as whatever default your registrar provides. When you understand what TTL controls and how it affects your operations, you can optimize DNS behavior for your infrastructure rather than working against it.
.png&w=2048&q=75)
.png&w=3840&q=75)
.png&w=3840&q=75)
.png&w=3840&q=75)