DNS TTL Explained: What It Is and How to Choose It

Every DNS record carries a small but consequential number called the TTL, short for Time To Live. It is the single setting that decides how long the rest of the internet is allowed to remember an answer before checking with you again. Set it well and your changes roll out quickly when you need them to while costing almost nothing the rest of the time; set it poorly and you either flood your nameservers with repeat queries or wait a full day for a fix to take effect. This guide explains what TTL is, how caching uses it, what the common values mean, and how to choose the right one for a given record. You can see the live TTL on any record with the DNS Lookup lookup tool.

TTL is a number of seconds attached to every DNS record. It tells any resolver that fetches that record how long it may cache and reuse the answer before it must ask again. A TTL of 3600 means "this answer is good for 3600 seconds (one hour); after that, throw it away and look it up fresh." The value lives in the record itself, not in some global setting, so different records in the same zone can have different TTLs, and you control each one.

In a zone file the TTL is the number that appears just before the record class and type, for example: www.example.com. 3600 IN A 93.184.216.34. Here the A record may be cached for one hour. Most DNS hosting panels expose this as a TTL field or dropdown next to each record, sometimes in seconds and sometimes as friendly options like "5 minutes" or "1 hour."

When a recursive resolver (your ISP's resolver, a public one like 8.8.8.8 or 1.1.1.1, or your router) looks up a name, it receives the record along with its TTL and stores the answer in memory. For the duration of that TTL, every user behind that resolver gets the cached answer instantly without the resolver bothering your authoritative nameservers at all. This is what keeps DNS fast and keeps load on origin servers manageable; the vast majority of lookups never reach you.

The resolver counts down the TTL it received. When the timer hits zero, the cached entry expires and the next request triggers a fresh lookup, which returns the current record and a new TTL to start the cycle again. The countdown is per resolver and starts whenever that resolver first cached the record, so different resolvers worldwide are at different points in their countdowns at any given moment.

A handful of values show up again and again. 300 seconds (5 minutes) is a common "low" TTL used when records change often or when an imminent change needs to propagate fast. 3600 seconds (1 hour) is a sensible default for most records that are stable but might occasionally need editing. 86400 seconds (24 hours) is a typical "high" TTL for records that almost never change, such as NS or MX entries on a settled domain.

The trade-off is a straight tug-of-war. A low TTL means changes take effect quickly because caches expire fast, but resolvers query your nameservers far more often, increasing load and adding latency to lookups that miss the cache. A high TTL is cheaper and faster for end users (more cache hits, fewer round trips) but makes changes painfully slow to roll out, because old answers linger in caches for as long as the TTL you set. There is no universally correct number; you are balancing agility against efficiency for each record.

People often talk about DNS changes needing time to "propagate," but propagation is really just caches expiring. The instant you save a change at your authoritative nameservers, it is live there. What takes time is the world's resolvers letting go of the old, still-valid cached answer. They will keep serving the stale value until the TTL that was in effect when they cached it runs out, then pick up your new record on their next lookup.

This is why the relevant TTL during a change is the old one, not the new one. If a record had a TTL of 86400 and you edit it, resolvers that cached the old value may keep serving it for up to a full day, regardless of the new TTL. The new TTL only governs how long the new answer is cached going forward. To watch a change spread in real time, the DNS Propagation tool compares the answer returned from many locations at once, so you can see which caches have caught up.

The most useful TTL technique in practice is lowering it ahead of a planned change. Suppose you are moving a site to a new IP, switching mail providers, or changing your nameservers. If your records currently sit at a 24-hour TTL, a cutover could leave some users hitting the old server for a full day. The fix is to plan ahead: well before the migration, drop the TTL on the affected records to something low like 300 seconds.

Timing matters here. You must lower the TTL at least one old-TTL period before the migration so the high cached value has time to expire everywhere and be replaced by the low value. If the old TTL was 86400, lower it more than 24 hours in advance. Once every resolver is caching the record at 300 seconds, you perform the cutover and the change propagates within about five minutes worldwide. After the migration settles and the new value is confirmed, raise the TTL back to a normal level to regain caching efficiency. Your NS records can be reviewed with the Nameserver Lookup tool to confirm what is authoritative before and after you switch.

TTL governs positive answers, but there is also a TTL for negative answers, the "this name does not exist" (NXDOMAIN) responses. That negative caching TTL is derived from your zone's SOA (Start of Authority) record. In modern DNS the negative TTL is the smaller of the SOA record's own TTL and the final field of the SOA, the minimum field. This is why a typo or a not-yet-created record can appear missing for a while even after you add it: resolvers cached the earlier "does not exist" answer for the duration set by your SOA.

Historically the SOA minimum field once acted as a default TTL for the whole zone, but today its primary job is controlling how long negative responses are cached. If you are adding a brand-new subdomain and it stubbornly fails to resolve right after creation, the SOA negative TTL is the usual culprit. You can inspect these SOA timers, including the minimum, with the SOA Lookup tool to understand how long failed lookups will be remembered.

A hard truth worth internalizing: once a resolver has cached your record, you have no way to reach into it and clear it early. The TTL is a promise the resolver is honoring, and it will serve that answer until the timer expires no matter how urgently you want the change live. You can flush your own machine's cache (ipconfig /flushdns on Windows, or restarting the resolver service on Linux and macOS), and you can flush a public resolver's cache for your name through its own flush page, but you cannot flush the thousands of other resolvers your users sit behind.

This is precisely why proactive TTL management beats reactive panic. There is no emergency button to undo a slow rollout; the only lever is the TTL you set before the change. Plan migrations around the old TTL, lower it in advance, and accept that the remaining wait is simply caches honoring values you already published.

To see the TTL currently on a record, query it and read the seconds value the answer carries. The quickest way is the DNS Lookup lookup tool, which displays each record's type, value, and its remaining TTL. On the command line, dig example.com (or dig +nocmd example.com A +noall +answer) prints the TTL in the second column, and nslookup with debug output shows it too. Note that when you query through a recursive resolver, the TTL you see counts down toward zero with each second the answer has been cached, so a freshly fetched record shows the full TTL while a long-cached one shows a smaller remaining number.

If you want the authoritative TTL exactly as configured rather than a counted-down cache value, query one of the domain's own nameservers directly (for example dig @ns1.example.com example.com), which returns the full configured TTL every time. After a change, pair the DNS Lookup tool with the DNS Propagation tool: the first confirms the value at the source, the second shows how far the new record has spread as old caches expire.