Cloudflare nameserver cutover runbook
Use this runbook to coordinate Cloudflare nameserver cutover. It covers registrar access, current and target nameservers, TTL timing, resolver validation, owner assignments, service checks, rollback criteria, and post-cutover monitoring.
Use this runbook to coordinate Cloudflare nameserver cutover. It covers registrar access, current and target nameservers, TTL timing, resolver validation, owner assignments, service checks, rollback criteria, and post-cutover monitoring.
Topics: cloudflare, resource, cloudflare, nameserver, cutover, runbook
Machine-readable context: /ai-index.json
Step by step
Runbook procedure
- 1
Confirm registrar login and the authority to change nameservers, and record the current authoritative nameservers exactly as the registrar shows them so you have a precise rollback target.
- 2
Verify the Cloudflare zone is fully populated and 'pending nameserver update' is the only thing left — every record recreated, proxy status set, SSL/TLS mode confirmed — before any registrar change.
- 3
Note the assigned Cloudflare nameservers for the zone (they are account-specific) and the registrar's NS-update and DNSSEC handling, including whether DS changes are manual or delayed.
- 4
Lower TTLs on key records ahead of the window and check the parent zone's NS TTL, since that governs how long old nameservers stay cached after the swap.
- 5
Assign owners for the window: who changes the registrar NS records, who watches resolver propagation, who runs service checks, and who holds the rollback decision.
- 6
Make the change: replace the registrar nameservers with the Cloudflare-assigned pair and confirm Cloudflare reports the zone as Active.
- 7
Monitor rollover by querying multiple public and ISP resolvers for NS, A/AAAA, and MX, watching for both new and stale answers, and run service checks (web over TLS, mail, APIs) as resolvers flip.
- 8
Hold for the propagation/monitoring window against the go/no-go criteria; if checks fail, revert the registrar nameservers to the recorded originals, otherwise confirm stable resolution and close the cutover.
Risk register
Risks to control
The Cloudflare zone is incomplete when nameservers are switched, so missing records stop resolving.
Gate the registrar change on a fully populated and validated zone — confirm record count, proxy status, and TLS readiness before touching the registrar.
The wrong or default nameservers are entered, since Cloudflare assigns account-specific pairs.
Copy the exact assigned nameservers from the Cloudflare dashboard for that zone and confirm Cloudflare marks the zone Active after the change.
DNSSEC is still active at the registrar, so the chain of trust breaks the instant authority moves.
Confirm DNSSEC is disabled and the DS record removed (through a proper unsigned window) before the nameserver swap, and re-enable on Cloudflare afterward.
High parent-zone NS TTLs leave old nameservers cached, stretching rollover and rollback far longer than expected.
Lower TTLs ahead of time, check the NS TTL, and size the monitoring window to the longest cached value rather than assuming instant propagation.
Resolution looks fine from one location but is broken elsewhere because only one resolver was checked.
Query several public and ISP resolvers across regions for NS, address, and mail records, and treat propagation as incomplete until they agree.
Rollback is unclear mid-window because the original nameservers were not recorded.
Record the exact original registrar nameservers and write reverting them as the explicit rollback action with a named decision owner.
Output
Useful deliverables
- Registrar access and authority confirmation, with the current authoritative nameservers recorded verbatim as the rollback target.
- Zone-readiness sign-off confirming all records, proxy status, and SSL/TLS settings before the change.
- The Cloudflare-assigned nameserver pair and the registrar's documented NS/DNSSEC update behavior.
- TTL lowering schedule including the parent-zone NS TTL and the resulting monitoring window length.
- Owner assignment matrix for the change, propagation watch, service checks, and rollback decision.
- Resolver and service validation checklist across multiple public/ISP resolvers for NS, address, mail, and API checks.
- Go/no-go criteria and rollback procedure reverting to the recorded original nameservers.
Keep reading
Related resources
FAQ
Frequently asked questions
Common questions teams ask when putting this resource into practice.
How long after I change nameservers does the cutover complete?
It is governed by the parent zone's NS TTL and resolver caching, not by Cloudflare. Old nameservers can keep answering until cached NS records expire, so size your monitoring window to the longest TTL involved and treat propagation as done only when multiple resolvers agree.
Why does Cloudflare give me specific nameservers instead of generic ones?
Cloudflare assigns an account-specific nameserver pair per zone, so you must use the exact ones shown for that zone in the dashboard. Entering the wrong pair leaves the zone inactive. Confirm Cloudflare reports the zone as Active after you update the registrar.
What do I check before I touch the registrar?
That the Cloudflare zone is complete and validated — every record recreated with correct proxy status, SSL/TLS mode confirmed, DNSSEC handled — and that you have recorded the current nameservers as a rollback target. The registrar change should be the last step, not the first.
How do I roll back a nameserver cutover?
Revert the registrar's nameservers to the originals you recorded before the change. Because rollback is also bounded by NS TTLs, keeping those TTLs low before the window is what makes a fast revert possible, and a single named owner should hold the rollback decision.
Nanosek
Prepare nameserver cutover
Nanosek can turn this resource into a practical delivery plan for your environment — with rollback planning, stakeholder alignment, and 24/7 managed operations support.