Replacing DNS Servers Using Pre-Provisioned Nodes

Overview

This chapter documents the standard procedure for replacing existing DNS (resolver or authoritative) servers with new Debian 13 nodes. The method described here follows a blue–green deployment strategy and is virtualization-agnostic, allowing us to operate safely even when the client does not disclose or standardize their virtualization environment.

The workflow is:

  1. The client provisions a single Debian 13 base virtual machine.

  2. The client clones this VM close to each legacy DNS server.

  3. Planisys applies configuration and role-specific software using Ansible.

  4. A coordinated cutover window is scheduled.

  5. Both servers (old and new) are powered off.

  6. IP addresses are swapped.

  7. Only the new server is powered on.

This process ensures:

  • Predictable, auditable changes

  • Immediate rollback capability

  • Zero modification of the production node prior to cutover

  • No dependency on the client’s hypervisor or orchestration layer

  • Full compliance with modern service-management frameworks

This approach is fully defensible in any ITIL, ISO-27001, SOC2, or NIS2 audit, because it isolates risk, maintains configuration integrity, and provides a documented rollback path.

Rationale

Why this method is used:

  • It avoids in-place upgrades, which are risky for DNS infrastructure.

  • It ensures the new node is fully validated prior to deployment.

  • It preserves all existing NS glue, ACLs, TSIGs, and firewall rules by reusing the original server’s IP address.

  • Rollback is trivial: power on the previous system.

  • The client remains free to use any virtualization stack (VMware, Proxmox, KVM, Nutanix, Hyper-V, OpenStack, etc.), because no hypervisor-specific operations are required.

  • Every action can be logged, approved, and audited.

This method provides the highest possible operational safety while maintaining a fast deployment cycle.

ITIL Change Control Document Template

The following template is provided to the client for each server replacement. It follows ITIL Change Enablement, Release Management, and Configuration Management principles.

Nota

This template is fully defensible in any ITIL, ISO-27001, SOC2, or NIS2 audit. It contains all required elements: scope, risk assessment, rollback plan, validation steps, responsibilities, and clear communication procedures.

Formal ITIL Change Control Document

Change ID: CHG-{{ change_number }} Title: Replacement of DNS Server {{ hostname }} with Debian 13 Node Service Category: Authoritative DNS / Recursive DNS Change Type: Standard + Pre-Approved Pattern (Blue–Green Deployment) Requested By: Planisys DNS Operations Customer: {{ customer_name }}

1. Purpose and Scope

This change covers the replacement of the existing DNS server {{ old_hostname }} with a newly provisioned Debian 13 server {{ new_hostname }}.

The operation includes configuration, validation, shutdown of both servers, IP-address swap, and activation of the new node.

The procedure is hypervisor-agnostic and works independently of the customer’s virtualization environment.

2. Description of Change

The customer deploys a Debian 13 base VM template and clones it near the legacy DNS server. Planisys configures the new node remotely via Ansible. During the change window:

  1. Both servers are powered off.

  2. The IP address of {{ old_hostname }} is reassigned to {{ new_hostname }}.

  3. Only the new node is powered on.

  4. Health checks are executed.

  5. Monitoring is updated.

No modification is performed on the legacy production server prior to shutdown.

3. Justification

  • Minimizes operational risk.

  • Enables complete validation prior to activation.

  • Ensures reproducible deployments across 33+ geographically distributed nodes.

  • Provides an immediate rollback path.

  • Fully compliant with ITIL, ISO-27001, SOC2, and NIS2 audit requirements.

  • Virtualization-agnostic approach avoids dependency on customer infrastructure.

  • Avoids in-place upgrades and configuration drift.

4. Risk Assessment

Risk Level: Low

Potential Risks:

  • Misconfiguration of DNS service

  • Unexpected behavior after IP reassignment

  • VM template inconsistencies

Mitigations:

  • Full pre-deployment validation on the new server

  • Repeatable Ansible automation

  • Blue–green strategy ensures no service interruption

  • Instant rollback by powering on the previous server

  • Post-deployment monitoring and alerts

5. Implementation Plan

  1. Customer provisions and clones a Debian 13 VM.

  2. Planisys applies configuration via Ansible.

  3. Pre-cutover verification: * named-checkconf * Zone transfer tests (authoritative) * Resolver tests (recursive) * DNSSEC validation (if applicable) * RPZ verification

  4. Change window: * Shut down both servers * Swap IP addresses * Boot the new server * Execute functional test suite

  5. Update documentation, CMDB, and monitoring.

6. Rollback Plan

Rollback is immediate and requires no reconfiguration.

  1. Shut down the new server.

  2. Reassign original IP to the legacy server.

  3. Boot the legacy server.

  4. Notify stakeholders.

Rollback time: typically 2–5 minutes.

7. Test and Validation Plan

Post-activation tests:

  • DNS UDP/TCP port checks

  • Internal and external zone queries

  • DNSSEC validation

  • RPZ enforcement tests

  • AXFR/IXFR tests (authoritative)

  • Recursion checks (resolvers)

  • Monitoring integration

Deployment is considered successful when all tests pass.

8. Communication Plan

  • Notify customer NOC 24h prior to change.

  • Notify all stakeholders when cutover begins.

  • Notify stakeholders at successful completion.

  • Provide post-change summary and verification logs.

9. Backout Implications

No data loss or configuration change occurs on the legacy server. Rollback is trivial and operationally safe.

10. Approval

  • Customer Change Manager: ____________________

  • Planisys Change Manager: ____________________

  • Scheduled Window: ____________________

Summary

This replacement methodology provides a repeatable, low-risk, virtualization-agnostic, and audit-compliant way to deploy new DNS infrastructure across dozens of sites.

It meets strict ITIL requirements, minimizes service disruption, and ensures that every deployment step is measurable, testable, and reversible.