Changing a DNS record with a rollback path: TTL lowering, cutover and verification

Goal

Move a hostname to a new address or provider without a period in which some users reach a dead target, and be able to revert within minutes rather than hours.

Prerequisites

Write access to the authoritative zone, a way to query authoritative servers and public resolvers directly (dig @server name type), and the new target already serving and tested by address or under a temporary name.

Steps

1. Read the current TTL. RFC 1035 defines it as the time interval that the record may be cached before the source is consulted again; any cache holding the record keeps it for up to that long after the change.
2. Lower the TTL to a few minutes (for example 300 seconds) and wait at least one full old TTL, so every cache that held the long TTL has expired it and refetched with the short one. Skipping this wait is a common reason a change appears to "propagate" for a day.
3. Prepare the rollback: write down the exact old record, and keep the old target running throughout.
4. Make the change. Check the authoritative servers first, then public resolvers, then a resolver on the local network.
5. Watch the new target's logs for traffic arriving and the old target's logs for traffic fading over the short TTL. Do not stop the old target until it has been quiet for longer than the TTL. RFC 8767 allows a recursive resolver that cannot contact the authoritative servers to keep answering with data whose TTL has expired, and suggests a maximum stale timer between 1 and 3 days; this only matters if the authoritative servers are unreachable, which is an argument for not changing DNS during a provider incident.
6. Once the old target is quiet, raise the TTL back to its normal value. Rollback is the same edit in reverse and takes one short TTL to take effect, which is why the TTL stays low until confirmation.
7. Record both record values and the timestamps in the change calendar.

Expected result

Traffic moves within minutes of the change, no user hits a dead target, and reverting is a single record edit with a known worst-case delay.

Limits and test basis

Some clients ignore TTLs: long-lived connections, runtime address caches, corporate proxies; those need a restart or their own expiry. Negative caching of a name that did not exist yet has its own TTL: RFC 2308 sets it from the minimum of the SOA record's MINIMUM field and the SOA's own TTL. The procedure follows the cited RFCs; no propagation timings are claimed beyond TTL arithmetic.