What is TTL in DNS and how should you set it?

Sajjad
DNS
10 Oct, 2026

TTL (time to live) in DNS is a number, in seconds, attached to every DNS record that tells resolvers how long they may cache that record before asking your nameservers again. A TTL of 3600 means a resolver can reuse the answer for up to one hour. You should set it based on how often the record changes and how quickly you need changes to take effect: around 3600 seconds (1 hour) is a sensible default for most records, 300 seconds (5 minutes) suits records you may need to change quickly, and 86400 seconds (1 day) or more works for records that almost never change, such as NS records.

TTL is one of the few DNS settings that directly controls the trade-off between speed and flexibility, yet it's often left at whatever a provider chose by default. This article explains what the TTL field actually does, how it interacts with resolvers and the SOA record, the trade-offs of short and long values, recommended TTLs by record type, and how to view and change TTLs with common tools and APIs.

What the TTL Field Is

Every resource record in DNS has the same basic structure: a name, a TTL, a class, a type and the data. In a zone file it looks like this:

www.example.com.   3600   IN   A   192.0.2.10

Reading left to right:

www.example.com. is the name.
3600 is the TTL in seconds.
IN is the class (Internet), which is almost always IN.
A is the record type.
192.0.2.10 is the data.

The TTL is defined as a 32-bit field. In practice, RFC 2181 limits the usable range to 0 through 2,147,483,647 seconds, and resolvers cap it far lower. You'll rarely see a TTL above one week (604800) on a real record.

TTL Applies to the Whole Record Set

Records with the same name, class and type form a record set (RRset). If www.example.com has two A records, they're cached together and should have the same TTL. RFC 2181 says all records in a set must share one TTL, and most DNS providers enforce this by letting you set a single TTL for the group. If you manage zone files by hand and give records in the same set different TTLs, servers such as BIND will warn you and use one value for the set.

How Resolvers Use the TTL

When a recursive resolver receives an answer from your authoritative nameserver, it stores the answer and starts counting the TTL down. Every answer it gives from cache shows the remaining time, not the original value. You can see this with dig:

dig @8.8.8.8 www.example.com A +noall +answer

www.example.com.	2715	IN	A	192.0.2.10

The authoritative server says 3600, but this resolver cached the record about 15 minutes ago, so there are 2715 seconds left. When the count reaches zero, the next query for that name causes a fresh lookup.

A few practical details are worth knowing:

Resolvers cap TTLs: Most resolvers have a maximum cache time, commonly one day, though some allow longer. Setting a TTL of a month doesn't mean every resolver will keep it for a month.
Some resolvers enforce a minimum: A small number of resolvers and ISPs refuse to cache for less than a certain time, such as 30 or 60 seconds. Very short TTLs aren't always honoured.
Browsers and operating systems cap too: Local caches usually keep entries for much less than the TTL, often a minute or so.
Applications may ignore TTL: Long-running processes sometimes resolve a name once and keep the result until restarted.

So the TTL is best thought of as the maximum time an old answer may survive in a well-behaved cache, not a precise expiry.

TTL of Zero

A TTL of 0 tells resolvers not to cache the answer at all, or to use it only for the current transaction. It's valid, but every lookup then hits your authoritative servers, adds latency for every visitor, and some resolvers will apply their own minimum anyway. If you need fast changes, a short TTL such as 30 or 60 seconds is a far better choice than zero.

The SOA Record and Negative TTL

TTLs also apply to answers that say something does not exist. If someone queries new.example.com before you've created it, resolvers cache the "no such name" response (NXDOMAIN). How long they keep it is controlled by your zone's SOA record.

dig example.com SOA +noall +answer

example.com.	3600	IN	SOA	ns1.example.com. hostmaster.example.com. 2026101101 7200 3600 1209600 300

The final field, here 300, is the SOA minimum field. Under RFC 2308 a resolver caches a negative answer for the lower of this value and the TTL of the SOA record itself. In this example negative answers are cached for 300 seconds.

If your SOA minimum is high, say 86400, a mistyped or not-yet-created name can stay "missing" for a day in caches that have already looked it up. Keeping this value between 300 and 3600 seconds is a good balance for most zones.

