=============================================== 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. .. note:: 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.