What Is TTL in DNS? Values, Caching and When to Lower It
What TTL means in DNS, how resolvers count it down, sensible values for each record type, negative caching, and how to plan a change so nobody sees stale data.
Published: · 6 min read
TTL, "time to live", is the number attached to every DNS record that says how many seconds a resolver may keep the answer in its cache before it has to ask again. It is the only real control you have over how quickly a DNS change reaches users, and the reason "DNS propagation" takes the time it does.
How TTL works
Every record in a zone carries a TTL:
www.example.com. 3600 IN A 192.0.2.10
When a recursive resolver (your ISP's, your office's, or a public one such as 1.1.1.1 or 8.8.8.8) fetches this record from the authoritative server, it stores it and starts counting down from 3600. Anyone who asks that resolver in the next hour gets the cached copy, with the remaining TTL. When the counter reaches zero the entry is dropped, and the next query triggers a fresh lookup.
You can watch this happen:
$ dig +noall +answer www.example.com @1.1.1.1
www.example.com. 3412 IN A 192.0.2.10
$ dig +noall +answer www.example.com @1.1.1.1
www.example.com. 3397 IN A 192.0.2.10
The second number went down. Ask the authoritative server directly and you always see the full, configured value:
$ dig +noall +answer www.example.com @ns1.dns.example
www.example.com. 3600 IN A 192.0.2.10
This difference is a handy diagnostic: a TTL lower than the configured one means you are looking at a cache.
Three consequences follow from the mechanism:
- Nothing is pushed. Changing a record does not notify any resolver. Each cache keeps the old answer until its own countdown ends.
- Caches expire at different moments, because each one fetched the record at a different time. For up to one TTL after a change, different users see different answers. That is all "propagation" is.
- The TTL that matters is the old one. A resolver that cached the record yesterday with a TTL of 86400 will keep it for the rest of those 24 hours, whatever you set today.
Caches you do not control
The recursive resolver is not the only cache. Operating systems, browsers and applications keep their own, and not all of them respect the TTL exactly: browsers hold addresses for a short fixed time, and long-running applications (older Java runtimes are the classic case) may cache a lookup for as long as the process lives. Some resolvers also apply a floor or ceiling: a TTL of 5 seconds may be treated as 30 or 60, and very long TTLs may be capped at a day or so. Resolvers can additionally serve expired data for a short while if the authoritative servers are unreachable.
So a TTL is a strong hint, not a guarantee, and it is dishonest to promise that a change is visible "everywhere" after exactly N seconds.
Negative caching: the TTL of "does not exist"
A resolver also caches the answer "this name does not exist" (NXDOMAIN) and "this name has no record of that type". The duration comes from the zone's SOA record: the lower of the SOA record's own TTL and its last field (historically called "minimum").
$ dig +noall +authority nosuch.example.com
example.com. 300 IN SOA ns1.dns.example. hostmaster.example.com. 2026092001 7200 3600 1209600 300
This is the usual explanation for "I created the record, the authoritative server returns it, but my resolver still says it does not exist": somebody (often you, checking too early) queried the name before it was created, and the negative answer is cached. With a negative TTL of 300 that is a five-minute annoyance; with 86400 it is a lost day. Keep it modest. Values between 300 and 3600 are reasonable.
Choosing TTL values
There is no single correct number. It is a trade between agility and resilience:
| Low TTL (60–300) | High TTL (3600–86400) | |
|---|---|---|
| Changes take effect | quickly | slowly |
| Mistakes | are fixed quickly | stick for hours |
| Query load on authoritative servers | higher | lower |
| Lookup latency for users | more cache misses | mostly cached |
| If your DNS provider has an outage | names stop resolving within minutes | cached answers carry users through |
The last row is often forgotten. A long TTL is free insurance against a short DNS outage.
Sensible starting points:
| Record | Typical TTL | Reasoning |
|---|---|---|
A/AAAA for a stable website |
3600 | changes are rare and planned |
A/AAAA used for failover or behind a load balancer |
60–300 | must move quickly; often set by the provider |
CNAME to a SaaS or CDN |
3600 | the target's own TTL governs the final address |
MX |
3600–86400 | mail servers change rarely; senders retry anyway |
TXT (SPF, DKIM, DMARC) |
3600 | lower it before planned edits |
NS and SOA |
86400 | stable; the delegation TTL at the parent is outside your control |
CAA |
3600–86400 | CAs honour its TTL when re-checking |
If your provider offers "Auto", it usually means 300 seconds, which is fine for most sites.
Planning a change with TTLs
The routine for moving a website, a mail server or anything else behind a DNS name:
- Look up the current TTL from the authoritative server. Call it T.
- Lower it to 300 (not lower; some resolvers ignore very small values) and wait at least T. Only after T has passed can you be sure every cache holds the 300-second version.
- Make the change.
- Verify against the authoritative server and a few public resolvers.
- Keep the old target running for at least the new TTL, realistically a few hours, because of the caches that do not follow the rules.
- Raise the TTL again once you are sure you will not roll back.
Lowering the TTL and changing the record in the same edit is the classic mistake: the resolvers that matter have the old record with the old TTL and will not even see your new TTL until it expires.
Note that for nameserver changes a second TTL is involved, the delegation's TTL in the parent zone, which is commonly two days and not yours to change. That case is covered in changing nameservers without downtime.
TTL and CNAME chains
When a name is a CNAME, the resolver caches each link separately, each with its own TTL:
www.example.com. 3600 IN CNAME site.cdn.example.
site.cdn.example. 60 IN A 203.0.113.20
The CDN can move its A record within a minute, but if you want to point www at a different CDN, your own 3600 applies. The effective delay for a given change is the TTL of the record you are changing, not the smallest one in the chain.
Can I flush the cache?
Your own: yes.
# macOS
$ sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Windows
> ipconfig /flushdns
# Linux with systemd-resolved
$ resolvectl flush-caches
Some public resolvers offer a web form to purge a name from their cache, which helps after a mistake. Everyone else's resolvers you cannot touch. There is no global flush, and any service claiming to "force propagation" is selling a button that does nothing.
Common mistakes
- Lowering the TTL at the same moment as the change, or five minutes before it.
- Leaving everything at 60 seconds forever "to be flexible", and then going down with your DNS provider.
- A day-long TTL on a record that is part of a failover plan.
- Forgetting the negative-caching value and querying a name before creating it.
- Treating a lookup from your own laptop as proof of what users see.
- Believing a percentage on a "propagation checker" describes the whole internet. It describes the locations that tool queried.
Check it with OrbitProbe
The OrbitProbe DNS lookup shows the TTL next to every record it returns, as public resolvers see it at that moment. Before a migration, use it to find the TTLs you need to lower; after the change, run it again to confirm the new value and watch the remaining TTL. For an overview of which records exist in the first place, see DNS record types explained, and if the change is part of fixing mail delivery, the DNS checklist for email going to spam.