DNS TTL Explained: How to Choose the Right Value

What TTL Is

TTL stands for Time to Live. In DNS, it is a value measured in seconds that tells caching systems how long they can store a DNS response before they must discard it and fetch a fresh copy from the authoritative nameserver.

Every DNS record has a TTL. When a recursive resolver looks up your A record and gets the answer, the TTL tells it: "You can reuse this answer for X seconds. After that, ask again."

example.com.    3600    IN    A    93.184.216.34

In this record, 3600 is the TTL. Any resolver that queries this record will cache the result for up to 3,600 seconds (1 hour).

TTL is set by the person who manages the DNS zone. You control it. But you depend on resolvers around the world to respect it. For the full picture on DNS fundamentals, see our complete DNS guide. For a deeper look at how caching and TTL interact, see DNS caching and TTL.

How Caching Works at Each Level

DNS responses are cached at multiple layers between the end user and your authoritative nameserver. Understanding where caching happens helps you predict how TTL changes will behave in practice.

Browser Cache

Web browsers maintain their own small DNS cache. Chrome, Firefox, and Safari all cache DNS lookups for short periods, typically 60 seconds or less, regardless of the record's actual TTL. This cache is internal to the browser process and is not configurable through DNS settings.

You cannot control the browser cache via TTL. It exists for performance optimization at the application level. Closing and reopening the browser clears it.

Operating System Cache

The operating system's stub resolver caches DNS lookups and serves them to all applications running on the machine. On Windows, this is the DNS Client service. On macOS, it is mDNSResponder. On Linux, systemd-resolved or nscd may handle caching depending on the distribution.

The OS cache generally respects the TTL from the DNS response, though some implementations enforce minimum or maximum cache durations. When users flush their DNS cache (e.g., ipconfig /flushdns on Windows), they are clearing this layer.

Recursive Resolver Cache

This is the most important caching layer for TTL purposes. Recursive resolvers (also called caching resolvers) sit between end users and your authoritative nameservers. They serve millions of users and cache records according to the TTL value.

Major public recursive resolvers include:

• Google Public DNS (8.8.8.8, 8.8.4.4)
• Cloudflare DNS (1.1.1.1, 1.0.0.1)
• Quad9 (9.9.9.9)
• ISP resolvers (assigned automatically to their customers)

When someone on Google's DNS looks up your domain, Google caches the response for the duration of the TTL. Every subsequent query from any Google DNS user for the same record is served from cache until the TTL expires. This is the layer where TTL has the greatest practical impact.

What Authoritative Nameservers Do

Your authoritative nameserver does not cache in the traditional sense. It serves the current state of your zone. When you update a record, the authoritative server reflects the change immediately. The delay you experience after making a DNS change is entirely due to downstream caches holding the old value until the TTL expires.

Common TTL Values and When to Use Each

There is no single correct TTL. The right value depends on how often the record changes, how critical fast changes are, and what tradeoffs you are willing to accept.

60-300 Seconds (1-5 Minutes)

Use very short TTLs for records behind active failover systems. If you use a DNS-based load balancer or failover service that needs to redirect traffic within minutes of a failure, TTL must be short enough that resolvers pick up the change quickly.

The tradeoff is higher query volume on your authoritative nameservers. Every resolver must re-query every few minutes instead of caching for hours. For most zones this is manageable, but it adds load.

Good for: Failover configurations, A/B testing, gradual traffic migration, records you plan to change soon.

300-900 Seconds (5-15 Minutes)

A practical default for most production A and CNAME records. This gives you a reasonable propagation window (under 15 minutes) without putting excessive load on your nameservers. If something goes wrong, you can update the record and expect most users to see the change within 15 minutes.

Good for: Web servers, API endpoints, most production services.

3,600 Seconds (1 Hour)

A common default that balances caching efficiency with change flexibility. Many DNS providers set this as the default TTL for new records. It works well for records that are stable but might occasionally need updating, such as when migrating to a new server.

Good for: Stable production records, records that change a few times per year.

14,400-43,200 Seconds (4-12 Hours)

Use longer TTLs for records that rarely change. NS records pointing to your DNS provider, MX records for a stable email service, and TXT records for established SPF/DKIM configurations are good candidates.

Good for: NS records, MX records for established email setups, verification TXT records that are permanent.

86,400 Seconds (24 Hours) and Above

Reserve very long TTLs for records that effectively never change. Your domain's NS records at the registrar level, for example, should almost never change. A 24-hour or longer TTL reduces query volume to a minimum.

Good for: NS delegation records, records that have not changed in years and are not expected to change.

Lowering TTL Before Making Changes

This is the single most important TTL practice: lower the TTL well in advance of a planned DNS change.

Here is why. Suppose your A record has a TTL of 86,400 seconds (24 hours). You update the IP address. Every resolver that queried your record in the last 24 hours is still caching the old IP. It could take up to 24 hours before all resolvers fetch the new value. During that window, some users reach the old server and some reach the new one.

The fix is straightforward:

Step 1: Lower the TTL

