What Is DNS TTL? The Plain-English Guide (and the TTL Values That Save Migrations)

CodexFuse Team · 2026-11-04T03:35:11.153Z · 15 min read min read

This what is DNS TTL guide is the plain-English version of a number that quietly controls how fast every DNS change you make reaches the internet. DNS TTL — time to live — is a value in seconds attached to every DNS record that tells resolvers how long they may cache your answer before they must ask your authoritative nameserver again. If your website, email, or move to a new host depends on a DNS change, the TTL decides whether users see it in minutes or tomorrow.

You can see any record's current TTL right now with our DNS lookup tool: type the domain, read the record, and the TTL sits right beside it. This guide explains what that number means, the values everyone actually uses, the pre-migration routine that prevents downtime, and the cases where resolvers ignore your setting anyway.

What Does DNS TTL Actually Do?

DNS TTL does one job: it sets the expiry date on a cached DNS answer. RFC 1035 defines TTL as a 32-bit unsigned integer specifying "the time interval (in seconds) that the resource record may be cached before it should be discarded." When a resolver — your ISP's, Google's 8.8.8.8, Cloudflare's 1.1.1.1, your office router, or your laptop's own cache — fetches a record from your authoritative nameserver, it stores the answer and starts the countdown. Until that countdown reaches zero, every lookup for the same name gets the cached copy instantly; once it expires, the resolver goes back to the authoritative server for a fresh copy.

The who.is TTL guide (updated June 2026) puts the philosophy well: a TTL is a permission, not a promise. It tells caches how long they may hold the answer, and RFC 2181 §8 makes it explicit that the TTL is a maximum, not a mandatory minimum — resolvers are free to re-check sooner or, as you will see below, to cap your value entirely. A TTL of 3600 permits one hour of caching; 300 permits five minutes. Nothing is deleted or "expired" when the timer hits zero — the cached copy is simply discarded so the next lookup fetches the current truth.

How Does a Resolver Actually Use the TTL?

A resolver uses the TTL as a countdown timer that starts the moment it caches your record. The dnsspy.io TTL guide (June 2026) describes it exactly: the authoritative TTL is the number that resets the countdown when the cache refreshes, and the resolver TTL counts down from there. Every layer caches independently — your ISP, the public resolvers, your office router, your laptop — and each runs its own timer from the moment it fetched the answer, not from the moment you changed the record.

That last point is the one that surprises people. If you edit a record at 2:00 PM but a resolver fetched the old copy at 1:55 PM with a TTL of 3600, that resolver keeps serving the old answer until 2:55 PM. There is no "push" and nothing "propagates" — the who.is guide calls this out directly as a myth: your change hits your authoritative nameservers instantly, and the rest of the internet only notices as old caches expire one by one. TTL is also per-record, not per-domain: your A record can run 3600 while your NS records run 86400 and your MX records run 14400, and each has its own timer.

One special case: negative caching. When a name does not exist, the "no such domain" answer is also cached, and its lifetime is governed by the minimum field of the zone's SOA record — the negative TTL, defined in RFC 2308. That is why a mistyped record can haunt you even after you fix it: the negative answer you earned during the typo is still being served from caches until the SOA minimum runs out.

What Are the Common DNS TTL Values?

Common DNS TTL values are a small vocabulary operators reuse everywhere: 60 for pre-migration, 300 as the "ready to change" setting, 1800 for production records that change occasionally, 3600 as the most common production default, 14400 for records that rarely change, 86400 for day-stable records like NS, and 172800 as the maximum recommended. Here is what each one means in practice, drawn from the dnsspy.io cheat sheet:

The pattern is a trade-off, not a magic number: shorter TTLs buy you fast changes at the cost of more DNS queries hitting your authoritative servers; longer TTLs buy you less load and faster answers from cache at the cost of sluggish change rollout. The VentraIP TTL guide (October 2026) shows the same ladder in its own words: 300 for temporary use before a planned change, 14,400 for records that rarely change.

