What Is DNS TTL? How Time to Live Controls Caching, Propagation, and Performance

TTL stands for Time to Live. In DNS, it is a value (measured in seconds) attached to every DNS record that tells resolvers how long they can cache that record before they must discard it and fetch a fresh copy from the authoritative nameserver. A TTL of 3600 means the record can be cached for one hour. A TTL of 300 means five minutes.

TTL is one of the most important DNS settings you will deal with, and it is frequently misunderstood. It directly controls how fast DNS changes propagate, how much load your nameservers handle, and how resilient your domain is to certain types of attacks. Getting it right is a balancing act between speed, performance, and reliability.

How TTL Works

Every DNS record has a TTL value set by the zone administrator:

example.com.    3600    IN    A    93.184.216.34
;               ^^^^
;               TTL = 3600 seconds (1 hour)

When a recursive resolver queries this record for the first time, it caches the response and starts a countdown from 3600 seconds. For the next hour, any client asking this resolver for example.com gets the cached answer instantly — no query to the authoritative server is needed.

When the countdown reaches zero, the cached entry expires. The next query triggers a fresh lookup from the authoritative server, and the cycle starts again with a new TTL countdown.

Time 0:00  — Resolver queries authoritative server, caches with TTL=3600
Time 0:01  — Client asks → served from cache (TTL remaining: 3599)
Time 0:30  — Client asks → served from cache (TTL remaining: 3570)
Time 1:00  — Cache expires, next query goes to authoritative server

TTL at Every Level

TTL applies at every layer of the DNS hierarchy:

• Root servers have TTLs of 48 hours (172800 seconds) for NS records
• TLD servers typically use TTLs of 24-48 hours
• Your authoritative records use whatever TTL you set (commonly 300-86400 seconds)
• Negative responses (NXDOMAIN) are cached according to the SOA minimum TTL

Resolvers also have their own minimum and maximum cache limits. Some enforce a minimum of 30-60 seconds even if you set TTL to 0, and some cap the maximum at 24-48 hours even if you set TTL to a week.

Common TTL Values and When to Use Them

When to Use Low TTL (60-300 seconds)

During a migration. If you are moving to a new hosting provider or changing IP addresses, lower your TTL to 300 seconds (or less) at least 24-48 hours before the change. This ensures that when you update the record, resolvers worldwide will pick up the new value within minutes instead of hours.

# Step 1: Lower TTL (do this 24-48 hours BEFORE the migration)
example.com.    300    IN    A    93.184.216.34

# Step 2: Wait for old TTL to expire everywhere

# Step 3: Change the IP
example.com.    300    IN    A    198.51.100.10

# Step 4: After migration is confirmed, raise TTL back
example.com.    3600   IN    A    198.51.100.10

For a detailed walkthrough, see How to Verify DNS Changes After Switching Hosts.

For failover. If you use DNS-based failover (where the IP changes when a server goes down), a low TTL ensures clients switch to the backup server quickly.

For load balancing. Round-robin DNS with low TTL distributes traffic more evenly because clients re-resolve frequently.

When to Use High TTL (3600-86400 seconds)

For stable records. If your IP address rarely changes, a high TTL reduces the number of queries hitting your authoritative server and speeds up resolution for users (cached responses are instant).

For NS records. Nameserver delegation records should have high TTLs (24-48 hours) because changing nameservers is rare and you want the delegation to be resilient against temporary nameserver outages.

For performance. Every cache hit avoids a round-trip to your nameserver. For a busy domain, the difference between a 300-second TTL and a 3600-second TTL can be millions of queries per day.

TTL and DNS Propagation

"DNS propagation" is really just caches expiring. When you change a DNS record, the old value remains cached at resolvers worldwide until their TTL countdown reaches zero. There is no push mechanism — resolvers do not get notified of changes.

This is why DNS changes are not instant and why "propagation time" varies:

