Guides · DNS
DNS TTL Explained — What Is TTL in DNS & How to Set It
DNS TTL (time to live) tells resolvers how long to cache a DNS record. Learn what TTL means in DNS, sensible default TTL values, and how to set TTL before a migration.
By Cody · 5 min read · Published · Updated
What TTL actually is
TTL in DNS — Time To Live — is the number of seconds a DNS resolver is allowed to cache a record before re-asking the authoritative server. Every record carries its own TTL, set by the zone owner, and it is the one value that decides how fast a DNS change reaches the rest of the internet.
When you set a TTL of 300 on an A record, you are saying: “tell every resolver they can hold this answer for five minutes; after that, ask again.” That five-minute window is exactly how long it takes for a change to propagate, in the worst case. TTL works hand in hand with the record types covered in DNS records explained — every A, MX, TXT, and CNAME record you publish carries one.
Common DNS TTL values
TTL is always expressed in seconds. These are the values you will actually run into, what they translate to, and when each one makes sense:
| TTL (seconds) | Human time | Typical use |
|---|---|---|
60 | 1 minute | Active migration / cutover window; fast rollback |
300 | 5 minutes | Records that may change soon; Cloudflare “Auto” default |
3600 | 1 hour | Sensible default for most records |
14400 | 4 hours | Stable records; common registrar default |
43200 | 12 hours | Rarely changing infrastructure |
86400 | 24 hours | NS and MX records that almost never change |
So TTL 3600 means one hour, TTL 14400 means four hours, and TTL 86400 means one day. There is no single “default” DNS TTL — each provider picks one (often 3600 or 14400). Most records sit happily in the 300–3600 range. The practical maximum honored by resolvers is bounded: RFC 2181 caps TTL at 2,147,483,647 seconds, but recursive resolvers commonly clamp anything above a day or two.
Long TTL vs short TTL — the tradeoff
The choice is between two costs:
- Long TTL = fewer authoritative queries, better cache hit rate, lower load — but slower propagation when you need to change something.
- Short TTL = faster propagation — but more queries to authoritative servers, and a partial outage of those servers is felt sooner.
In practice most teams default to 300–3600 seconds. The exception is when you are preparing for a migration: drop TTL to 60s a day or two in advance, do the cutover, then raise it back to the normal value once the new record is stable.
TTLs by record type
Common patterns that actually make sense:
- Apex A / AAAA / CNAME for a website that may need rollback:
300to3600. - Backend A records consumed only by your own systems: stable, pick what matches operational change windows.
- NS records:
86400(24 hours). Nameservers should not change often. - MX records:
3600to86400. Email infrastructure is rarely volatile and large TTL helps deliverability when there is a brief outage. - TXT records for SPF / DKIM / DMARC:
3600is fine; longer is fine too unless you rotate keys aggressively. - SOA minimum (used for NXDOMAIN caching):
3600. Avoid 24 hours here because it makes “why is my new record still returning NXDOMAIN?” a much longer mystery.
The migration pattern
The pattern when you know a cutover is coming:
- A day or two before the change, lower the TTL on the affected record(s) to 60–300s. Push and wait at least one current-TTL period for that change to spread.
- Do the actual record change. Within one short-TTL period, resolvers everywhere are serving the new answer.
- Verify with the DNS lookup, online nslookup tool, and resolver comparison tools. Different resolvers reaching the new answer at different times is expected during this window.
- After 24–48 hours of stability, raise the TTL back to the steady-state value to reduce authoritative load.
Reading TTL in tools
dig shows TTL as the second column of every record line in the answer section:
example.com. 3600 IN A 93.184.215.14
That value decreases as the resolver's cache ages. If you query the same name twice and see the TTL drop, you are seeing the same cached entry counting down. Query the authoritative server directly with +norecurse to see the canonical TTL the zone is publishing.
Cutover-day TTL pattern
- Example input
example.com A record, scheduled migration- Example result
# Day -2: lower TTL example.com. 60 IN A 203.0.113.10 # Day 0: cutover to new IP example.com. 60 IN A 198.51.100.20 # Day +2 (after verification): raise TTL back example.com. 3600 IN A 198.51.100.20
The 60-second window gives you fast rollback if the new IP misbehaves. Raise the TTL back afterward to drop authoritative load.
Related tools
FAQ
What does TTL mean in DNS?
TTL stands for time to live. In DNS it is the number of seconds a resolver is allowed to cache a record before it must ask the authoritative nameserver again. A TTL of 3600 means resolvers may reuse the cached answer for one hour. It is the single value that controls how fast a DNS change propagates.
What is the default DNS TTL?
There is no universal default — each DNS provider picks one. Common defaults are 3600 seconds (1 hour) at many registrars, 300 seconds at Cloudflare's 'Auto' setting, and up to 86400 seconds (24 hours) on older or self-managed zones. For most records, a default in the 300–3600 second range is the sweet spot between propagation speed and authoritative load.
What is DNS cache TTL?
DNS cache TTL is the same value seen from the caching side: it is how long a recursive resolver (or your operating system's stub resolver) keeps a record in its cache. When you run a lookup twice and watch the TTL count down, you are watching the resolver's cache TTL age toward zero, at which point it re-queries the authoritative server.
What is a sensible default TTL?
300 to 3600 seconds (5 minutes to 1 hour) is a good default for most records. Long enough to absorb burst load against authoritative servers, short enough that fixes propagate within an hour. Bigger sites with anycast and good provisioning can push higher; small sites should not exceed an hour by default.
What does a TTL of 3600 mean?
A TTL of 3600 means one hour (3600 seconds). Resolvers may cache that record for up to an hour before re-querying the authoritative server. Likewise, 14400 is four hours, 300 is five minutes, and 86400 is 24 hours. TTL is always counted in seconds.
What is the maximum DNS TTL?
RFC 2181 defines the TTL field as a 32-bit value, so the theoretical maximum is 2,147,483,647 seconds (about 68 years). In practice that is meaningless: most recursive resolvers clamp inbound TTLs to a day or two, and there is no benefit to setting a record beyond 86400 (24 hours) for normal use. Pick a value that matches how often the record actually changes.
Do resolvers always honor TTL?
Mostly yes, but a few caveats. Some resolvers cap inbound TTLs (Cloudflare's recursive caps at a few hours regardless of what you set), some apply a minimum to avoid hammering authoritative servers, and DNS-over-HTTPS clients may layer their own caches on top. Treat declared TTL as a strong hint, not a contract.
What is negative caching TTL?
When a resolver asks for a name that does not exist (NXDOMAIN), it caches that answer too. The duration is bounded by the SOA record's minimum field, capped at 24 hours by RFC 2308. If you just created a record and resolvers still report NXDOMAIN, you are waiting on negative caching.
Should the TTL be the same on every record in my zone?
No. Apex A and CNAME records that may need fast cutover want short TTLs (300s). Stable infrastructure like nameserver NS records and MX records pointing at hosted email want long TTLs (24 hours) so they survive blips. Mix them to match how often each record actually changes.
Does shortening TTL cost anything?
Yes — every additional cached miss is another query to your authoritative nameservers. A site with a 60s TTL gets roughly 60× the authoritative query load of one with a 3600s TTL. With cheap managed DNS that cost is invisible to you; with self-hosted authoritative DNS it can matter.
Last reviewed: 2026-06-18.