Blue–Green DNS Cutover Procedure

Overview

This chapter describes the standardized procedure used by Planisys to replace existing DNS servers (authoritative or recursive) using a Blue–Green Deployment model.

This method ensures:

  • Zero in-place modification of production DNS servers.

  • Full pre-deployment validation on a secondary server.

  • A deterministic, reversible, and auditable change.

  • A mechanism that works on top of any virtualization platform.

  • Immediate rollback by powering on the previous node.

  • Full compliance with ITIL, ISO-27001, SOC2, and NIS2 requirements.

The procedure is explicitly designed for heterogeneous customer environments where the underlying virtualization stack is unknown or varies across sites.

Terminology

  • Blue Server — the currently active production DNS server.

  • Green Server — the new Debian 13 server prepared to replace the Blue server.

  • Cutover — the moment at which the Green server becomes authoritative by assuming the production IP address.

  • Rollback — returning to the Blue server in case of unexpected behavior.

This model eliminates risk associated with in-place upgrades and ensures service continuity.

Why Blue–Green for DNS?

DNS infrastructure is especially sensitive to:

  • configuration drift

  • package version inconsistencies

  • live system modifications

  • partially applied updates

By preparing a fully functional Green server in parallel, we reduce risk to near zero:

  • No change is applied to the live Blue server.

  • Operators can validate the new stack before it serves traffic.

  • Rollback requires only powering off Green and powering on Blue.

  • No DNS clients need to update any configuration.

  • Glue records, allow-transfer ACLs, TSIG keys, RPZ policies, reverse delegations, and monitoring all remain valid.

This approach is fully defensible in any ITIL, ISO-27001, SOC2, or NIS2 audit due to its predictable, reversible, and well-documented nature.

Virtualization-Agnostic Deployment

A core requirement for this project is that the deployment must not depend on:

  • VMware

  • Proxmox

  • KVM

  • Hyper-V

  • Nutanix

  • OpenStack

  • Cloud platforms (AWS, Azure, GCP)

  • Bare metal environments

The Blue–Green strategy achieves complete virtualization agnosticism because the only mandatory operation during cutover is:

Swap the IP addresses between the Blue and Green servers.

Every hypervisor, in every datacenter or cloud provider, can perform:

  • VM shutdown

  • VM IP address reassignment

  • VM startup

No additional capabilities are required.

This makes the method ideal for environments where:

  • virtualization details are undisclosed, or

  • virtualization differs across geographic areas, or

  • change control prohibits direct manipulation of VM resources.

Cutover Strategy

The Blue–Green cutover consists of five phases.

Phase 1 — Provisioning the Green Server

  1. The client provisions a Debian 13 base VM from template.

  2. The client clones it near each legacy DNS server scheduled for replacement.

  3. Planisys connects and applies the authoritative or resolver role using Ansible.

  4. The Green server is built to match production requirements.

At this point:

  • The Blue server remains active.

  • No service disruption occurs.

  • No configuration is changed on the production server.

Phase 2 — Pre-Cutover Validation

Before the new node is activated, we conduct:

  • named-checkconf syntax verification

  • DNS resolver self-tests (recursive servers)

  • Zone-transfer and SOA consistency tests (authoritative servers)

  • DNSSEC validation tests

  • RPZ policy enforcement

  • Logging checks

  • Monitoring integration tests

Only when the Green node fully passes validation does it qualify for cutover.

Phase 3 — Coordinated Shutdown

During the approved change window:

  1. Shut down the Blue server.

  2. Shut down the Green server.

This avoids IP conflicts during reassignment.

Phase 4 — IP Swap and Activation

This is the key step in the Blue–Green model:

  1. Reassign the production IP address from the Blue server to the Green server.

  2. Boot only the Green server.

Because DNS relies heavily on stable IPs for:

  • Glue records

  • Allow-transfer ACLs

  • Notify lists

  • TSIG relationships

  • Monitoring systems

  • Resolver configurations baked into endpoints

Keeping the same IP ensures total continuity.

This swap mechanism works regardless of the virtualization system, because every hypervisor supports:

  • power off

  • IP configuration changes

  • power on

No cloud-specific APIs or proprietary automation are needed.

Phase 5 — Post-Cutover Testing

After the Green node becomes active:

  • Query tests (internal/external)

  • DNSSEC checks

  • RPZ enforcement

  • AXFR/IXFR confirmation (authoritative)

  • Recursion checks (resolver)

  • Monitoring and alert integration

  • Log verification

Once tests pass, the change is considered successful.

Rollback Plan

Rollback is simple, immediate, and risk-free:

  1. Shut down the Green server.

  2. Reassign the original IP address to the Blue server.

  3. Power on the Blue server.

  4. Notify stakeholders.

No data is lost. No configuration is changed on the Blue server at any point.

Audit Defensibility

This procedure is fully defensible in regulated or audited environments:

  • ITIL — Meets Change Enablement, Release Management, and Configuration Management requirements.

  • ISO-27001 — Ensures controlled change, documentation, traceability, rollback, and minimized impact.

  • SOC2 — Demonstrates change discipline, testing, reproducibility, and operational integrity.

  • NIS2 — Aligns with secure operations, infrastructure resilience, and risk mitigation.

Auditors especially appreciate:

  1. The absence of in-place modification.

  2. A deterministic step-by-step plan.

  3. A clearly defined rollback.

  4. Evidence of pre- and post-change testing.

  5. No dependency on specific virtualization platforms.

Summary

The Blue–Green DNS cutover procedure provides:

  • Minimal risk

  • Zero downtime

  • Total reproducibility

  • Instant rollback

  • Virtualization-agnostic operation

  • Full compliance with major audit frameworks

It is the safest and most efficient method for replacing DNS servers across multiple geographies where the underlying hypervisor varies or is unknown.