• If the old record had a TTL of 300 seconds, most resolvers will pick up the change within 5 minutes
• If the old TTL was 86400 seconds (24 hours), some resolvers will serve the old value for up to a day

The propagation delay is determined by the old TTL — the one that was in effect before you made the change. This is why lowering TTL before a migration is critical: you need the low TTL to be cached everywhere before the actual change.

Use the Propagation Checker to monitor how your changes are spreading across resolvers worldwide.

For a deeper dive into propagation mechanics and myths, see What Is DNS Propagation? and DNS Propagation Myths Debunked.

TTL and Security

TTL has security implications that are often overlooked:

Cache Poisoning Window

A higher TTL means a poisoned cache entry persists longer. If an attacker successfully poisons a resolver's cache for your domain and your TTL is 86400, every user of that resolver is redirected to the attacker's server for up to 24 hours. A lower TTL limits the damage window — but also means more frequent queries to your authoritative server, which increases the number of opportunities for the attacker to attempt poisoning.

Fast Flux Detection

Malicious fast flux networks use extremely low TTLs (60-300 seconds) to rapidly rotate the IP addresses behind a domain. If you see a domain with consistently low TTL and IPs that change on every query across many different ASNs and countries, it is a strong indicator of fast flux.

DDoS Resilience

Higher TTLs improve resilience against DDoS attacks on your authoritative nameservers. If your nameservers are under attack but your TTL is 3600 seconds, resolvers that queried within the last hour still have valid cached data and will continue serving your domain normally. A low TTL means resolvers must query your (potentially unreachable) nameservers more frequently.

How to Check Your Current TTL

# Check the TTL for a specific record
dig example.com A

# The TTL is the number in the answer section
;; ANSWER SECTION:
example.com.    2847    IN    A    93.184.216.34
;               ^^^^
;               2847 seconds remaining in this resolver's cache

Note that the TTL shown by dig is the remaining TTL from the resolver's cache, not the original value set on the authoritative server. To see the authoritative TTL, query the nameserver directly:

dig example.com A @ns1.example.com

You can also use the DNS Inspector to view the TTL for all record types on your domain.

How to Set TTL

TTL is configured at your DNS provider or in your zone file. The exact method depends on your provider:

• Cloudflare: Each record has a TTL dropdown (or "Auto" which Cloudflare manages)
• Route 53: TTL is a field when creating or editing records
• BIND zone file: TTL appears as a number before the record class

; BIND zone file example
$TTL 3600                              ; Default TTL for the zone
example.com.    IN    SOA    ns1.example.com. admin.example.com. (
                    2025081201  ; Serial
                    3600        ; Refresh
                    900         ; Retry
                    604800      ; Expire
                    300         ; Negative cache TTL
                )
example.com.    3600    IN    A     93.184.216.34
www             300     IN    CNAME example.com.

The $TTL directive sets the default for all records in the zone. Individual records can override it.

Common TTL Mistakes

• Not lowering TTL before a migration. Changing your IP with a 24-hour TTL means some users will not see the change for a day. Lower TTL to 300 seconds at least 24-48 hours before the change.
• Setting TTL too low permanently. A 60-second TTL on a stable record wastes resources — your nameserver handles 60x more queries than with a 3600-second TTL, and every user experiences a slight delay when the cache expires.
• Setting TTL too high on dynamic records. If your IP might change (cloud instances, failover), a 24-hour TTL means a failure takes up to 24 hours to recover via DNS.
• Forgetting to raise TTL after a migration. Leaving TTL at 300 seconds after a successful migration means unnecessary query load and slightly slower resolution for users.
• Ignoring the SOA minimum TTL. The SOA record's minimum field controls how long NXDOMAIN responses are cached. If it is too high, deleted subdomains will continue returning "does not exist" from caches long after you create them.

For more foundational DNS knowledge, see Understanding DNS Record Types and What Is DNS Propagation?. For security implications of TTL, see the Complete Guide to DNS Attacks and DNS Security.