Guides · DNS
What Is A TTL In DNS?
TTL tells resolvers how long to cache a DNS record. Pick it well and changes propagate fast; pick it badly and traffic stops moving when you need it to.
By Cody · 5 min read · Published
What TTL actually is
TTL — 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.
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.
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 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 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.
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-05-14.