Every DNS record has a TTL (Time to Live) value that controls how long resolvers cache the response before requesting a fresh copy. It's a single number, measured in seconds, and it's one of the most consequential settings in your DNS configuration.
Set it too high and changes take hours or days to propagate. Set it too low and your authoritative nameservers handle significantly more queries, increasing latency and costs. Get it wrong during a migration and you're stuck waiting for caches to expire while users hit the wrong server.
Despite its importance, TTL strategy is rarely discussed with the same rigor as record values themselves. Most organizations use whatever default their DNS provider sets and never revisit it. This guide covers how TTL works, what values to use for different record types, how to prepare for migrations, and the common mistakes that cause unnecessary downtime.
How TTL Works
When a recursive resolver (like Google's 8.8.8.8 or Cloudflare's 1.1.1.1) queries your authoritative nameserver for a record, the response includes a TTL value. The resolver caches the response and serves it to all subsequent queries for that record until the TTL expires. Only then does the resolver go back to your nameserver for a fresh copy.
TTL is specified in seconds in your DNS zone file or provider dashboard:
yourcompany.com. 300 IN A 203.0.113.50The 300 means resolvers will cache this A record for 5 minutes. After 5 minutes, the next query triggers a fresh lookup from your authoritative nameserver.
TTL Is Not a Guarantee
Important nuance: TTL tells resolvers how long they should cache a record. It doesn't force them to. Some resolvers enforce minimum TTL floors (typically 30-60 seconds), ignoring TTLs below that threshold. Others may serve stale records beyond the TTL in certain failure scenarios (RFC 8767, "serve stale"). And local caches (browser, operating system, application) add their own caching layers on top of resolver caching.
TTL is your best tool for controlling cache behavior, but it's not absolute. Plan accordingly.
Recommended TTL Values by Record Type
Different record types have different change frequencies and different impacts when they're stale. Your TTL strategy should reflect this.
A and AAAA Records (Address Records)
Recommended: 300 seconds (5 minutes)
A records are the most likely to change during migrations, failovers, and infrastructure updates. A 5-minute TTL provides a good balance: changes propagate within minutes, but your nameservers aren't overwhelmed with queries. If you use a CDN that manages your A records (like Cloudflare), the CDN handles the query volume and you can use even lower TTLs.
For domains behind load balancers or failover services, some providers recommend TTLs as low as 60 seconds to enable rapid failover. Check your provider's documentation.
CNAME Records
Recommended: 300-3600 seconds (5 minutes to 1 hour)
CNAME records point to another hostname rather than an IP. If the CNAME target rarely changes (e.g., www pointing to your CDN), a higher TTL (3600) is fine. If the CNAME might change during service migrations, use a lower TTL (300).
Remember that CNAME resolution adds a step: the resolver must first resolve the CNAME, then resolve the target hostname. Each step has its own TTL. A high-TTL CNAME pointing to a low-TTL target means the CNAME itself is sticky even if the target's IP changes quickly.
MX Records (Mail Exchanger)
Recommended: 3600 seconds (1 hour)
MX records change infrequently. You typically only modify them when migrating email providers, which is a planned event where you can lower the TTL in advance. A 1-hour TTL provides good caching while still allowing changes to propagate within a reasonable timeframe.
During an email migration, lower the MX TTL to 300 seconds at least 24 hours before the cutover.
TXT Records (SPF, DKIM, DMARC, Verification)
Recommended: 3600 seconds (1 hour)
TXT records used for email authentication (SPF, DKIM, DMARC) change rarely after initial setup. A 1-hour TTL is appropriate. Domain verification TXT records (Google Workspace, Microsoft 365, etc.) can use even higher TTLs since they're typically checked once during initial setup.
Exception: if you're actively iterating on your SPF record (adding new includes, testing soft fail vs. hard fail), temporarily lower the TTL to 300 seconds so changes take effect quickly.
NS Records (Nameserver)
Recommended: 86400 seconds (24 hours)
Nameserver changes are rare, high-impact events. A 24-hour TTL is standard. The TTL on NS records at the TLD level (set by the registry, not by you) is typically 48 hours, which is why nameserver migrations can take up to two days to fully propagate regardless of what TTL you set on your own NS records.
SOA Records (Start of Authority)
Recommended: 3600 seconds (1 hour)
The SOA record's TTL controls how often resolvers refresh the zone's administrative metadata. The SOA record also contains a "minimum TTL" field that controls negative caching (how long resolvers cache "this record doesn't exist" responses). A minimum TTL of 300-900 seconds is typical.
CAA Records (Certificate Authority Authorization)
Recommended: 3600-86400 seconds (1-24 hours)
CAA records change infrequently. A higher TTL reduces the query load for what is essentially a static security policy. If you're adding or changing authorized CAs, temporarily lower the TTL before making the change.
SRV Records (Service Discovery)
Recommended: 300-3600 seconds
Depends on the service. SRV records for services that might failover (VoIP, instant messaging) benefit from lower TTLs. SRV records for stable services (Microsoft 365 autodiscover) can use higher TTLs.
The Pre-Migration TTL Lowering Process
This is the single most important TTL practice. When you're planning any DNS change, especially a migration, lowering the TTL in advance is the difference between a 5-minute cutover and a 24-hour waiting game.
Here's the process:
- At least 2x the current TTL before your change: Lower the TTL on the records you plan to modify. If the current TTL is 86400 seconds (24 hours), lower it at least 48 hours before the change. If it's 3600 (1 hour), lower it at least 2 hours before. The reason: resolvers that cached the record at the old TTL need time to expire and pick up the new, lower TTL.
- Set the temporary TTL to 60-300 seconds: This ensures that by the time you make the actual change, no resolver is caching your record for longer than 5 minutes.
- Make your change: Update the record to the new value. Propagation completes within minutes.
- Verify the change: Use the DNS lookup tool at dnsassistant.com/tools to confirm the new value is being returned.
- Raise the TTL back: After confirming the change is live and stable, raise the TTL back to the normal value for that record type.
Skipping this process is the number one cause of prolonged propagation delays during migrations. If your A record has a 24-hour TTL and you change the IP without lowering the TTL first, some users will be stuck on the old IP for up to 24 hours.
Common TTL Mistakes
Using the Same TTL for Everything
A 300-second TTL on your NS records means unnecessary query load on your nameservers. A 86400-second TTL on your A records means day-long propagation delays when you need to make a change. Match the TTL to the record type's change frequency and criticality.
Setting TTLs Too Low Permanently
A 60-second TTL on all records might seem like a good idea ("changes propagate instantly!"), but it means your nameservers handle 60x more queries than they would with a 1-hour TTL. This increases costs on metered DNS providers, increases latency for users (more cache misses), and makes your domain more sensitive to nameserver outages (shorter cache duration means less resilience when your nameservers are briefly unreachable).
Low TTLs should be temporary, used during planned changes and raised back afterward.
Not Lowering TTL Before a Migration
Covered above, but worth repeating because it's the most common and most impactful mistake. The time to lower your TTL is days before the migration, not the moment you're making the change.
Forgetting About Negative Caching
If a resolver queries your nameserver for a record that doesn't exist, it caches the NXDOMAIN (not found) response for the duration specified by the SOA record's minimum TTL field. If you create a new record after someone has already triggered a negative cache entry, they won't see the new record until the negative cache expires.
Prevention: create DNS records before the services that depend on them go live. If your SOA minimum TTL is 3600 seconds and someone queries the record before it exists, they'll see NXDOMAIN for up to an hour even after you create it.
Ignoring TTL When Debugging
When troubleshooting DNS issues, always check the TTL on the response you're seeing. If a resolver is returning an old value with a TTL of 45000 seconds remaining, you know exactly how long before it refreshes. The TTL in the response counts down from the original value, so it tells you both how old the cached entry is and how long until it expires.
TTL and DNS Security
TTL has security implications that are often overlooked:
Cache Resilience During Outages
Higher TTLs provide a buffer during nameserver outages. If your nameservers go down for 30 minutes and your TTL is 3600 seconds, most resolvers will continue serving cached records. If your TTL is 60 seconds, records start expiring within a minute and your domain becomes unreachable almost immediately.
DNS Hijacking Detection Window
If an attacker changes your DNS records, the TTL determines how quickly the malicious change propagates. Lower TTLs mean faster propagation of both legitimate and malicious changes. Higher TTLs give you more time to detect and respond to unauthorized changes before they reach all users.
This is a tradeoff: lower TTLs are better for operational agility but worse for attack resilience. The answer is monitoring. DNS Assistant detects record changes in real time regardless of TTL, giving you the alerting speed that makes this tradeoff manageable.
DDoS Amplification
Lower TTLs increase the number of queries that reach your authoritative nameservers, which increases the amplification factor in DNS-based DDoS attacks. Attackers can trigger more queries to your nameservers by exploiting the shorter cache duration. Higher TTLs reduce the query volume at your nameservers.
TTL Quick Reference
| Record Type | Normal TTL | Pre-Migration TTL | Notes |
|---|---|---|---|
| A / AAAA | 300s (5 min) | 60s (1 min) | Most likely to change |
| CNAME | 300-3600s | 60-300s | Match to change frequency |
| MX | 3600s (1 hr) | 300s (5 min) | Lower before email migration |
| TXT (SPF/DKIM/DMARC) | 3600s (1 hr) | 300s (5 min) | Stable after initial setup |
| NS | 86400s (24 hr) | 3600s (1 hr) | TLD NS TTL is out of your control |
| SOA | 3600s (1 hr) | N/A | Min TTL controls negative caching |
| CAA | 3600-86400s | 300s (5 min) | Static security policy |
| SRV | 300-3600s | 60-300s | Depends on service criticality |
Monitoring TTL Changes
DNS Assistant tracks TTL values across all your records and includes them in change alerts. If someone modifies a TTL (intentionally or accidentally), your team knows about it. This is important because TTL changes are often a precursor to other changes: a TTL being lowered from 86400 to 60 seconds might indicate that someone is preparing for a migration, or it might indicate that an attacker is preparing to make a change and wants it to propagate quickly.
Use the DNS lookup tool at dnsassistant.com/tools to check your current TTL values across all record types. For continuous monitoring with real-time alerting on TTL and record changes, sign up at dnsassistant.com.
Top comments (0)