What TTL Means in DNS
TTL — Time to Live — is a field present on every DNS resource record, as specified in RFC 1035. Its value is a non-negative integer representing a number of seconds. When a recursive resolver fetches a record from your authoritative nameserver, it caches that record locally and serves it to any client that queries for the same record within the TTL window. Once the TTL expires, the cached copy is discarded and the resolver fetches a fresh copy the next time a client asks.
A practical example: if your A record for example.com has a TTL of 3600, a resolver that fetches it at 09:00 will serve the cached value to every client until 10:00. At 10:00 (or the next query after 10:00), it fetches again from your authoritative nameserver. If you update the record at 09:05, the resolver — and every client behind it — will continue receiving the old value until 10:00. There is no mechanism to push the update early.
TTL is set at the individual record level in your DNS zone file or control panel. Different records for the same domain can — and often should — carry different TTL values.
ℹ️ Note: TTL is distinct from the SOA record's minimum TTL field. The SOA minimum TTL (the last field in the SOA record) controls negative caching — how long resolvers cache NXDOMAIN responses when a record doesn't exist, as defined in RFC 2308. Use our SOA Lookup to inspect both values for your zone.
How TTL Interacts with Caching Resolvers
Understanding the caching behaviour at resolvers is essential for setting TTL values correctly, because the TTL you set is a ceiling — resolvers may cache for less, but never for more (with the exception of non-compliant ISP resolvers that override TTL, which is a known edge case covered in our DNS Propagation guide).
When a resolver caches a record, it starts a countdown from the TTL value. On the next query:
- If the countdown hasn't reached zero: the resolver returns the cached record along with the remaining TTL (not the original). A client querying a record with
TTL 3600five minutes after the resolver cached it will receiveTTL 3300. - If the countdown has reached zero: the resolver treats the cache entry as stale, fetches a fresh copy from your authoritative nameserver, and restarts the countdown.
This countdown behaviour is visible in dig output and is an important diagnostic tool — the TTL remaining tells you exactly how recently the resolver fetched the record.
# Query Google's resolver and observe the TTL in the ANSWER section
dig example.com A @8.8.8.8
# ;; ANSWER SECTION:
# example.com. 847 IN A 93.184.216.34
# ^^^
# Remaining TTL — this resolver cached the record 2753 seconds ago
# (original TTL was 3600)
# Query your authoritative nameserver for the original TTL
dig example.com A @ns1.yourprovider.com
# ;; ANSWER SECTION:
# example.com. 3600 IN A 93.184.216.34
# ^^^^
# Full TTL — authoritative answer always shows the configured value
The TTL returned by your authoritative nameserver is always the full configured value. The TTL returned by a recursive resolver decrements with each passing second.
TTL Values for Different Record Types
Not all DNS records should carry the same TTL. Records that change frequently need low TTL for fast propagation. Records that rarely change should carry higher TTL to reduce query load and improve resilience. Records that control critical infrastructure warrant extra care.
| Record Type | Recommended TTL | Reasoning |
|---|---|---|
A (standard web/app) | 3600 (1 hour) | Balance between propagation speed and query load |
A (pre-migration) | 300 (5 minutes) | Temporary reduction; allows fast failover or cutover |
AAAA | Same as corresponding A | IPv6 address records follow the same logic as A records |
CNAME | 3600 (1 hour) | Should match the TTL of the record it points to |
MX | 3600–14400 | Mail routing changes are rare; higher TTL reduces query load |
TXT (SPF, DMARC) | 3600 | Authentication records change rarely; 1 hour is safe |
TXT (domain verification) | 300–3600 | Can be lowered if verification needs to be updated quickly |
NS | 86400 (24 hours) | NS records must match parent zone; slow to change by design |
SOA | 3600–86400 | Controlled by your DNS provider; rarely needs manual adjustment |
CAA | 3600–86400 | Certificate authority policy; changes infrequently |
SRV | 3600 | Service records; balance with anticipated change frequency |
PTR | 86400 | Reverse DNS; rarely changes; controlled by IP block owner |
⚠️ Warning: NS record TTL is primarily controlled by the parent zone (your registrar or TLD registry), not by your own zone file. The NS records in your own zone should match the parent zone, but the TTL on the parent zone's NS records is set by the registry. You cannot directly control how quickly nameserver changes propagate at the registry level.
The Right TTL for Each Use Case
Beyond record type, the right TTL depends on how frequently the record changes and how quickly you need changes to take effect.
| Use Case | Recommended TTL | Notes |
|---|---|---|
| Stable production site, no planned changes | 3600–86400 | Higher TTL reduces query volume; improves cache hit rate |
| Active development environment | 300–600 | Records change frequently; low TTL reduces stale cache incidents |
| CDN-served content with anycast routing | 60–300 | CDN routing decisions need fast propagation; most CDN providers recommend low TTL |
| Migration preparation (48–72 hours before change) | 300 | Must be lowered before making the actual record change |
| Failover A records (primary/backup pair) | 60–300 | Fast failover requires low TTL; weigh against query load increase |
| Email (MX records) | 3600–14400 | Mail delivery tolerates longer propagation; higher TTL is fine |
| DMARC / SPF (TXT records) | 3600 | Authentication records don't change often; 1 hour is appropriate |
| Wildcard records | Same as equivalent specific record | Wildcard TTL applies the same caching rules |
The Pre-Migration TTL Strategy
This is the single most important TTL practice for anyone who manages DNS changes on production infrastructure. The principle is simple: lower your TTL well before making a change, wait for the old TTL to expire, then make the change.
The reason this sequencing matters is often misunderstood. Lowering your TTL and immediately making the record change does almost nothing — resolvers are already caching the old record with the old (high) TTL and won't respect the new lower TTL until their existing cache entry expires.
The correct sequence:
-
Check the current TTL on the record you plan to change. Use
digor DNS Lookup to confirm the value. -
Lower the TTL to 300 (5 minutes) at least 24–48 hours before your planned change window. If the current TTL is 86400 (24 hours), you need to wait a full 24 hours after lowering it before all resolvers will have expired their cached copies and fetched the new low TTL.
-
Wait for the full duration of the old TTL. This is the step most teams skip. If your record had TTL 86400, you must wait 24 hours after lowering it. Resolvers that cached the record 1 minute before you lowered the TTL will hold the old value — with the old high TTL — for nearly another 24 hours.
-
Make your DNS change during the planned window. With TTL now at 300, all resolvers will pick up the new value within 5–10 minutes of their next cache expiry.
-
Monitor propagation using the DNS Propagation Checker to confirm the new record is visible across global resolver vantage points.
-
Restore the TTL to a normal value (3600 or higher) after confirming the change is fully propagated and stable. Running indefinitely at TTL 300 increases query load on your authoritative nameserver unnecessarily.
# Step 1: Check current TTL before lowering
dig example.com A +short
dig example.com A | grep -A1 "ANSWER SECTION"
# Step 4 (after waiting): Verify the change is live on your auth NS
dig example.com A @ns1.yourprovider.com +short
# Step 5: Check propagation across public resolvers
dig example.com A @8.8.8.8 +short
dig example.com A @1.1.1.1 +short
dig example.com A @9.9.9.9 +short
💡 Tip: Calendar the TTL reduction 48–72 hours before any planned migration or cutover. Teams that do this as routine practice never experience the "why is it still not propagated after 30 hours" incident — because their TTL is 300 by the time they make the change.
For the full DNS migration workflow that this TTL strategy fits into, see our DNS Migration Without Downtime guide.
What Happens If You Set TTL Too Low?
Very low TTLs (under 60 seconds) are sometimes used for ultra-fast failover configurations, but they come with real trade-offs that are worth understanding before committing.
Increased query load on your authoritative nameserver. Every resolver that queries your record must re-fetch it once per TTL window. At TTL 60, a resolver serving 10,000 users for your domain makes 1,440 authoritative queries per day for that single record. At TTL 3600, it makes 24. For high-traffic domains with many records, extremely low TTLs can meaningfully increase authoritative query volume.
Reduced resilience during authoritative nameserver outages. If your authoritative nameserver becomes unreachable, cached records act as a buffer — resolvers continue serving the cached value until the TTL expires. At TTL 60, that buffer is 60 seconds. At TTL 3600, it's an hour. During an authoritative NS outage, high TTL keeps your site accessible; low TTL means resolver caches drain quickly and your site becomes unreachable.
Some resolvers enforce a minimum TTL floor. Public resolvers including some ISP-operated resolvers may enforce a minimum cache duration regardless of the TTL you set — commonly 60 or 120 seconds. Setting TTL 10 will not actually result in 10-second propagation on those resolvers.
The practical guidance: use TTL 300 (5 minutes) as your minimum for production records except in specific failover architectures designed around it. Use TTL 60 only if you have a genuine operational need for sub-minute DNS updates and have confirmed your authoritative nameserver can handle the query volume.
What Happens If You Set TTL Too High?
The cost of TTL-too-high is slower propagation for any record change — and it accumulates silently over time as teams set high TTLs and forget about them.
The propagation delay compounds with the TTL you had before a change. A record with TTL 604800 (7 days) that you need to change urgently will take up to 7 days to fully propagate worldwide. Any emergency infrastructure change becomes an extended incident.
Some DNS control panels default to high TTL values. When you add a new record and don't specify a TTL, many providers default to 3600 or even 14400. Check the TTL on every record you create, not just the ones you're actively changing.
High TTL on TXT records can slow email authentication changes. If you need to update an SPF record or rotate a DKIM key and your TXT records have TTL 86400, you're waiting up to 24 hours for the change to reach all receiving mail servers. This extends any email authentication incident unnecessarily.
The practical guidance: 3600 (1 hour) is a safe default for most production records on stable infrastructure. It provides reasonable propagation speed without excessive query load. Avoid values above 86400 on any record you might reasonably need to change on short notice.
How to Check and Change Your Current TTL
Check TTL via dig
# Check TTL on your authoritative nameserver (shows configured value)
dig example.com A @ns1.yourprovider.com
# Check TTL as seen by a public resolver (shows remaining cache time)
dig example.com A @8.8.8.8
# Check TTL for all record types at once
dig example.com ANY @ns1.yourprovider.com
# Check the SOA record minimum TTL (negative caching TTL)
dig example.com SOA @ns1.yourprovider.com +short
# Last field in output is the minimum TTL
Check TTL via DNS Lookup
Use our DNS Lookup tool to query any record type for any domain and inspect the TTL in the response — no command line required. Select the record type, enter your domain, and the TTL column in the results shows the current configured value.
Change TTL in your DNS control panel
The process varies by DNS provider, but is typically:
- Log in to your DNS control panel
- Navigate to the zone for your domain
- Find the record you want to modify
- Edit the record — the TTL field is usually alongside the record value
- Save the change
Some providers display TTL as a dropdown with human-readable options (5 minutes, 1 hour, 24 hours). Others accept a raw integer in seconds. Both refer to the same field.
After lowering TTL, always confirm the change took effect by querying your authoritative nameserver directly and verifying the TTL in the answer section matches your intended value.
Frequently Asked Questions
Q: What is a good default TTL for DNS records?
For most production records on stable infrastructure, 3600 seconds (1 hour) is a sensible default. It gives a reasonable propagation window for planned changes while keeping query load manageable. Lower to 300 before planned changes; restore to 3600 afterward. For MX records and other records that change rarely, 14400 (4 hours) is fine.
Q: Does TTL affect how quickly Google re-crawls my site after a DNS change?
TTL affects how quickly resolvers — including Google's resolvers — pick up DNS changes. After Googlebot's resolver updates its cache, subsequent crawls will use the new IP. However, Google's crawl scheduling is independent of DNS TTL — lowering TTL speeds up DNS propagation but doesn't force a crawl. DNS changes with low TTL will be visible to Googlebot quickly once its resolver cache expires.
Q: I lowered my TTL but propagation is still slow — what's happening?
Almost certainly, you lowered the TTL before waiting for the old high TTL to expire. Resolvers that cached your record before you lowered the TTL are still holding the old value with the old (high) TTL. They won't check for the new low TTL until their existing cache entry expires. The wait time is the old TTL value minus the time elapsed since those resolvers last cached it. In the worst case, you wait for the full old TTL duration.
Q: Can I set a different TTL for each DNS record?
Yes, and you should. Different records have different change frequencies and different operational requirements. A and AAAA records that serve web traffic typically use 3600. MX records that rarely change can use 14400. TXT records for SPF and DMARC authentication stay at 3600. NS records follow the parent zone's TTL. Setting the same TTL on every record regardless of type is a missed optimisation.
Q: What is the minimum TTL I can set?
Technically, TTL 0 is valid per the DNS specification, meaning "do not cache." In practice, most DNS providers enforce a minimum (often 60 or 300 seconds). Some public resolvers also ignore TTL values below their own floor. TTL 300 is the lowest value worth using in production; TTL 0 will be ignored or floor-clamped by most infrastructure.
Q: Does lowering TTL affect my site's performance?
In most cases, no. The performance impact of TTL on DNS resolution is minimal for end users — DNS lookups are typically sub-millisecond from a warm resolver cache regardless of TTL. The impact of very low TTL is primarily on your authoritative nameserver (more queries) and on resilience during outages (smaller buffer). For most production sites, the difference between TTL 300 and TTL 3600 is imperceptible to end users.
Next Steps
If you're preparing for an upcoming DNS migration and want to apply the pre-migration TTL strategy to a full cut-over workflow, read our DNS Migration Without Downtime guide for the complete phase-by-phase playbook.
To see how TTL values interact with real-world propagation timelines and why different resolvers see different values at the same moment, see our How DNS Propagation Works guide.
Check your current record TTLs using DNS Lookup or verify the propagation status of a recent change with the DNS Propagation Checker.
Browse all DNS guides on DNSnexus for related topics.