Procedimiento de Cutover DNS Blue–Green

Descripción General

Este capítulo describe el procedimiento estandarizado utilizado por Planisys para reemplazar servidores DNS existentes (autoritativos o recursivos) utilizando un modelo de Blue–Green Deployment.

Este método garantiza:

  • Cero modificaciones in-place sobre los servidores DNS de producción.

  • Validación completa previa al despliegue sobre un servidor secundario.

  • Un cambio determinístico, reversible y auditable.

  • Un mecanismo que funciona sobre cualquier plataforma de virtualización.

  • Rollback inmediato simplemente encendiendo el nodo anterior.

  • Cumplimiento total con requerimientos de ITIL, ISO-27001, SOC2 y NIS2.

El procedimiento fue diseñado explícitamente para entornos heterogéneos de clientes donde la plataforma de virtualización subyacente es desconocida o varía entre distintos sitios.

Terminología

  • Blue Server — el servidor DNS de producción actualmente activo.

  • Green Server — el nuevo servidor Debian 13 preparado para reemplazar al servidor Blue.

  • Cutover — el momento en el cual el servidor Green se vuelve autoritativo al asumir la dirección IP de producción.

  • Rollback — retorno al servidor Blue en caso de comportamiento inesperado.

Este modelo elimina el riesgo asociado a upgrades in-place y garantiza continuidad del servicio.

¿Por qué Blue–Green para DNS?

La infraestructura DNS es especialmente sensible a:

  • configuration drift

  • inconsistencias de versiones de paquetes

  • modificaciones sobre sistemas en producción

  • actualizaciones parcialmente aplicadas

Preparando un servidor Green completamente funcional en paralelo, reducimos el riesgo prácticamente a cero:

  • No se aplica ningún cambio sobre el servidor Blue en producción.

  • Los operadores pueden validar el nuevo stack antes de servir tráfico.

  • El rollback solo requiere apagar Green y volver a encender Blue.

  • Ningún cliente DNS necesita actualizar configuraciones.

  • Glue records, ACLs de allow-transfer, claves TSIG, políticas RPZ, delegaciones reversas y monitoreo permanecen válidos.

Este enfoque es completamente defendible en auditorías ITIL, ISO-27001, SOC2 o NIS2 debido a su naturaleza predecible, reversible y bien documentada.

Despliegue Agnóstico de Virtualización

Un requerimiento fundamental de este proyecto es que el despliegue no debe depender de:

  • VMware

  • Proxmox

  • KVM

  • Hyper-V

  • Nutanix

  • OpenStack

  • Plataformas cloud (AWS, Azure, GCP)

  • Entornos bare metal

La estrategia Blue–Green logra un enfoque completamente agnóstico de virtualización porque la única operación obligatoria durante el cutover es:

Intercambiar las direcciones IP entre los servidores Blue y Green.

Todo hypervisor, en cualquier datacenter o proveedor cloud, puede realizar:

  • apagado de VM

  • reasignación de IP de VM

  • encendido de VM

No se requieren capacidades adicionales.

Esto hace que el método sea ideal para entornos donde:

  • los detalles de virtualización no son revelados, o

  • la virtualización difiere entre distintas áreas geográficas, o

  • el control de cambios prohíbe manipulación directa de recursos de VM.

Estrategia de Cutover

El cutover Blue–Green consiste en cinco fases.

Fase 1 — Provisioning del Servidor Green

  1. El cliente provisiona una VM base Debian 13 desde template.

  2. El cliente la clona cerca de cada servidor DNS legacy programado para reemplazo.

  3. Planisys se conecta y aplica el rol autoritativo o resolver utilizando Ansible.

  4. El servidor Green es construido para cumplir los requerimientos de producción.

En este punto:

  • El servidor Blue permanece activo.

  • No ocurre interrupción de servicio.

  • No se modifica ninguna configuración sobre el servidor de producción.

Fase 2 — Validación Pre-Cutover

Antes de activar el nuevo nodo, realizamos:

  • verificación sintáctica con named-checkconf

  • self-tests de resolvers DNS (servidores recursivos)

  • tests de transferencia de zonas y consistencia SOA (servidores autoritativos)

  • tests de validación DNSSEC

  • validación de políticas RPZ

  • verificación de logs

  • tests de integración con monitoreo

Solo cuando el nodo Green supera completamente las validaciones queda habilitado para el 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. Encender el servidor Blue.

  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.