The $TTL Directive

In a BIND-style zone file, the $TTL directive at the top sets the default TTL for any record that doesn't specify its own:

$TTL 3600
@       IN  SOA  ns1.example.com. hostmaster.example.com. (
                 2026101101 ; serial
                 7200       ; refresh
                 3600       ; retry
                 1209600    ; expire
                 300 )      ; negative caching TTL

        IN  NS   ns1.example.com.
        IN  NS   ns2.example.com.
@       IN  A    192.0.2.10
www     300 IN  A    192.0.2.10
mail        IN  A    192.0.2.20

Here www overrides the default with a 300-second TTL, while the apex and mail records inherit 3600 from $TTL. BIND also accepts unit suffixes such as 1h, 30m and 1d, which are easier to read than raw seconds.

The Trade-Off: Short vs Long TTLs

Choosing a TTL means balancing several factors. Neither short nor long is "correct" on its own.

Factor	Short TTL (60–300s)	Long TTL (3600–86400s)
Speed of changes	Changes visible within minutes	Changes can take hours or a day
Lookup latency for users	More cache misses, slightly slower	More cache hits, faster on average
Load on authoritative servers	Higher query volume	Lower query volume
Cost on per-query DNS pricing	Higher	Lower
Resilience if DNS provider fails	Caches empty quickly, outage felt sooner	Cached answers keep working longer
Suitability for failover	Good	Poor

Why Short TTLs Aren't Free

It's tempting to set every record to 60 seconds "just in case". The costs are real, though:

Latency: Each cache miss adds a full lookup, often tens of milliseconds and sometimes much more, to a visitor's first connection.
Fragility: If your DNS provider suffers an outage or a DDoS attack, records with a 60-second TTL disappear from caches within a minute. Records with a 1-hour TTL keep working for most users for up to an hour.
Cost: Providers that bill per query, such as Amazon Route 53 and Google Cloud DNS, charge more when resolvers come back more often.

Why Long TTLs Aren't Free Either

Long TTLs make you slow to react. If a server's IP address changes unexpectedly, or you discover a mistake in a record, everyone who cached the old value keeps using it for up to the full TTL. For records with a one-day TTL, that can mean a day of partial downtime that you can't speed up.

Recommended TTL Values

These values are sensible starting points. Adjust them for your own change frequency and risk.

Record type	Typical TTL	Why
NS (in your zone)	86400 (1 day)	Nameservers rarely change, and they're looked up constantly
SOA	3600 (1 hour)	Also caps negative caching time
A / AAAA for a stable website	3600 (1 hour)	Good balance of speed and agility
A / AAAA behind failover or load balancing	30–60	Clients must move away from failed targets quickly
CNAME to a CDN or SaaS platform	3600	The provider handles changes behind its own name
MX	3600–14400	Mail routing changes are rare and mail retries anyway
TXT for SPF, DKIM, DMARC	3600	Changes are occasional; one hour is quick enough
TXT for one-time domain verification	300–3600	Short helps if you need to fix a typo
CAA	3600–86400	Certificate policy changes are infrequent
Records before a planned migration	300	Lowered temporarily, then raised again

A few points to keep in mind:

NS TTL at the parent is not yours to set: The NS records published in the TLD zone, such as .com, carry the TLD operator's TTL (two days for .com). Your own NS TTL only applies to resolvers that ask your nameservers directly.
Provider-managed records may have fixed TTLs: For example, Cloudflare uses an automatic TTL of 300 seconds for proxied records, and Route 53 alias records don't take a TTL at all, because Route 53 sets it based on the AWS resource they point to.
Use the same TTL for related records: If example.com and www.example.com point to the same server, keep their TTLs aligned so they change together.

Lowering TTL Before a Change

The most useful TTL technique is to lower a record's TTL before you change its value. The timeline looks like this:

Day 0: The record has a TTL of 86400. Change it to 300 but keep the value the same.
Wait at least the old TTL: After 24 hours, every cache that held the record with the long TTL has expired it and picked up the 300-second version.
Day 1: Change the record's value. All caches refresh within five minutes.
After the change settles: Raise the TTL back to its normal value.

