Self-Replicating DNS Forwarders Problems in Windows Server 2008/2012
In two of my previous articles this month I wrote about “Best Practices for DNS Forwarding” and “Configure DNS forwarders in Windows Server 2012 R2.” If you followed my advice and configured your DNS servers the proper way, then you may also want to read this article that deals with self-replicating DNS forwarders problems in Windows Server 2008 and Windows Server 2012.
Self-Replicating Problems with DNS Forwarders
When you configure DNS forwarders, the changes you made are written in the computer’s local registry. Unlike the case of conditional forwarders, the forwarders’ settings are not replicated between DNS servers. What you configure on one DNS server stays there. For example, you can have a physical site with two DNS servers, where one is configured as a forwarder. Then, in another physical site you can have a couple of additional DNS servers,where one of which is a forwarder.
As I found out, however, there is a strange behavior that might happen when you try using multiple DNS servers, and this is something that unless you know what is causing it, may cause quite a few problems.
When you are using more than one DNS server in an Active Directory-based network, it’s mostly likely that your DNS server are running on the same machines as your Domain Controllers (DCs). Why? Well for one, it makes the life of an IT guy more simple. A second reason is that when you configure a DNS server on a DC, replicating the DNS zones becomes a much more robust and secure task, much more than if you’d be hosting the DNS role on a regular server.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
And Microsoft makes it easy for us to take that path, offering us the option of installing the DNS role as a part of the Domain Controller promotion phase. We’ll get back to that in a moment.
International DNS Forwarding
Let’s move on. Looking at the following diagram, if you have a UK site with two DNS servers that are probably also DCs, and you’re using a UK-based ISP, then it’s most likely that the DNS servers are configured to use the UK-based ISP’s DNS servers as forwarders.
DNS forwarder diagram: UK-based site (Image: Daniel Petri)
Two months later your CTO calls you over and informs you that the company has acquired a USA-based company, and your task is to add their existing network to your company’s network. Since the acquired company only has around 100 users and runs all their resources locally, you decide to create a new site in Active Directory (using site-to-site VPN), and place a third DC in that site. Of course, you want to also configure it as a DNS server.
So you remote into a server that was created by one of your local IT guys and after some preparations (like giving it a valid IP address in the USA site and configuring it as a member of the existing domain), you install the AD-DS role on it, and promote it to become the domain’s third DC. After 30 minutes or so, you’re all set up. After checking AD replication and other settings, you call it a day, not before you instruct the IT guy to configure all USA-based computers to use the new DNS’s IP address as their DNS server in TCP/IP configuration.
When the USA employees come to work the next morning, you’re still asleep. But a few moments later you are awakened by their calls, screaming at you because they lost Internet connectivity. What’s more is that you’re hearing complaints about email and browsing is not working, where Lync and other Internet-based services are also not functional.
So what went wrong?
DNS forwarder diagram: UK to USA DNS forwarding. (Image: Daniel Petri)
When you promoted the new server to be a DC, you were also asked if you also wanted it to run the DNS server role. You chose “Yes,” and it immediately installed the DNS server role on it.
Original DNS Server Forwarders’ Lists in the New DNS Role
Here comes the tricky part. By doing this, the server automatically pulled the forwarders’ list from the original DNS servers, and it placed these settings in the new DNS server role. This behavior is by default and cannot be changed. Since it’s likely that in the new site you’re using a different ISP than the UK-based ISP, the original forwarder settings may not work for you there. The UK-based ISP will not “honor” your DNS server’s forwarding requests because it does not recognize it as coming from its own IP range.
So be aware of this. In this example, you must manually change the forwarders’ list on the new DNS+DC server to use the USA-based ISP’s DNS servers as forwarders.