Intermittent Azure DNS Resolution Issues With With New Domain Controller

The default option for DNS resolution on an Azure virtual network is to use the Azure DNS service.  This is perfectly fine for regular Internet requests, if you need the capability to register internal DNS records for Active Directory then you will typically need to run your own DNS service.  This is the case here and is also something observed with multiple customers.  In each of these cases the DNS queries must be sent to the DCs in the lab so that the necessary internal DNS records can be registered (A, SRV & SOA for example) and then queried by the internal systems.

Typical Virtual Network Setup

Rather than set the DNS configuration per VM, usually this is done at the virtual network level.  In the below screen shot we are looking at the properties of a virtual network.  This is how my common set up the virtual network for an Azure hosted lab.

Since the first valid IP which can be assigned is .4 on an Azure network, I typically use the .4 and .5 addresses for Active Directory VMs.  Two IPs are used as there are two DCs.  The remaining machines in the lab are then statically assigned addresses starting at .10  - this is just how I personally deploy the machines so if I happen to see a machine with an IP of .6 then it tells me I forgot to statically assign it an address.

Typically the virtual network configuration is done prior to deploying any VMs as we need to plan out the network IDs and overall security right at the start.

Back to the subject in hand – DNS.

The Azure Virtual Network is set to distribute the manually specified DNS IPs so that all the VMs on this network are configured consistently.  This means that we do not have to waste time setting or updating the configuration on each VM, and overall uniformity is greatly improved.

You would think that we are done, and no issues would arise.  Alas no.

The symptom you will likely encounter is intermittent DNS resolution.  Clients will be able to resolve DNS names in some cases, but in others they will not.

Lab DNS Configuration

One thing that I've noticed is that when the DC is promoted, you may find that a forwarder has been unexpectedly added to the DNS server configuration.

Here are two examples from different labs.  As you can guess by the server names, they are different versions of Windows.  Note that the Azure virtual network DNS settings were configured prior to starting the DC promotion.

For the server on the right, it is unable to  even resolve the name of the forwarder in the lab

Removing the Unwanted Forwarder

The steps below assume that you do not want to use any forwarders, and wish to rely on the default configuration of using the root DNS servers.

To remove the unwanted forwarder, perform the following:

• Launch DNS Manager in the VM.
• Right-click the server name in DNS Manager and select Properties.
• Select the Forwarders tab.
• Click the Edit button, and remove any forwarders then click OK.
• Ensure you select Use root hints if no forwarders are available and click OK.

The problem should now be resolved, and the server should look like this:

You may need to clear the DNS cache on the client when verifying.

Cheers,

Rhoderick