The key detail is step 2. Lowering the TTL has no effect on copies that are already cached with the old, long TTL. You must wait out the old value first.

How to Check a Record's TTL

To see the TTL your nameservers are actually publishing, ask them directly rather than through a cache:

# Find the authoritative nameservers
dig example.com NS +short

# Ask one directly
dig @ns1.example.com www.example.com A +noall +answer

www.example.com.	300	IN	A	192.0.2.10

To see how long a public resolver will keep serving its cached copy:

dig @1.1.1.1 www.example.com A +noall +answer

If you prefer kdig from Knot DNS, the same idea applies:

kdig @ns1.example.com www.example.com A +short +ttlunits

On Windows, Resolve-DnsName shows the TTL in its TTL column:

Resolve-DnsName -Name www.example.com -Type A -Server 1.1.1.1

Name                 Type   TTL   Section    IPAddress
----                 ----   ---   -------    ---------
www.example.com      A      287   Answer     192.0.2.10

Setting TTL With Common Tools

Cloudflare API

You can set a record's TTL when creating or updating it through the Cloudflare API. A TTL of 1 means "automatic" in Cloudflare's API; any other value must be between 60 and 86400 seconds on most plans (Enterprise plans allow lower values):

curl -X PATCH \
  "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/$RECORD_ID" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"ttl": 300}'

Amazon Route 53 With Terraform

In Terraform, the ttl argument on an aws_route53_record sets the value for the whole record set:

resource "aws_route53_record" "www" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "www.example.com"
  type    = "A"
  ttl     = 300
  records = ["192.0.2.10", "192.0.2.11"]
}

Managing TTLs as code makes it easy to lower them for a migration and see exactly when they were raised again in your version history.

AWS CLI

With the AWS CLI, you change a TTL by upserting the record set with the new value:

aws route53 change-resource-record-sets \
  --hosted-zone-id Z0123456789EXAMPLE \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "www.example.com",
        "Type": "A",
        "TTL": 300,
        "ResourceRecords": [{"Value": "192.0.2.10"}]
      }
    }]
  }'

Common TTL Mistakes

Lowering the TTL and changing the record at the same time: Caches holding the old long TTL won't see the new value any sooner. Lower first, wait, then change.
Forgetting to raise the TTL afterwards: A record left at 60 seconds for months costs latency and resilience for no benefit.
Using very short TTLs everywhere: Reserve short values for records that genuinely need them, such as failover targets.
Ignoring the SOA minimum: A large negative caching value makes new records slow to appear for anyone who looked them up too early.
Expecting a TTL to control the TLD's NS records: Changes of nameserver at the registrar are governed by the TLD's own TTL, which you can't shorten.

FAQ: DNS TTL

3600 seconds (one hour) is a sensible default for most records. It keeps lookups fast and load low, while still letting changes take effect within an hour.

The DNS protocol allows 0, but many providers set a minimum such as 30 or 60 seconds, and some resolvers apply their own minimum. A value of 60 seconds is a practical lower limit for most uses.

No, usually the opposite. A lower TTL means resolvers look up your records more often, so more visitors experience a full DNS lookup. Longer TTLs give more cache hits and slightly faster first connections.

Something may have cached the record before you lowered the TTL, a resolver or application may ignore TTLs, or the change involved nameservers at the registrar, which follow the TLD's TTL. Negative caching from an earlier lookup can also delay new records.

Not necessarily. Records in the same record set must share a TTL, but different records can and often should have different values based on how often they change.

When you query a recursive resolver, the TTL shows the remaining seconds before its cached copy expires. When you query an authoritative nameserver directly, it shows the full value configured in the zone.

Conclusion

The TTL is a simple number with a big effect. It tells every resolver how long it may keep your records, which sets the balance between fast, resilient lookups and the ability to change things quickly. A default around one hour, longer values for records that never change, and short values only where you need fast failover will suit most domains.

The habit that pays off most is lowering a TTL well before a planned change, waiting out the old value, making the change, and then raising it again. Keep an eye on your SOA minimum for negative caching, check what your authoritative servers actually publish with dig, and TTL will stop being a mystery and start being a tool.