How Do You Choose a DNS TTL Value?

You choose a DNS TTL value by matching it to how often the record actually changes and how fast you need changes to land. The default answer for most production websites is 3600: one hour of caching, a change window of about an hour, and modest query load — the dnsspy.io guide calls it the most common production TTL and a sensible default. If the record almost never changes — your NS records, your SOA, an MX record pointing at a provider you have used for years — 14400 or 86400 is honest, and it cuts your authoritative query load to a trickle.

Cloudflare's own docs (updated April 2026) give a concrete picture of how a major provider thinks about defaults. Every proxied record on Cloudflare uses an "Auto" TTL of 300 seconds — that is five minutes, not the hour some guides guess. For DNS-only (unproxied) records, Cloudflare lets you pick from 60 seconds (30 seconds on Enterprise plans) up to one day. The lesson generalizes: if your provider will not let you set a low TTL, you cannot do a fast migration, no matter what a guide says.

Two warnings from the operator world belong here. First, RIPE 91 (October 2025) presented real-world TTL measurements from RIPE Atlas probes: 45 percent of observed TTLs are capped at 12 hours or less by resolvers, 70 percent at one day or less, and the presenter's advice was blunt — do not use a TTL longer than one day. Second, the "48 hours for DNS changes" number your hosting company quotes is, per the dnsspy.io guide, a safety margin covering the slowest cache in the chain, not a law of physics: a change on a 300-second TTL reaches well-behaved caches in minutes.

How Do You Lower DNS TTL Before a Migration?

You lower DNS TTL before a migration by dropping the TTL on the affected records to 300 (or 60) at least 24 hours before the change, waiting for the old TTL to drain out of every cache, making the change, then raising the TTL back afterward. This is the standard zero-downtime playbook, and dnsspy.io prints it as four steps:

1. Two days before the change, drop the TTL. Set the records you are about to change to 300 (five minutes) or 60 (one minute) for a fast cutover.
2. Wait at least as long as the old TTL. If your old TTL was 3600, wait at least an hour — better, wait the full 24 hours. This guarantees every cache in the world has refreshed and pulled the new low TTL.
3. Make your real change. Because the TTL is now 60 or 300, the change reaches users in minutes instead of hours.
4. Raise the TTL back. Once the migration is stable, restore a normal value like 3600 so your query load and cache efficiency return to normal.
5. Verify from outside. Check the new record from resolvers you do not control (8.8.8.8, 1.1.1.1) rather than your own cache.

The timing rule is corroborated everywhere operators write about it: Gcore's TTL guide says lower to 300–600 seconds at least 24–48 hours before migrations, and blog.fxrm.com's cutover guide says to reduce the TTL at least one old-TTL period before you need it. Step 2 is the one people skip — if your old TTL was 86400 and you lower to 300 an hour before the move, resolvers that cached yesterday's value with the day-long TTL will happily serve it for another 23 hours. The lowered TTL only governs answers fetched after the change.

If you are moving a whole site to a new server, the same discipline applies to the hosting layer: read our what is VPS hosting guide before the move so the TTL schedule and the server cutover happen as one plan, not two.

How Long Does a DNS Change Take to Take Effect?

A DNS change takes effect as soon as the old cached answer's TTL expires everywhere — roughly the old TTL's length, plus a fudge factor for misbehaving caches. The dnsspy.io guide states it directly: changes take "as long as your TTL plus a fudge factor for misbehaving caches." The rough mapping from practice: a 60-second TTL resolves in a minute or two, 300 in about five minutes, 3600 in about an hour, 14400 in about four hours, and 86400 in up to 24 hours.

