Skip navigation
Pointing to the Cloud

A number of FAQs dealing with advanced networking with Azure IaaS VMs

John Savill's Frequently Asked Questions

Three times a week (Monday/Wednesday/Friday), John Savill tackles your most pressing IT questions. Read through the FAQ archives, or send him your questions via email.

Q. How can I configure a specific vmNIC on an Azure VM to use Azure DNS?

Q. If I deploy my own DNS services in Azure is there a way to forward recursive requests to Azure DNS for resolution?

Q. I've configured my Azure VM to use Azure DNS at the NIC level using IP address however the hostname record resolution fails which does not occur when setting at the virtual network level to Azure provided name resolution. Why?

-------------------

Q. How can I configure a specific vmNIC on an Azure VM to use Azure DNS?

Dept - Azure

A. Typically the DNS configuration for VMs is configured at the virtual network which can be either:

  • Azure DNS
  • Custom DNS (such as on-premises or any other DNS servers based on a set of IP addresses)

It is also possible to override the DNS configuration on a vmNIC level but specifying a different set of IP addresses however how can you configure it to use Azure DNS? Simply set to 168.63.129.16. This is the same IP address you can configure for your own DNS services in Azure to forward requests to Azure DNS per document https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-name-resolution-for-vms-and-role-instances.

Q. If I deploy my own DNS services in Azure is there a way to forward recursive requests to Azure DNS for resolution?

Dept - Azure

A. Typically a DNS server is authoritative for specific domains, i.e. the ones it hosts. For any other DNS queries it does a recursive query to resolve the requested name to an IP address. Another option is to configure forwarding of any request for a zone it is not authoritative for to another set of DNS servers who perform the recursive lookup and may have a larger cache of resolutions.

If you want to forward requests to Azure DNS set the forwarder for your DNS server to 168.63.129.16 per document https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-name-resolution-for-vms-and-role-instances. This also enables the resolution of Azure-provided hostnames.

Q. I've configured my Azure VM to use Azure DNS at the NIC level using IP address however the hostname record resolution fails which does not occur when setting at the virtual network level to Azure provided name resolution. Why?

Dept - Azure

A. At the virtual network level in Azure you can configure the Azure-provided name resolution DNS (IDNS) service to be used or a custom list of IP addresses can be configured. This configuration is applied to VMs in the virtual network via DHCP. Additionally DNS configuration can be set at a vmNIC level which allows a list of IP addresses to be set which is considered custom DNS even if you specify 168.63.129.16 which directs the requests to the IDNS (this is an important point).

Dynamic DNS is a technology which allows OS instances to register hostname (A) records to map their hostname to their IP address or through DHCP configuration the DHCP server can register on behalf of the client which is required for operating systems such as Linux. In the case of Azure, the Azure fabric ALWAYS registers a host record in the internal DNS for OS instances (even if using custom DNS). The records are created in an internal zone of the format < VNet encoded ID>..internal.cloudapp.net. This cannot be changed. The Azure fabric receives the OS hostname as part of the DHCP discover sent by the client during startup.

When the configuration to the vmNIC DNS is from the virtual network and is set to use the IDNS (default Azure DNS services), the client is sent the IP address of the internal DNS servers, 168.63.129.16 and a default DNS suffix of the internal zone, e.g. kwagipstuffqxwwc.bx.internal.cloudapp.net. This part is important as it allows the client OS to then query DNS as it has the correct suffix for the zone where the records are registered. When a client looks for webapp1 the OS actually adds the default suffix and queries DNS so the lookup is actually webapp1.kwagipstuffqxwwc.bx.internal.cloudapp.net. This means name resolution works for records within the virtual network.

When the configuration to the vmNIC DNS is set at the vmNIC level it is considered custom DNS even when its set to 168.63.129.16 (IDNS) and so the client is sent the IP of the DNS server but NOT the DNS suffix of the internal zone. As mentioned earlier the host record is still registered by the Azure fabric to the virtual networks associated internal zone however the guest OS does not know what that zone is and so when it queries DNS it will not get results as its not querying the correct FQDN (hostname plus the DNS suffix). This is why you see a difference in the behavior.

The solution is to configure the guest OS with the default suffix configuration of the virtual network. You can find this suffix by opening https://resources.azure.com and navigating to a NIC connected to the virtual network that is running. It will show you the internalDomainNameSuffix. Take a note of this value.

You now need to either manually configure the DNS suffix inside the guest OS or configure it as part of the VM provisioning using a custom script extension. An example of this approach can be found at https://github.com/Azure/azure-quickstart-templates/tree/master/custom-private-dns. Note this example creates a whole environment. The key part is in the nested folder that walks through actually configuring the suffix. For example the commands to execute on Linux would be (from https://github.com/Azure/azure-quickstart-templates/blob/master/custom-private-dns/nested/linux-client/setuplinuxclient.sh)

sudo echo "supersede domain-name \"kwagipstuffqxwwc.bx.internal.cloudapp.net\";" >> /etc/dhcp/dhclient.conf
sudo dhclient -v

For Windows see https://github.com/Azure/azure-quickstart-templates/blob/master/custom-private-dns/nested/windows-client/setupwinclient.ps1.

With this in place the VM now knows the correct suffix and will be able to resolve records.

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish