DNS cutover TTL planner: when to lower the TTL, switch and raise it again

The problem it solves

When you change where a domain's records point, every resolver that already holds the old answer keeps using it until its time to live runs out. If the current TTL is a day, some visitors can still be sent to the old server, or the old mail host, for a full day after you switch. The usual fix is to lower the TTL first, wait at least one old TTL so that every cache holding the long-lived answer has expired it, and only then switch. This tool turns your own numbers into the exact times for each step.

• Lower the TTL no later than one current TTL before the switch.
• Switch.
• Keep the low TTL until the last old answer has aged out, plus any rollback window you want.
• Raise the TTL again.

What you enter and what is computed

You enter the current TTL of the records you will change (the longest, if there are several), the date and time you plan to switch, the earliest time you can lower the TTL, the TTL to lower it to and the TTL to set afterwards, each in seconds, minutes, hours or days. Optionally you enter a safety margin in minutes, for providers that take a while to publish a change, and a rollback hold in hours. You choose a UTC offset for each of the two dates, because a clock change can fall between them: the offset in force when you lower the TTL, and the offset in force at the switch. The page preselects each from your device for the date you type, when it is in the list.

Latest time to lower = switch - current TTL - margin. Earliest safe switch = the time you lower + margin + current TTL. Worst-case last stale answer = the later of (lowering takes effect + current TTL) and (switch + lowered TTL). Raise the TTL again no earlier than = worst-case last stale answer + rollback hold. All of it is whole-second arithmetic and the working is shown under the result. Times about lowering are shown at the lowering offset and the rest at the switch offset, each with its UTC reading when the two offsets differ.

• If you lower the TTL too late, the tool says by how much and gives the earliest switch that would be safe.
• If the planned switch is already in the past, it says so and shows the earliest safe switch from now.
• A current TTL of 0 needs no lead time; a lowered TTL above the current one is rejected.
• If the lowered TTL equals the current TTL, or the current TTL is 0, there is no lowering to schedule: the lowering deadline and the earliest safe switch are not shown, the time you can lower the TTL is optional, and the result gives only the worst case (switch plus the full current TTL) and the raise-again time.
• The rollback hold counts from the end of the worst-case stale window, not from the switch.

Assumptions and limits

The model assumes caches hold a record for at most the TTL they received, counted from when they received it (RFC 1035 section 4.1.3). The RFC calls that a maximum, not a guarantee: a resolver may cap a TTL lower, and under RFC 8767 may keep serving an expired record when it cannot refresh it. Some resolvers, browsers and applications also hold addresses longer than the TTL. So the worst-case time is a plan, not a promise, and you should check with real lookups from more than one network.

The tool assumes your DNS provider is serving the lowered TTL from the moment you lower it, plus the margin. Providers differ on the lowest TTL they accept; Cloudflare documents 60 seconds as the minimum for unproxied records outside Enterprise (30 seconds for Enterprise), so a lowered TTL under 60 seconds gets a warning. Changing nameservers at a registrar is a different case: it follows the delegation TTL at the parent zone, which you do not control from your own zone, and DNSSEC adds its own steps, covered in the linked guide.

Each time uses a fixed UTC offset that you choose for it. A fixed offset does not follow daylight saving, which is why the time you lower the TTL and the switch time have separate offsets: if the clocks change between them, give each the offset in force on its own date. A clock change after the switch moves the local reading of the end of the stale window and of the raise-again time, not the moment itself; every time shows UTC as well when the offsets differ.

• Largest TTL accepted: 2,147,483,647 seconds (RFC 2181 section 8).
• A current TTL over 7 days is noted, because RFC 8767 recommends resolvers cap TTLs at 7 days.
• Nothing is looked up: the tool does not read your actual TTL, so take it from your DNS provider.

Privacy and scope

The values stay in this page. They are not sent anywhere, not stored and not added to the web address. The tool does not change DNS and cannot confirm that a TTL change has taken effect.

If you want this done for you

The linked outcome covers comparing the old and new zone, planning the switch with the account holder and checking the website and mail after it. Cached answers can delay recovery and no zero-downtime promise follows from a timetable. Scope and price are agreed before work; send the domain and the providers involved, not registrar passwords.