Changing DHCP options and static settings does not guarantee that every client has moved to the new DNS service. Appliances, containers, VPN profiles, hard-coded application settings, and systems that rarely start may continue querying the old resolver. Query logs are useful, but a quiet server could also mean clients are offline or relying on cached answers. What evidence should be collected before retiring the old resolver? A possible process is to monitor the old address through at least the longest DHCP lease period, record source addresses and query times, compare results with DHCP and configuration-management data, and then replace the old service with a monitored sink or forwarding resolver before removing it. How should this account for NAT, privacy addresses, split DNS, maintenance windows, and disaster-recovery systems? Is there a better final validation method than gradually blocking the old resolver and watching for failures?
3 Answers
If possible, give the replacement resolver the old IP address. Clients that still have the old address configured will then continue working while you migrate them, and you can detect them through logging. If changing ownership of the address is not practical, a temporary NAT redirect can provide a similar safety net, but it should be treated as a transition measure rather than the final configuration.
A practical approach is to leave the old address reachable but monitored for longer than the longest known lease, sleep interval, and maintenance cycle. After the normal observation period, point the address at a logging sink or forwarding resolver. That lets late or rarely used systems surface without immediately causing an outage. Keep checking during backups, patch windows, VPN tests, and disaster-recovery exercises.
Capture traffic directly on the old resolver or its address. A filter for UDP and TCP port 53 will show which source addresses are still sending queries, and running the resolver's query logging can reveal the requested names as well. Correlate those sources with DHCP leases, NAT tables, inventory, containers, VPN assignments, and configuration-management records rather than relying on IP addresses alone.
Even with address reuse, keep enough logging and inventory work in place to find hard-coded settings. Otherwise those clients may appear healthy while remaining dependent on an address that is supposed to be retired.