Big DNS change on the calendar, no plan B if it goes wrong
DNS mistakes are notorious because the error spreads as long as TTL is alive, and you cannot revert instantly. A working rollback plan lowers TTL beforehand, documents the previous value, and has a kill switch.
Try this first
- 1Lower TTL to 300 seconds at least 24 hours before the change, not during the change itself.
- 2Snapshot the current zone (BIND export or control-panel screenshots) and store it where you can reach it without logging in.
- 3Schedule the change outside business hours when possible, especially for MX and NS, and keep at least two people on standby with DNS and registrar access.
- 4Test immediately after publish with dig from multiple resolvers (1.1.1.1, 8.8.8.8, your own ISP) and not just via your browser, browser cache distorts.
- 5Define a kill-switch criterion in advance: 'If within 15 minutes the monitor shows X% errors, we revert A to Y.' Decision fatigue is your biggest enemy.
When to bring us in
If a major DNS or mail migration is on the calendar and you want someone there to run the cutover and roll back on signal, we can plan it together.
See also
- Domain expires tomorrow and nobody saw the emailAn expired domain doesn't transfer instantly. There's a redemption window, but you pay extra.
- Unsure whether to enable auto-renewDisabling auto-renew only makes sense for domains you'll truly drop. For anything live, just keep it on.
- New registrar asks for auth code, can't find itEPP code or transfer code is the password to move a domain from registrar A to B.
None of the above fits?
Describe your situation below. We pass your input plus the steps you already saw to our AI and return tailored next-step advice. If it's too risky to DIY, we'll say so.
Or skip the DIY entirely
Our Managed IT clients do not look these things up. One point of contact, a fixed monthly price, resolved within working hours.