DNS TTL Calculator

Convert a raw DNS TTL (time-to-live) value between seconds and a human-readable format, build a TTL from days/hours/minutes, and use the migration planner to know exactly when to lower your TTL before a record change — so you do not strand visitors in stale caches.

How to use the DNS TTL Calculator

There are three ways to use this tool:

  1. Seconds → human readable: Type a TTL value (in seconds) into the TTL in seconds field. The output instantly shows it broken down into days, hours, minutes, and seconds, plus common-sense context.
  2. Duration builder: Enter days, hours, and minutes to construct a TTL. The equivalent seconds value is shown so you can paste it directly into your DNS zone file or provider's UI.
  3. Migration planner: Enter your current TTL (the TTL the record has right now) and the target TTL you want after the change. The planner tells you: (a) how far in advance to lower the TTL so that all resolvers' caches expire before you make the actual record change, (b) when to make the change, and (c) how long to expect before the new record is fully propagated based on the target TTL.

The key insight for migrations: DNS resolvers cache a record for exactly the TTL value they received. So before changing a high-TTL record, you must lower the TTL and wait at least one full old-TTL period for all caches to refresh and pick up the shorter TTL. Only then make the actual value change.

What is DNS TTL and why does it matter?

TTL (Time To Live) is an integer field on every DNS resource record that tells resolvers how many seconds they may cache the record before they must re-query the authoritative nameserver. A TTL of 3600 means resolvers cache the answer for one hour; a TTL of 300 means five minutes. The value travels with the record — every resolver that caches it also stores when it expires, and the clock starts when the resolver first fetched the record, not when you changed it.

The TTL is a tradeoff between propagation speed and nameserver load. A very low TTL (60–300 s) means changes propagate quickly (within minutes), but every resolver must re-query your nameserver far more frequently, increasing DNS query volume. A high TTL (86400 s = 1 day or more) reduces query load but means changes take up to that TTL to be visible everywhere. For most production domains, 3600 s (1 hour) is a sensible default. Reduce to 300 s in the hours before a planned record change, then restore after propagation is confirmed.

One important nuance: there is no global "DNS propagation delay." Propagation means "waiting for cached records at all resolvers to expire." Different resolvers fetched the record at different times, so the worst-case propagation time is one full TTL period, not some fixed worldwide window. The 24–48 hour figure you sometimes hear is a legacy from when many registrars had 24-hour SOA refresh intervals — it does not reflect actual resolver caching behavior for records with shorter TTLs.

Common use cases

  • Pre-migration TTL lowering — Calculate when to reduce a high-TTL A record before migrating to a new server IP, ensuring the change is live everywhere within minutes.
  • Failover planning — Determine how quickly a low-TTL record propagates so you can estimate recovery time for automated DNS failover scenarios.
  • Zone file authoring — Convert human-readable durations (2 days, 6 hours) to the raw seconds expected by BIND zone files and most DNS APIs.
  • Explaining TTL to stakeholders — Quickly translate a seconds value into plain English so non-technical stakeholders understand why a record change is not instant.
  • SOA record tuning — The SOA record contains a minimum TTL for negative caching (NXDOMAIN responses). Use the calculator to find the right balance for domains with frequent subdomain additions.

Frequently asked questions

What is a good default TTL?
3600 seconds (1 hour) is a sensible production default for most records. It balances propagation speed with reasonable nameserver load. Use 86400 (1 day) for very stable records like MX and SPF; use 300 (5 minutes) during migrations or for health-check-driven failover.

How long does DNS propagation really take?
For records with a low TTL (300 s or less), propagation completes in 5–10 minutes for most resolvers. For records that had a high TTL before the change, you must wait one full old-TTL period after lowering it before the change propagates within that new TTL window.

Can TTL be 0?
Technically yes, but it is not recommended. A TTL of 0 tells resolvers not to cache at all, which can severely increase query load and may cause some resolvers to treat the record as invalid. Use 60 or 300 as the practical minimum.

Does TTL affect email deliverability?
MX and SPF records with very low TTLs can sometimes trigger spam-filter heuristics that treat low-TTL sender domains as suspicious. Keep MX and SPF TTLs at 3600 or higher under normal conditions.

What is the maximum TTL value?
The DNS protocol stores TTL as a 32-bit unsigned integer, giving a theoretical maximum of 4,294,967,295 seconds (~136 years). In practice, values above 86400 (1 day) are rarely useful and many resolvers cap their cache at a lower value regardless.