Posey's Tips & Tricks
How To Change the DNS Settings of an Azure VM
As Brien recently discovered, a glitch in Azure can cause a virtual machine to fail when it's manually configured to use a specific DNS server. Here's how the problem went down and how he fixed it.
Even though I have been using Microsoft Azure for years, I have to admit that I really have never given DNS a second thought.
When you deploy an Azure virtual machine (VM), the VM is automatically provisioned with an IP address, and is also automatically configured to use an appropriate DNS server.
As I recently discovered, however, Azure contains a glitch whereby manually configuring a VM to use a specific DNS server causes the VM to fail. Let's take a look at what happens.
If you look at Figure 1, you can see that I have created an Azure VM and that I have successfully logged into the VM without any issues. It doesn't really make a difference, but in case you are wondering, the Azure VM that I am using for this article is running Windows Server 2016 Datacenter Edition.
Now take a look at Figure 2. The VM is configured by default to receive its IP address and DNS server configuration from a DHCP server. This is exactly the behavior that I would expect from a cloud VM. Both Microsoft and Amazon Web Services (AWS) automatically supply IP addresses and DNS server configuration information to the cloud VMs created through their services.
So to illustrate the glitch that I talked about earlier, I am going to change this VM's DNS server assignments. I seriously doubt that I would ever have a reason to do this in real life, but for the sake of demonstration, I am going to tell the VM to use my ISP's DNS servers rather than Microsoft's DNS servers.
If you look at Figure 3, you can see that even though I have manually specified the DNS servers that I want to use, I am still allowing Azure to automatically assign an IP address to the VM. In other words, the change that I am making should not impact the VM's IP address in any way.
So what happens when I make the change? Well, take a look at Figure 4. Several seconds after completing the configuration change, the VM drops the RDP session that I am using to interact with the VM.
The first time that this happened to me, I assumed that after a few seconds, the RDP client would be able to re-establish its session with the VM. After more than a dozen retries, however, it became very clear that the client was not going to reconnect.
The solution to this glitch is actually very simple. It's so simple, that some of you may wonder why I am even bothering to write an article about it. Here's the back story.
Last week, I was working on a project in which I needed to create a few Azure VMs, and have those VMs behave as if they resided on-premises. In other words, I needed DNS name resolution capabilities, and I needed to join the VMs to an on-premises Active Directory domain. Although I got the VPN setup working relatively quickly, the DNS problem that I just showed you ended up being a major hurdle. It took me the better part of a day to find a solution. My hope is that by sharing my solution here, I can save someone else from wasting time looking for a fix.
So how did I fix the problem? Well, during the course of my troubleshooting efforts, I read a TechNet article indicating that DNS changes to Azure VMs do not take effect until the VM is rebooted. I was pretty sure that a reboot would not fix my problem, because the loss of connectivity to the VM indicated that a configuration change had taken place. Even so, I rebooted the VM because I did not know what else to try, and the problem went away.
If you look at Figure 5 above, you can see that I have reconnected to the Azure VM, and that the VM is indeed using my manually assigned DNS servers.
About the Author
Brien Posey is a 21-time Microsoft MVP with decades of IT experience. As a freelance writer, Posey has written thousands of articles and contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. In addition to his continued work in IT, Posey has spent the last several years actively training as a commercial scientist-astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space. You can follow his spaceflight training on his Web site.