Things to Check After Changing the IP of a Domain Controller

As you might have seen in my recent rant, I made a rookie mistake and broke a bunch of stuff. One of those things was changing the IP addresses on my domain controllers. It seemed so simple. My dc1 ended in 120, and my dc2 ended in 121, but I really wanted my dc1 to be 121, and my dc2 to be 122. You can see the vision, right? Probably not a big deal, but I tried to deploy a dc03 on a different virtual host and found out a little too late that it wasn’t doing what it should have been.

Check DNS Settings on Each DC.

DNS setting on each domain controller should have another DC as the first preferred DNS server, and 127.0.0.1 should be the next. You want your domain controller to check the others before it checks itself. There should be no public DNS, like 1.1.1.1 or 8.8.8.8 configured on your domain controller. If you change a domain controller IP address, then your other DCs probably have the old IP addresses set as DNS servers

Check DNS forwarders

Next, you need to be sure that DNS forwarders are set appropriately. In my case, domain controllers were forwarding to other domain controllers for DNS forwarding, but I went ahead and changed them to forward to 1.1.1.1, with the assumption that any record not found internally would get forwarded to a public DNS server to be resolved. The problem was, my domain controllers have no internet… Whoops. Be sure that the forwarders are accessible by your domain controller. Skip the to the next header if you don’t want a long example.

The reason, or excuse, for this mistake was that my main DNS server was configured to forward .calmatlas.com addresses to my internal DNS (the domain controllers with no internet) in case I needed to get to the server for non 443 traffic, but web traffic should be resolved through a Cloudflare proxied addresses. Cloudflare allows this type of configuration by supporting something.calmatlas.com.cdn.cloudlare.net as a CNAME. In order for these CNAMEs to resolve, I needed to set my forwarder back to my main DNS server. This is a bit circular, and adds an extra hop for these CNAMed records, but works such that internal web traffic still goes through Cloudflare and doesn’t bypass security rules or analytics. Not a big deal with 4 users out of my house, but a relevant use case for a large organization.

To be clear, internally, I have additional records for administration that are different than the publicly available names that serve the website. For example, create a zone that’s public.example.com, then your admins can ssh to webserver1.public.example.com (with an A record pointing to your private address) while on the corporate network, meanwhile, users enter https://webserver.example.com/ in their browser, and another record webserver.example.com has a CNAME to webserver.example.com.cdn.cloudflare.net, letting Cloudflare proxy that web traffic. Anyone outside the corporate network, like on the internet, that goes to https://webserver.example.com/ has their DNS handled by Cloudflare directly and ends up at the same website configured in Cloudfare’s interface.

Some might argue that the “better” way to do this might be to point internal server records to internal IP addresses with an A record no matter what, since we’re already doing split brain dns anyway, but this set up provides a minor performance and is in direct contrast of zero trust methodology.

Cleanup Incorrect DNS Records

Check that there are no inaccurate records in the forward and reverse zones for yourdoamin.com, _msdcs.yourdomain.com and in zones _sites, and _tcp, also check reverse zones and remove the old IP from Properties – Name Servers.

Flush DNS Caches

Finally, on each DC in the environment you should:

• ipconfig /flushdns
• ipconfig /registerdns
• dcdiag /fix
• repadmin /syncall

Why DNS Breaks After an IP change

• DC still has stale DNS records
• DC is pointing to itself as preferred DNS
• AD Sites/Subnets not updated
• Other DCs still have cached or stale NS records

Since Active Directory is reliant on working DNS it’s important to make sure that all records are accurate, and that DNS is replicating correctly. Remove any records that reference the old IP address, and ensure that all configurations use the correct IPs.