How to: Resolve slow Logging in issues and Sudo rights use when using your own DNS in Windows Azure

How to: Resolve slow Logging in issues and Sudo rights use when using your own DNS in Windows Azure

Another issue I encountered while using a Linux VM inside Windows Azure is that the logging in process was extremely slow and then you tried to run a command with elevated rights, it was slow too. It turns out after some digging that the problem is the computer is having problems talking to itself (ironic right?). Recently I wrote an article about How to: Enable proper domain DNS search in Ubuntu when using Windows Azure. In it I talk about things like the appended DNS suffix that is used for DNS searches. Long story short: if you are running an Ubuntu VM in Windows Azure it is going to be assigned a DNS search suffix of: ComputerName.b#.internal.cloudapp.net. IF you are using the default DNS that is provided by Windows Azure then no problem, said search will in fact return the correct IP for the computer and it will be able to connect to itself. If you happen to use your own domain name and DNS server as part of your Virtual Network then you are in need of some tweaks or you’ll experience slow responses whenever you need to authenticate.

Why would you want to use your own DNS then? Well, suppose you have a Virtual Private Network in Windows Azure and then you have VMs that are part of Cloud Services inside that Virtual Network. Windows Azure DNS resolution works great for VMs that are all inside a Cloud Service but fails to address resolution for VMs inside the same Virtual Network but that are part of other Cloud Service. You could for instance, on a running VM obtain the DNS suffix for it and ping the FQDN. The risk with this approach is that if your VM is shut down then when it is turned back on it will obtain a new internal & external IP address and a new DNS suffix (the new one might be the same as the old one, depends on the availability and rules for selection. External IP addresses is very low probability as it does a round robin through all the IPs that are not taken. Internal IP addresses is higher probability as it based on the VMs you have turned on. DNS suffix it all depends. Windows Azure maintains the DNS suffix for a Cloud Service, same for an External IP address. If you keep at least one computer on in a Cloud Service both your External IP address and DNS suffix will remain the same. If you completely turn off all VMs inside a Cloud Service then Windows Azure will assign new External IP and DNS suffix to the service and all VMs inside of it, present and future, until they are all turned off again. <– Pretty complex for a new cloud user right?)

So there you have it: If you are using a Virtual Network with several Cloud Services and you want Name Resolution between those services you need your own DNS. If you have your own DNS then you need to configure your VM to resolve its name and others with the right Virtual Network suffix of your DNS server (again, see How to: Enable proper domain DNS search in Ubuntu when using Windows Azure).

To configure the resolution of your own machine do the following:

1. You’ll need to edit the /etc/hosts file
2. Modify the line with your localhost in the following format:
   • from:
     • 127.0.0.1 localhost
   • to:
     • 127.0.0.1 MyComputerName.FQDN MyComputerName localhost
   • So it should look in the end like so:
     • 127.0.0.1 wordpress.azurenetwork.cloudingenium.com wordpress localhost
3. Save changes and you’re done!

What we are doing with this approach is first defining your local computer FQDN hostname, then an alias for your short name and finally an alias for localhost. Please bare in mind that you need to set up your /etc/hostname file to your hostname (not your FQDN hostname) which comes like that by default when you provision a VM in Windows Azure. Good luck!