Loading page
About this tool
Pick steady-state TTLs per record type and get a timed lower-cutover-restore plan for zero-surprise DNS migrations.
This planner turns the DNS caching rule of RFC 1035 — resolvers keep an answer for the TTL attached when they fetched it — into a concrete migration schedule: when to lower the TTL before a cutover, when the change becomes fully visible afterwards, and when to restore the steady-state TTL. It also recommends steady-state TTLs per record type (A/AAAA, CNAME, MX, TXT, NS, CAA). It is for engineers planning a server move, provider switch or load-balancer swap who want the timing computed rather than guessed.
Open DNS TTL Strategy Planner on AltFTool — it loads instantly in your browser.
Paste your code or data sample into the workspace.
Pick the format, conversion, or analysis you need.
Copy the polished result straight back into your project.
The lower-before-cutover interval is derived from your actual current TTL with a stated safety factor.
Shows how fast an undo propagates while the low TTL is live — the main reason to lower it at all.
The plan ends by raising the TTL back, avoiding the silent query-load cost of permanently low TTLs.
At least one full current-TTL period before the change, because caches that fetched just before the lowering keep the old TTL that long; doubling that lead time is standard safety practice. With a 24-hour TTL, that means lowering it around 48 hours before the cutover.
Common practice is 300-3600 seconds for A/AAAA and CNAME records that might be repointed, 3600-86400 for MX and TXT, and 86400 or more for NS records. Short TTLs buy agility at the cost of more queries and slightly slower lookups; long TTLs do the opposite.
Every cache expiry forces a fresh recursive lookup, so a permanently tiny TTL multiplies query volume to your DNS provider and adds resolver latency for users, while some resolvers clamp very low TTLs upward anyway. Lower the TTL for planned changes, then restore it.
No — raising is instant in effect: caches holding the short-TTL copy expire quickly and the next fetch carries the new long TTL. Only lowering needs lead time, because you must wait out caches that still hold the old, longer TTL.