The Role of DNS TTL (Time to Live) Settings

Every DNS answer comes with a number attached: the Time to Live, or TTL. It is easy to overlook because DNS panels fill in a default and most people never touch it. Yet that one value decides how quickly a change to your website, email or API reaches users, how much load your nameservers handle and how gracefully your domain survives a provider outage. Understanding TTL is the difference between a migration that finishes in five minutes and one that drags on for a day.

This guide explains what TTL actually does, how to choose sensible values, how to plan a migration around it, and why real-world caches do not always follow the number you set.

What TTL means in DNS

TTL is a field on every resource record, measured in seconds. When a recursive resolver, such as your ISP’s resolver or a public one like 1.1.1.1 or 8.8.8.8, fetches a record from an authoritative nameserver, it stores the answer and counts the TTL down. Until it reaches zero, the resolver answers from its cache without asking the authoritative server again. When it expires, the next query triggers a fresh lookup.

You can see the countdown with dig. Run the same query twice against a resolver and the TTL in the answer section will be lower the second time:

dig @8.8.8.8 example.com A +noall +answer
example.com.    2873    IN    A    93.184.215.14

To see the original value set by the zone owner, ask an authoritative nameserver directly:

dig NS example.com +short
dig @ns1.example-dns.net example.com A +noall +answer

The often quoted idea of “DNS propagation” is really this: thousands of independent caches each expiring the old answer on their own schedule. Nothing is pushed out; caches simply forget.

The trade-offs of short and long TTLs

No TTL is right for every record. Each choice balances agility against efficiency and resilience.

A long TTL also acts as a safety net. If your authoritative DNS provider goes down, resolvers that cached your records an hour ago keep answering for the rest of that hour. With a 60-second TTL, users feel an outage almost immediately. Short TTLs are not free performance either: each cache miss adds a round trip to the authoritative servers.

Choosing values for each record type

A, AAAA and CNAME

For a website on a stable server, one hour is a sensible baseline. If you use a CDN or a managed load balancer, follow the provider’s guidance; many use short TTLs on their own records so they can steer traffic, and your CNAME to them can stay longer.

MX and mail-related TXT

Mail routing rarely changes, and senders retry for days if delivery fails, so a few hours to a day is fine. Lower it in advance if you are moving to a new email provider.

NS records

The NS records that really matter for delegation sit in the parent zone and are controlled by the registry, often with a TTL of one or two days. That is why changing nameservers at your registrar takes longer than changing an A record. You can check which nameservers a domain currently delegates to with the TLDix WHOIS lookup.

SOA

The SOA record carries timers for secondary servers and the negative-caching value discussed below. Its own TTL is usually an hour or more.

Lowering TTL before a migration

The most useful practical TTL technique is to shrink it before a planned change. The key detail people miss is timing: resolvers only learn about your new, lower TTL after their cached copy with the old TTL expires.

1. Check the current TTL on the authoritative server. Say it is 86400 seconds.
2. Lower it to 300 seconds at least 24 hours, one full old TTL, before the migration. Waiting a little longer is safer.
3. Make the change, for example point the A record at the new server. Most caches now refresh within five minutes.
4. Keep the old server running for a while, because some clients will lag behind.
5. Raise the TTL back to its normal value once traffic and logs confirm the move is complete.

; 24+ hours before
www.example.com.   300    IN  A  203.0.113.10
; migration moment
www.example.com.   300    IN  A  198.51.100.20
; after verification
www.example.com.   3600   IN  A  198.51.100.20

If you skip step 2 and change the record while the TTL is still a day, some users will reach the old server for up to a day.

Negative caching and the SOA minimum

Resolvers also cache the absence of a record. When a name does not exist (NXDOMAIN) or exists without the requested type (NODATA), RFC 2308 says the resolver may cache that negative answer. Its lifetime is the lower of the SOA record’s own TTL and the last field in the SOA, historically called “minimum”.

dig example.com SOA +noall +answer
example.com. 3600 IN SOA ns1.example-dns.net. hostmaster.example.com. 2026100701 7200 3600 1209600 3600

Here the final 3600 means a failed lookup can be remembered for an hour. This bites when you query a new subdomain before creating it: a monitoring check, a certificate validation attempt or an impatient test caches NXDOMAIN, and the new record then seems “not to propagate”. To avoid this, create records before anything looks them up, and keep the SOA negative TTL modest, typically 300 to 3600 seconds.

When resolvers clamp or ignore your TTL

The TTL you publish is a maximum, not a guarantee. Several layers may change it:

• Resolver limits. Software such as BIND and Unbound has configurable maximum cache times, and operators may set minimums so very short TTLs are raised. BIND’s default maximum is one week, and its negative cache is capped at three hours by default.
• Serve-stale. RFC 8767 lets resolvers keep answering with expired data when authoritative servers are unreachable. This improves resilience but can extend the life of old answers.
• Operating systems and browsers. Local stub resolvers and browsers keep their own short caches, independent of the network resolver.
• Applications. Long-running processes may resolve a name once and reuse the address, and some runtimes have their own DNS cache settings.

The upshot: plan for a long tail. After any change, expect most traffic to move within the TTL and a small fraction to straggle for longer.

Monitoring and good habits

• Document the normal TTL for each record so temporary reductions are not forgotten.
• Compare authoritative answers with several public resolvers after changes.
• Avoid TTLs below 30 seconds unless your provider specifically needs them.
• Pair DNS changes with expiry tracking for the domain, certificates and hosting, since an expired domain breaks DNS regardless of TTL.

For a refresher on what each record type does, read our guide to DNS records basics.