Three things make the real number longer than the table. First, some resolvers impose their own floors and ceilings on TTL regardless of what you publish — more on that below. Second, nameserver changes (moving DNS to a new provider, not just editing a record) are bounded by the parent zone's NS TTL, which you cannot control and which the who.is guide notes is often long; for .com and .net, the registry delegation TTL is 48 hours, which is why nameserver migrations can take two full days whatever you do. Third, clients cache too: browsers and operating systems keep their own copies on timers you cannot flush from the DNS console.

To see what the world actually sees, check your record from several public resolvers — our dog vs dig comparison shows the modern syntax for querying specific resolvers side by side, which is exactly how you confirm a change has landed outside your own cache.

Why Don't Some Resolvers Honor Your TTL?

Some resolvers do not honor your TTL because the standards explicitly allow them to override it. RFC 2181 §8 says implementations "are always free to place an upper bound on any TTL received" — the TTL is a maximum you request, not a mandate you impose. Real-world measurements from RIPE 91 (Shane Kerr, NS1, October 2025) show how aggressively this happens: Google's 8.8.8.8 caps received TTLs at 6 hours, OpenDNS caps at 7 days, and only some resolvers like 1.1.1.1 impose no maximum at all.

The ISP side is worse than the public-resolver side. The dnsspy.io guide warns that "most ISPs and corporate networks have at least one resolver in the chain that ignores TTLs," and community reports corroborate it: some ISP resolvers cap everything at four hours, and others enforce a minimum floor — commonly 300 seconds — so your careful 60-second cutover TTL gets rounded up to five minutes without anyone telling you. IONOS's TTL guide (the stale vendor page on page 1) says the same from the other direction: many ISPs ignore TTL settings and refresh on their own schedule.

Practically, this means two things. Never plan a migration that requires caches to drop your answer faster than 300 seconds — the floor may be raised on you. And do not set TTLs longer than one day expecting them to be honored everywhere: RIPE 91's advice, based on actual measurements, is to treat one day as the practical ceiling, because 70 percent of observed TTLs end up capped at a day or less.

How Do You Check a DNS Record's TTL?

You check a DNS record's TTL by querying the record directly — the TTL is printed in every answer. The fastest way is our DNS record lookup tool: enter the domain, and each record row shows its type, value, and current TTL. From a terminal, dig example.com shows the TTL in the second field of each answer section line, and querying a specific resolver with dig @8.8.8.8 example.com or dog example.com @1.1.1.1 shows you what the outside world sees rather than your own cache.

For reading your own zone, the TTL also lives in your DNS provider's dashboard on every record row — and if you are auditing a whole domain before a migration, our subdomain finder guide covers enumerating every name in the zone so no record keeps a stale TTL you forgot to lower.

Should You Ever Set TTL to 0?

You should not set TTL to 0 — it behaves unpredictably and buys you nothing reliable. RFC 1035 says a zero TTL means the record "can only be used for the transaction in progress, and should not be cached." In practice, per the dnsspy.io guide, some resolvers respect that and never cache; others ignore it and substitute a default. You get the worst of both worlds: extra DNS queries on every lookup without reliably faster updates, plus measurable load on your authoritative servers. ExpressVPN's DNS glossary adds the performance angle: configuring zero is discouraged because it can significantly affect DNS server performance.

If you need the shortest practical cache time, use 60 seconds. It is honored by well-behaved resolvers, rounded up to at most a few minutes by the aggressive ones, and — unlike zero — never rejected or substituted. The only place zero belongs is RFC 1035's original use case: extremely volatile data within a single transaction.

What Is the Maximum DNS TTL?

The theoretical maximum DNS TTL is 2,147,483,647 seconds — 2^31−1, about 68 years — because RFC 2181 §8 defines the TTL as an unsigned 32-bit integer with that range. The practical maximum is far lower and depends on your provider: Cloudflare caps DNS-only records at one day, dnsspy.io calls 172800 (48 hours) the maximum recommended, and RIPE 91's measured data suggests anything above a day gets capped by resolvers in 70 percent of cases anyway.

