Name Resolution (DNS)

Updated: December 4, 2014

Name resolution is used when you want to refer to VMs and role instances by hostname or FQDN directly, instead of by IP address and port number. Before deploying role instances or virtual machines, you must consider how you want name resolution to be handled. There are two options available. You can either use internal name resolution provided by Azure, or you can choose to specify a DNS server that is not maintained by Azure. Not all configuration options are available for every deployment type. Carefully consider your deployment scenario before making this choice.

Azure-provided name resolution provides hostname resolution for VMs and role instances that reside in the same cloud service. This service is separate from the service that handles externally facing publicly accessible names.

Although Azure-provided name resolution requires very little configuration, it is not the appropriate choice for all deployments. If your network requires name resolution across cloud services, you’ll need to use your own DNS server. For example, if you have two VMs located on the same virtual network, you will need to use your own DNS server solution in order for them to communicate directly by hostname. If you require cross-premises name resolution, or if you want to register additional DNS records of your own, you will need to use your own DNS solution and not the Azure-provided solution. For additional details, see the Features and Considerations.

Note

In the case of web and worker roles, you can also access the internal IP addresses of role instances based on the role name and instance number using the Azure runtime API. For more information, see the Azure runtime class library.

Ease of use: Little or no configuration is required in order to use the Azure-provided DNS service.

Hostname resolution is provided between role instances within the same cloud service.

Hostname resolution is provided between VMs within the same cloud service.

Name resolution is provided between VMs located on the same virtual network, but in different cloud services. (FQDN)

You can create the hostnames that will best describe your deployments, rather than working with auto-generated names.

Standard DNS lookups are supported.

Considerations:

Name resolution between virtual networks is not available.

Use of multiple hostnames for the same virtual machine or role instance is not supported.

Cross-premises name resolution is not available.

Reverse lookups (PTR) records are not available.

The Azure-created DNS suffix cannot be modified.

You cannot manually register your own records in Azure-provided DNS.

WINS and NetBIOS are not supported. (You cannot list your virtual machines in the network browser in Windows Explorer.)

Hostnames must be DNS-compatible (They must use only 0-9, a-z and ‘-‘, and cannot start or end with a ‘-‘. See RFC 3696 section 2.)

DNS query traffic is throttled per VM. If your application performs frequent DNS queries on multiple target names, it is possible that some queries may time out. A possible workaround is to reduce DNS query traffic from each VM and then retry the lookup.

If your name resolution requirements go beyond the features available from the Azure-provided DNS server, you have the option of using your own DNS server.

Note

You may choose to specify a DNS server that is provided by a third-party. An external solution may not support your VMs or role instances. In most cases, an external solution should be avoided except for specific situations where you only need name resolution of external DNS names.

It’s important to understand that DNS server lists do not work round-robin. DNS servers will be used in the order that they are specified. If the first DNS server on the list can be reached, the client will use that DNS server regardless of whether the DNS server is functioning properly or not. For this reason, verify that you have your DNS servers listed in the correct order for your environment.

If you used the Management Portal or a Network Configuration file to create your virtual network and you want to edit the DNS settings that you specified, after you make the changes to the virtual network, you must then restart each virtual machine. Restarting the virtual machine allows it to register the new DNS settings. If you don’t restart your virtual machines, they will continue to use the DNS server settings that were in effect before you made the changes.

The Management Portal can be used to configure DNS settings when you create a virtual network. When you create a virtual network by using the Management Portal, you are using the portal to create a Network Configuration file, although you do not see the file unless you export it. If you prefer to work with the Network Configuration file directly (not in the Management Portal), you may want to create your initial virtual network in the Management Portal and then export the file to use as a virtual network file template.

When you create your virtual network by using the Management Portal, you can specify the IP address and name of the DNS server (or servers) that you want to use. Once the virtual network has been created, the virtual machines and roles that you deploy to the virtual network are automatically configured with your specified DNS settings. For more information about configuring settings for Azure Virtual Network, see About Configuring a Virtual Network in the Management Portal.

You can specify DNS servers by using configuration files when you create a virtual network, or when you deploy roles. There are two different files in which you can specify a DNS server: the Network Configuration file and the Service Configuration file. Select the appropriate configuration file based on your name resolution needs.

For example, to create and configure a virtual network, you will probably want to use the Network Configuration file. When you specify DNS settings in the Network Configuration file, any roles or virtual machines that you then deploy to the virtual network will automatically be configured with those DNS settings.

If you do not plan to use a virtual network, or are using a virtual network and want to specify different DNS settings for a particular cloud service within that network, you would specify those settings in the Service Configuration file. Settings in the Service Configuration file take precedence over settings in the Network Configuration file.

In order to specify this setting for the Virtual Network Sites element, it must be first defined in the DNS element of the Network Configuration file. The DnsServerRef name in the Virtual Network Sites element must refer to a name value specified in the DNS element for DnsServer name.

If you do not plan to use a virtual network, or are using a virtual network and want to specify different DNS settings for a particular cloud service within the virtual network, you would specify those settings in the Service Configuration file. Settings in the Service Configuration file take precedence over settings in the Network Configuration file. You can also use the Service Configuration file to modify DNS server settings for web and worker roles.