Making a DNS Change Without Causing an Outage
DNS changes are among the least reversible things you do routinely. The change itself is instant; undoing it is not, because the old value is now cached in resolvers you do not control for as long as the TTL you set before you started. Almost everything that makes a DNS change safe happens days before you edit the record.
Days ahead: lower the TTL
Whatever TTL the record carries is your minimum rollback time. A record at 86400 means a mistake takes up to a day to undo, and no amount of urgency shortens that. Drop it to something small — 300 seconds is typical — and wait at least the length of the old TTL before making the real change, so every resolver has picked up the short one. Skipping this is the single most common reason a DNS incident lasts hours instead of minutes.
Before: know what you are changing from
Record the current answer from more than your own machine. Query several resolvers explicitly so you have a before-state to compare against, and confirm the record you are about to edit is the one actually being served. A surprising number of DNS changes are made in a zone that is no longer authoritative, at a registrar that was replaced, or on a provider that was migrated away from. The symptom is an edit that appears to succeed and changes nothing, and it can absorb an afternoon.
Check delegation while you are there. If the registry delegates to different nameservers than the ones you are editing, nothing you do takes effect and everything on your side looks correct.
During: verify against resolvers, not your cache
Your own machine is the least reliable place to check, because it has a cache and possibly a stub resolver with its own. Query the authoritative nameservers directly to confirm the zone is serving the new value, then query public resolvers to watch it spread. Those are different questions and it matters which is failing: authoritative serving the old value means the change did not apply; authoritative correct with resolvers lagging means it applied and you are waiting.
Expect disagreement during the window. Partial propagation is normal and not a signal to roll back — that decision follows from whether the authoritative answer is right, not from whether every resolver agrees yet.
After: do not decommission early
The old destination must keep serving until the last cached answer expires, and longer if anything ignores TTLs — which some resolvers and many application-level caches do. Turning off the old host as soon as the new one starts receiving traffic is what converts a clean migration into a partial outage for the tail of clients still holding the old address.
Once it has settled, put the TTL back up. A permanently short TTL means more query load and a hard dependency on your nameservers being reachable at all times, which is a worse trade than it sounds.
The rollback you should have written down
Before editing, record the exact previous value somewhere outside the system you are changing. Under pressure, reconstructing what a record used to be from memory is where second mistakes come from — and the second mistake is usually worse, because it is made quickly.
Tools used in this playbook
For the underlying concepts rather than this procedure, NetTests.NET covers the topic in more depth in its guide.