Treat the 68-year figure as trivia and the one-day figure as engineering. A TTL longer than a day mainly buys you one thing: misery when the record is wrong, because every cache that honored it will keep serving the wrong answer for the full duration, and you have no remote-flush button.

Sources

Every fact in this guide was verified against a named source fetched on 2026-11-04 (US Pacific).

• who.is — "DNS TTL and Propagation: Why Changes Take Time" (updated 2026-06-19; TTL as permission-not-promise; propagation myth; parent-zone NS TTL bounds).
• dnsspy.io — "What is DNS TTL? How to Choose the Right Value" (2026-06-09; per-record values table 60/300/1800/3600/14400/86400/172800; four-step pre-migration playbook; TTL-0 warning; ISP override caveat).
• Cloudflare Docs — DNS TTL reference (updated 2026-04-16; proxied "Auto" TTL = 300 seconds; DNS-only range 60s–1 day).
• RIPE 91 — "DNS TTL Upper Limits in Practice", Shane Kerr (NS1), 2025-10-23 (RIPE Atlas measurements: 8.8.8.8 caps at 6h, OpenDNS at 7 days, 1.1.1.1 no cap; 45% ≤12h, 70% ≤1d; advice: no TTL over 1 day).
• IONOS Digital Guide — "Understanding and Configuring DNS TTL" (typical defaults 12h/24h; lower 24h before moves; ISPs ignore TTL; never 0; good minimum 3600).
• VentraIP — "What Is TTL in DNS?" (October 2026; 300-for-planned-change / 14,400-for-rarely-changed ladder).
• whatsmydns.me — "What is TTL and How Does it Affect DNS Propagation" (longer TTL = slower propagation).
• Gcore Learning — "What is DNS TTL" (pre-migration: lower to 300–600s at least 24–48h ahead).
• blog.fxrm.com — "DNS TTLs & Zero-Downtime Hosting Cutover" (reduce TTL at least one old-TTL period before need; resolver ceilings and floors).
• RFC 1035 §3.2.1 (TTL definition; zero = transaction-only), RFC 2181 §8 (TTL is a maximum; 2^31−1 range; resolvers may cap), RFC 2308 §5 (negative caching from SOA minimum), RFC 8767 (serve-stale exception).

Frequently Asked Questions

What is the default DNS TTL?

There is no single default — it depends on your provider. Common defaults are 3600 (one hour) or 86400 (24 hours) per the IONOS guide, and Cloudflare's proxied "Auto" TTL is 300 seconds (five minutes) per its April 2026 docs. If you inherited a domain, check your DNS provider's dashboard: the TTL is printed on every record row.

Will lowering my TTL speed up a change I already made?

No. Lowering the TTL now only affects answers fetched after the change — resolvers that already cached your record under the old TTL keep serving it until that old timer expires. That is why the pre-migration playbook says to lower the TTL at least one full old-TTL period (ideally 24 hours) before you need it.

Why isn't my DNS change showing up after the TTL expired?

Either a cache in the chain is ignoring your TTL (some ISPs cap or floor values regardless of what you publish), the change is a nameserver move bounded by the 48-hour registry TTL, or your own browser or OS cache is holding the old answer. Check the record from an independent public resolver first — if 8.8.8.8 shows the new value, the internet has it and your local cache is the problem.

What is the best TTL for a website that never changes?

14400 to 86400 is the honest range for stable records — four hours to a full day of caching cuts your authoritative query load to almost nothing. Do not go past one day: RIPE 91's measurements show most resolvers cap long TTLs anyway, and a long TTL turns any future mistake into a long-lived wrong answer.

Does DNS TTL affect failover?

Yes — TTL is the heartbeat of DNS-based failover. A standby-record TTL of 60 means clients move to the failover target within minutes; a TTL of 86400 means they keep hitting the dead primary for up to a day. Low-TTL records are exactly how operators make DNS failover responsive.