DNS TTL Calculator
Convert a DNS TTL from seconds into minutes, hours, and days — and plan migrations without cache surprises. Presets 60, 300 (5 min), 3600 (1 h), 86400 (24 h).
Results
Enter data and click Calculate.
What TTL controls
TTL (Time To Live) tells resolvers how long they may cache an answer (in seconds). It is not domain registration lifetime or a registrar “propagation deadline” — only a caching hint. This calculator converts seconds into minutes, hours, and days (e.g. 300 = 5 min, 86400 = 24 h).
Recursive resolver caching
- A resolver (ISP / 1.1.1.1 / 8.8.8.8) keeps the answer until TTL expires — different networks can see new and old IPs at the same time.
- Browsers and OSes also cache (hence “works for me, not for you”).
- NXDOMAIN has its own SOA timings — that also feels like “DNS won’t refresh.”
TTL quick-reference table
Common values at a glance. Form presets: 60, 300, 3600, 86400.
| Seconds | Minutes | Hours / days | Typical use |
|---|---|---|---|
| 60 | 1 | — | Tests, emergency cutover (more DNS queries) |
| 300 | 5 | — | Before migrations / failover |
| 600 | 10 | — | Short compromise when changes are frequent |
| 3600 | 60 | 1 h | Stable services — common default |
| 14400 | 240 | 4 h | Quieter DNS traffic, slower change |
| 86400 | 1440 | 24 h / 1 day | Rarely changed records; risky right before cutover |
Migration and delays
- Before cutover: lower TTL (e.g. 86400 → 300), wait ≥ the old TTL, then change the record; after things stabilize, raise TTL (e.g. 3600).
- Setting 300 today does not flush yesterday’s caches that still hold a 86400 TTL.
- If you still see the old IP: different resolver, OS/browser cache, CDN, or wrong record/zone — check with
dig @1.1.1.1.
A / AAAA / CNAME / MX scenarios
- A / AAAA — TTL sits directly on the IP. Web server move: short TTL → change IP → observe → longer TTL.
- CNAME — clients follow the target; both the CNAME TTL and the target record TTL matter. A short CNAME with a long target A can still “stick” on the old IP.
- MX — mail cutover: lower MX TTL (and related MX host A/AAAA) in advance; keep priorities coherent during the switch.
- Multiple NS / anycast — consistent publication on all NS; TTL will not fix a split zone.
Pre-change checklist
- Note the current TTL and convert it in the calculator.
- Lower to 300 (or 60 in an emergency), wait ≥ the previous TTL, change the record, verify on 2–3 resolvers.
- After things stabilize, raise TTL (e.g. 3600) and record real timings in the runbook.
Example: Monday 10:00 — 86400 → 300; Tuesday 10:00 — change A; Wednesday — raise to 3600.
FAQ — TTL, migrations, and “propagation”
Practical questions about TTL values and cutover planning.
- What are 300, 3600, and 86400 in practice?
300= 5 minutes,3600= 1 hour,86400= 24 hours. The calculator also shows fractional hours/days.- Is TTL the same as DNS propagation time?
- Not exactly. TTL is the max cache lifetime. “Propagation” is the mix of TTL, resolver caches, and when the record actually changed on the NS.
- How do I prepare a migration from TTL 86400?
- Set e.g. 300, wait at least 24 h (the old TTL), then change the record. After success, raise back to 3600+.
- Why does dig show the new IP but my phone shows the old?
- Different resolver / app cache. Query the same resolver the phone uses, or flush the device DNS cache.
- Is a shorter TTL always better?
- No — shorter means more queries and NS load. For calm services prefer 3600–14400; reserve short TTLs for change windows.
- CNAME TTL vs A TTL
- Both matter. Even a short CNAME cannot outrun a long TTL on the target A when the destination IP changes.
- What about MX when moving mail hosting?
- Lower MX and MX-host A/AAAA TTLs early, keep parallel receive if the provider allows, then switch targets/priorities.
- Is 60 seconds safe permanently?
- It works technically but creates DNS chatter. Use it during incidents or tests, then raise it.