We currently use two Windows Server 2016 domain controllers for DNS. I've built Server 2022 replacement domain controllers, but our IP addressing scheme has changed, so the new servers have different addresses. The environment also includes many non-Windows devices with statically configured DNS servers, and updating all of them manually could cause a service interruption. For an Exchange server, I previously added a second NIC using the old server's MAC and IP, but I'm unsure whether anything similar is safe or appropriate for domain controllers. What is the safest migration strategy, and how can I keep DNS available while updating the clients?
4 Answers
Do not add a second NIC or try to give a domain controller multiple addresses just to preserve the old DNS IP. Multihomed DCs can register unintended addresses through Netlogon and dynamic DNS, which can break DC discovery, authentication, and other Active Directory services. Bring the new DCs online with their proper addresses, update clients through DHCP or management tools, and then demote the old DCs normally.
Another clean design is to separate client recursive DNS from Active Directory DNS. Clients query dedicated recursive resolvers that keep stable addresses, while those resolvers forward internal lookups to the domain controllers. That avoids tying every device to a DC address, although it adds infrastructure and should be planned rather than rushed. In all cases, verify AD Sites and Services, DNS registration, DHCP settings, firewall rules, NTP dependencies, and application configurations before demoting the old servers.
The simplest approach is to run the old and new domain controllers in parallel. Move clients to the new DNS addresses gradually, preferably by changing DHCP options and using scripts or remote-management tools for devices that are statically configured. Monitor DNS query logs on the old servers to identify systems that still use them. DHCP reservations can also reduce this kind of maintenance in the future.
If changing the old addresses immediately is impossible, place separate DNS forwarding or proxy servers on the old addresses temporarily and forward requests to the new domain controllers. A carefully scoped NAT rule for DNS can also serve as a short-term compatibility measure. Treat this as a migration bridge, not a permanent design, and make sure it does not interfere with other domain-controller traffic such as LDAP, Kerberos, SMB, RPC, or TLS.
The main challenge is the equipment that cannot use DHCP and has the old DNS addresses hard-coded. I’ll need to inventory those systems and update them separately.