DNS TTL Explained: How Caching Affects Your Website and How to Use It
Every DNS record has a TTL value, measured in seconds. It tells resolvers how long they can cache the answer before asking again. A TTL of 3600 means "you can trust this answer for one hour." After that, the resolver throws it away and queries the authoritative server again.
This caching mechanism is what makes DNS fast. It's also what makes DNS changes feel slow. Understanding TTL is essential for anyone managing DNS records.
How Caching Works
When a resolver receives a DNS response, it stores the result for the duration specified by the TTL. Every subsequent query for the same record is answered from the cache without needing to traverse the DNS hierarchy again.
This happens at multiple layers:
Recursive resolvers (like 1.1.1.1 or 8.8.8.8) cache aggressively because they serve millions of users; caching a popular domain's records saves enormous amounts of upstream queries. These resolvers honor the A record TTL you set on your authoritative nameserver.
Operating systems maintain their own DNS cache. On macOS, Linux, and Windows, resolved names are cached locally so repeated lookups for the same domain don't even hit the network.
Applications sometimes cache DNS results internally. Browsers, for instance, maintain their own cache separate from the OS.
When you change a DNS record, the old value persists in all of these caches until the TTL expires. If your A record has a TTL of 86400 (24 hours), some users will continue reaching the old IP for up to 24 hours after you've made the change. You cannot force remote caches to flush.
Choosing the Right TTL
There's no universally correct TTL. The right value depends on what the record does and how often it might need to change.
Low TTLs (60-300 seconds)
Use short TTLs when you need fast failover or frequent changes.
When to use:
- Active failover systems where a health check switches traffic to a backup server
- Records you're about to change (lower the TTL in advance, wait for the old TTL to expire, then make the change)
- Development and staging environments where records change often
- CDN or load balancer configurations that may need rapid updates
Tradeoffs: More DNS queries hit your authoritative servers, increasing their load. Slightly higher latency for users since their resolver has to re-query more often. For most domains, the latency difference is negligible (a few milliseconds), but the query volume increase is real.
Medium TTLs (3600-14400 seconds / 1-4 hours)
The sweet spot for most production records. Short enough that changes propagate within a few hours, long enough to benefit from caching.
When to use:
- Website A/AAAA records that don't change frequently
- MX records for email delivery
- Most TXT records (SPF, domain verification)
- SRV records for service discovery
High TTLs (86400+ seconds / 24+ hours)
Use long TTLs for records that essentially never change.
When to use:
- NS records for established domains
- SOA records
- DKIM public keys that are rotated infrequently
- Records for infrastructure that hasn't changed in years
Tradeoffs: When you do need to change these records, the old values linger in caches for a long time. You can mitigate this by lowering the TTL in advance of a planned change.
The TTL Dance: Preparing for Changes
When you know you're going to change a DNS record (for example, migrating your website to a new server), follow this sequence:
- Lower the TTL on the record you're going to change. Set it to 300 seconds (5 minutes).
- Wait for the old TTL to expire. If the TTL was 86400 (24 hours), you need to wait 24 hours for all caches worldwide to expire their copy and pick up the new, lower TTL.
- Make the change. Update the record value (e.g., point the A record to the new server's IP).
- Wait for propagation. With a 300-second TTL, most resolvers will pick up the new value within 5 minutes.
- Verify. Test from multiple locations to confirm the new value is being served.
- Raise the TTL back. Once the change is confirmed, increase the TTL to its normal value.
Skipping step 2 is the most common mistake. If you lower the TTL and immediately make the change, caches that still have the old TTL haven't expired yet; they'll serve the stale record for the remainder of the old TTL, regardless of what you set the new TTL to.
TTL Realities and Gotchas
Not all resolvers honor TTL
Some resolvers impose minimum TTLs. If you set a TTL of 30 seconds, a resolver with a minimum of 300 seconds will cache for 300 seconds anyway. This is uncommon but not rare, particularly in corporate environments with custom DNS configurations.
Some resolvers serve stale records
RFC 8767 defines "Serving Stale Data to Improve DNS Resiliency." Some resolvers will continue serving cached records past their TTL if the authoritative server is unreachable. This is a resilience feature, not a bug; however, it means your records might persist slightly longer than the TTL suggests.
NS record TTLs are special
The TTL on NS records in the parent zone (the glue records) may differ from the TTL on NS records in your zone. The parent zone's TTL controls how long resolvers cache the delegation, which can be different from what you set.
CNAME chains multiply latency
If www.example.com is a CNAME to example.cdn.com, which is a CNAME to edge42.cdn.com, each link in the chain has its own TTL and requires its own resolution. The effective cache time is limited by whichever TTL is shortest in the chain.
Monitoring TTL Changes
TTL changes are worth monitoring because they can signal important events:
Preparation for an attack. An attacker who compromises your DNS might lower TTLs first. When they change the record values, the new (malicious) values propagate quickly. DNS record monitoring can alert you to unexpected TTL changes.
Misconfiguration. Someone accidentally sets a TTL to 60 seconds on a record that should be 86400. Query volume to your nameservers spikes.
Degraded resilience. If someone raises TTLs too high, your ability to respond quickly to an incident decreases. You won't be able to redirect traffic via DNS changes in a reasonable timeframe.
A TTL change might seem minor, but in context it can be the early warning sign of a larger problem. Monitor it like any other record change.