DNS Caching and TTL: What They Mean for Your Site
Understand how DNS caching works at every level, what TTL values mean, how to choose the right TTL, and best practices for faster propagation.
Last updated: 2026-02-17
Every DNS lookup involves multiple systems working together to translate a domain name into an IP address. Without caching, every single page load, API call, and email delivery would require a full trip through the DNS hierarchy, from root servers down to authoritative nameservers. That would be slow, expensive, and would overwhelm DNS infrastructure globally.
Caching solves this by storing DNS responses temporarily so that repeated queries for the same domain are answered locally. The TTL (Time to Live) value controls how long each cached response remains valid.
Understanding how caching and TTL work together is essential for planning DNS changes, diagnosing propagation issues, and optimizing your site's DNS performance.
What TTL Actually Is
TTL is a value, measured in seconds, attached to every DNS record. It tells any system that caches the record how long to keep it before discarding the cached copy and fetching a fresh one from the authoritative nameserver.
When you set a TTL of 3600 on an A record, you are saying: "After you look up this record, you can use the cached answer for 3600 seconds (1 hour). After that, query the authoritative server again."
example.com. 3600 IN A 93.184.216.34
In this example, 3600 is the TTL. Every resolver that queries this record will cache the answer and reuse it for up to one hour.
TTL is set by the zone owner, enforced by resolvers
You control the TTL value in your DNS zone. But you depend on recursive resolvers (ISPs, Google DNS, Cloudflare DNS, etc.) to respect it. Most do, but some impose minimum or maximum cache durations regardless of what your TTL says.
Where DNS Gets Cached
DNS caching happens at multiple layers between the user and your authoritative nameserver. Each layer has its own behavior.
Browser Cache
Modern browsers maintain their own DNS cache. Chrome caches DNS lookups for up to 60 seconds by default. Firefox and Safari have similar behavior. This cache exists entirely within the browser process, so different browsers on the same machine may have different cached values.
Browser DNS caches are not configurable by the domain owner. They use short internal TTLs regardless of the authoritative TTL. Closing and reopening the browser typically clears this cache.
Operating System Cache
The OS stub resolver caches DNS lookups and serves them to all applications on the machine. On Windows, the DNS Client service manages this cache. On macOS, mDNSResponder handles it. On Linux, systemd-resolved or nscd may provide caching depending on the distribution.
The OS cache generally respects the TTL from the DNS response, though it may have minimum or maximum bounds. This is the cache you clear with:
- Windows:
ipconfig /flushdns - macOS:
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder - Linux:
sudo systemd-resolve --flush-caches(varies by distribution)
Recursive Resolver Cache
This is the most significant caching layer. Recursive resolvers (also called caching resolvers) sit between end users and the authoritative nameservers. Major public resolvers include Google Public DNS (8.8.8.8), Cloudflare (1.1.1.1), and Quad9 (9.9.9.9). ISPs also operate their own resolvers for their customers.
These resolvers cache records strictly according to TTL (with some exceptions). Because they serve millions of users, a single cached entry prevents millions of redundant queries to your authoritative server.
Recursive resolver caching is the bottleneck
When people talk about DNS propagation time, they are primarily talking about how long recursive resolvers hold onto cached records. This is the layer where TTL has the most practical impact on how quickly DNS changes take effect.
Authoritative Nameserver
Your authoritative nameservers do not cache in the traditional sense. They serve the current version of your records from the zone file or database. When you update a record, the authoritative server reflects the change immediately. The delay is entirely in downstream caches.
How TTL Affects DNS Changes
When you change a DNS record, the new value is immediately available on your authoritative nameserver. But every recursive resolver that previously queried the old record is still serving the cached old value until the TTL expires.
This is why TTL directly controls your propagation time. The relationship is straightforward:
| TTL Value | Seconds | Propagation Window |
|---|---|---|
| Very short | 60–300 | 1–5 minutes |
| Short | 300–900 | 5–15 minutes |
| Medium | 3600 | 1–2 hours |
| Long | 14400 | 4–6 hours |
| Very long | 86400 | 24–48 hours |
The important detail: it is the previous TTL that matters, not the new one you set during the change. If your old record had a TTL of 86400 and you change the record while also lowering the TTL to 300, resolvers that cached the old record will still hold it for up to 86400 seconds.
Choosing the Right TTL
TTL is a tradeoff between DNS query performance and change responsiveness.
Lower TTL (60–300 seconds)
Changes propagate quickly. Ideal for records that may need to change in an emergency (failover scenarios) or during planned migrations. The tradeoff is more frequent queries to your authoritative nameserver, which means slightly more DNS traffic and marginally higher lookup latency for some users.
Medium TTL (3600 seconds)
A common default that balances query efficiency with reasonable propagation time. Good for records that change infrequently but might need to change during planned maintenance windows.
Higher TTL (14400–86400 seconds)
Reduces DNS query load significantly. Suitable for records that rarely or never change, such as NS records or MX records for a well-established email provider. The tradeoff is that unplanned changes take hours to propagate.
Track TTL changes across all your records
DNS Monitor detects when TTL values change and tracks how records propagate across global resolvers. Know exactly when your DNS changes take effect.
The TTL Lowering Strategy
The most important TTL best practice is lowering it before a planned DNS change. This is the standard approach used by experienced DNS administrators.
Check the current TTL
Before you plan a change, check the current TTL on the record you intend to modify. If it is 3600 or higher, you need to lower it in advance.
Lower TTL at least one full TTL period in advance
If your current TTL is 3600 (1 hour), lower it to 300 at least 1 hour before your planned change. This ensures all resolvers have cached the record with the new short TTL by the time you make the actual change.
Wait for the old TTL to expire
After lowering the TTL, wait at least as long as the old TTL value. If the old TTL was 3600, wait at least 1 hour. This is the time it takes for all resolvers to pick up the shorter TTL.
Make your DNS change
Now when you change the record value, resolvers will only hold the old value for the duration of the new short TTL (e.g., 300 seconds). Propagation completes in minutes.
Raise TTL after confirming the change
Once you've verified the change has propagated and everything is working, raise the TTL back to your preferred long-term value. This reduces ongoing DNS query load.
TTL Best Practices
Match TTL to Change Frequency
Records that never change (like NS records for a stable DNS provider) can have long TTLs. Records that might need to change in an emergency (like A records for a web server) should have shorter TTLs.
Don't Set TTL to Zero
A TTL of 0 means "do not cache." While technically valid, it forces a full DNS resolution for every single request. This adds latency to every page load and puts unnecessary load on your authoritative servers. Some resolvers treat TTL 0 as a minimum of 30 or 60 seconds anyway.
Be Aware of Minimum TTL Enforcement
Some recursive resolvers enforce minimum TTL values. For example, a resolver might treat any TTL below 30 seconds as 30 seconds. This is done to protect against excessive query rates. In practice, setting your TTL to 300 seconds works well as a floor value that all resolvers will respect.
Consider Negative TTL
The SOA record's minimum TTL field (sometimes called negative TTL) controls how long resolvers cache NXDOMAIN responses, which are responses indicating a name does not exist. If you plan to create a new subdomain, be aware that resolvers may have cached a negative response for that name.
TTL and DNS Monitoring
Monitoring TTL values is part of comprehensive DNS monitoring. Changes to TTL that you didn't make can indicate:
- Someone preparing for a DNS change (lowering TTL)
- A DNS provider resetting records to defaults
- An attacker lowering TTL before modifying records (to limit the window where the old, correct value is cached)
Unexplained TTL changes should be investigated with the same urgency as record value changes.
Common TTL Mistakes
Changing Records Without Lowering TTL First
This is the most common mistake. You change an A record that has a 24-hour TTL, then wonder why some users are still seeing the old site a day later. The fix is always to lower TTL in advance.
Assuming All Resolvers Behave the Same
Different resolvers have different caching behaviors. Some ISP resolvers are known to cache records longer than the TTL specifies. Google Public DNS and Cloudflare DNS are generally well-behaved, but the resolvers your users actually use may not be.
Forgetting About Multiple Caching Layers
Flushing your local DNS cache does not affect the recursive resolver's cache. When testing DNS changes, query the authoritative server directly or use tools that bypass local caching.
DNS caching and TTL are the mechanisms that make DNS fast and scalable, but they also determine how quickly changes propagate. Mastering TTL management is the key to making DNS changes predictable and minimizing disruption.
Monitor DNS caching and propagation globally
DNS Monitor checks your records from multiple locations, tracks TTL changes, and confirms propagation. Never wonder if your DNS change has taken effect.