At least 24-48 hours before the planned change (longer than the current TTL), reduce the TTL to 300 seconds or less.

Step 2: Wait for the Old TTL to Expire

If your old TTL was 86,400 seconds, you need to wait at least 86,400 seconds after lowering it. This ensures all caches have expired the old high-TTL record and fetched the new low-TTL version.

Step 3: Make the Change

Now when you update the record, the maximum propagation time is 300 seconds (or whatever you set the low TTL to).

Step 4: Verify Propagation

Use DNS lookup tools to verify the change has propagated to major resolvers. See our guide on checking DNS propagation for specific tools and techniques.

Step 5: Raise the TTL

Once the change is confirmed and stable, raise the TTL back to your normal value. There is no reason to leave it low permanently unless you need ongoing fast-change capability.

TTL and Propagation Speed

"DNS propagation" is really just TTL expiration across the world's recursive resolvers. There is no broadcast mechanism that pushes DNS changes to all resolvers. Each resolver discovers the change independently when its cached copy expires and it queries the authoritative server for a fresh answer.

This means:

• Propagation time is bounded by TTL. If your TTL is 3,600 seconds, the maximum propagation time is 3,600 seconds (assuming all resolvers respect the TTL).
• Propagation is not instantaneous even with low TTL. A 60-second TTL means most resolvers will pick up the change within 60 seconds, but some may have queried 1 second before you made the change and will hold the old value for another 59 seconds.
• Some resolvers do not fully respect TTL. A few ISP resolvers impose minimum cache durations regardless of your TTL. Setting a TTL of 60 seconds does not guarantee that every resolver worldwide will re-query within 60 seconds.

For a detailed explanation of how propagation works, see DNS propagation explained.

TTL for Different Record Types

Different record types benefit from different TTL strategies.

• A and AAAA records: Match TTL to your failover requirements. 300 seconds for fast failover, 3,600 for stable servers.
• CNAME records: Same logic as A records. Keep in mind that CNAME lookups involve multiple queries, so very short TTLs increase total resolution time.
• MX records: Mail server changes are infrequent and the consequences of a wrong MX record are severe. Use 3,600-14,400 seconds and lower well in advance of changes.
• TXT records: SPF, DKIM, and DMARC records rarely change once configured. A TTL of 3,600-14,400 seconds works well.
• NS records: Should have long TTLs (86,400+ seconds). DNS provider changes are rare.
• SOA minimum TTL: Controls how long resolvers cache NXDOMAIN responses. Keep it short if you frequently create new subdomains.

Monitoring TTL Behavior

TTL changes can be an indicator of DNS issues or even attacks. Monitoring your DNS records should include tracking TTL values, not just record data.

Unexpected TTL changes could indicate:

• Someone preparing for a DNS change (lowering TTL as a preparatory step)
• A DNS provider resetting records to defaults after a configuration change
• An attacker lowering TTL before modifying records (to limit the window where the legitimate value is cached and to ensure the malicious value propagates quickly)

If your TTL changes without a corresponding planned change, investigate immediately. DNS monitoring tools that track TTL values alongside record data provide this visibility. Learn more about how to check DNS records to verify your current TTL values.

Common TTL Mistakes

Setting TTL too low permanently. A 60-second TTL on all records "just in case" creates unnecessary query volume and adds latency. Set TTL appropriately for each record and lower it temporarily only when needed.

Forgetting to raise TTL after a change. A low TTL left indefinitely wastes resources and provides no benefit once the change is stable.

Assuming TTL controls everything. Some resolvers enforce minimum cache durations regardless of your TTL. Browser and OS caches operate on their own schedules. TTL is the primary control, but it is not absolute.

Changing records without waiting for the old TTL to expire. If you lower your TTL from 86,400 to 300, you must wait at least 86,400 seconds before making the actual record change. Otherwise resolvers still holding the old high-TTL entry will serve stale data.

Ignoring negative TTL. The SOA minimum TTL controls how long NXDOMAIN responses are cached. If set to 86,400 and you create a new subdomain, resolvers may cache the "does not exist" response for up to 24 hours.

Key Takeaways

• TTL is measured in seconds and controls how long DNS responses are cached by recursive resolvers.
• Caching happens at multiple layers: browser, OS, and recursive resolver. The recursive resolver cache is the most significant.
• Choose TTL based on how frequently the record changes and how fast you need changes to propagate.
• Always lower TTL well in advance of a planned DNS change, then raise it afterward.
• Monitor TTL values as part of DNS monitoring. Unexpected changes can indicate problems or attacks.
• There is no one-size-fits-all TTL. Use short values for dynamic records, medium for stable production records, and long for records that rarely change.

References

• Mockapetris, P., "Domain Names: Implementation and Specification" (RFC 1035), https://datatracker.ietf.org/doc/html/rfc1035
• Cloudflare, "DNS TTL: What It Is and How It Works," https://www.cloudflare.com/learning/cdn/glossary/time-to-live-ttl/
• Google Public DNS, "Caching and Performance," https://developers.google.com/speed/public-dns/docs/performance