Solution for Name Resolution and Network addressing
In this tutorial we will learn about Azure name resolution and its various areas including the detailed information about IP addressing.
For using Azure to host IaaS, PaaS, and hybrid solutions, you may require to allow the virtual machines (VMs) for deploying in a virtual network to communicate with each other. However, when resources deployed in virtual networks require to resolve domain names to internal IP addresses, they can use methods like:
- Azure DNS private zones
- Azure-provided name resolution
- Name resolution that uses your own DNS server
Azure-provided name resolution
Azure provided name resolution covers only basic authoritative DNS capabilities. However, with this option the DNS zone names and records will be automatically managed by Azure. And, if you need a fully featured DNS solution for your virtual networks then you must use Azure DNS private zones or Customer-managed DNS servers.
Azure also provides internal name resolution for VMs and role instances that reside within the same virtual network or cloud service. However, VMs and instances in a cloud service share the same DNS suffix, so the host name alone is sufficient. In this situation, you require the FQDN for resolving names between different cloud services.
Features
Azure-provided name resolution includes the following features:
- Firstly, there is need of configuration
- Secondly, there is no requirement for creating and managing clusters of your own DNS servers.
- Thirdly, you can use the service in conjunction with your own DNS servers for resolving both on-premises and Azure host names.
- Moreover, you can use name resolution between VMs and role instances within the same cloud service, without the need for an FQDN.
- Lastly, you can use name resolution between VMs in virtual networks that use the Azure Resource Manager deployment model, without need for an FQDN.
Name resolution that uses your own DNS server
In this we will understand VMs, role instances, and web apps.
VMs and role instances
Your name resolution requirement can go beyond the features provided by Azure. That is to say, you may require Microsoft Windows Server Active Directory domains, resolve DNS names between virtual networks. However, for this, Azure provides the ability for you to use your own DNS servers.
DNS servers within a virtual network have the ability to forward DNS queries to the recursive resolvers in Azure. And, this enables you to resolve hostnames within that virtual network. Moreover, DNS forwarding also enables DNS resolution between virtual networks and allows your on-premises machines for resolving Azure-provided hostnames. For resolving a VM’s hostname, the DNS server VM must reside in the same virtual network, and be configured to forward hostname queries to Azure. The image below shows two virtual networks and an on-premises network doing DNS resolution between virtual networks, by using this method.
While using Azure-provided name resolution, Azure Dynamic Host Configuration Protocol (DHCP) provides an internal DNS suffix to each VM. And, when you are using your own name resolution solution, this suffix will not move to VMs because it interferes with other DNS architectures.
However, if necessary, you can determine the internal DNS suffix by using PowerShell or the API:
- Firstly, for virtual networks in Azure Resource Manager deployment models, the suffix is available via the network interface REST API, the Get-AzNetworkInterface PowerShell cmdlet, and the az network nic show Azure CLI command.
- Secondly, in classic deployment models, the suffix is available via the Get Deployment API call or the Get-AzureVM -Debug cmdlet.
Web apps
Assume you need to perform name resolution from your web app built by using App Service, linked to a virtual network, to VMs in the same virtual network. For setting up a custom DNS server that has a DNS forwarder that forwards queries to Azure perform the following steps:
- Firstly, enable virtual network integration for your web app.
- Secondly, in the Azure portal, for the App Service plan hosting the web app, select Sync Network under Networking, Virtual Network Integration.
However, if you need to perform name resolution from your web app built by using App Service, linked to a virtual network, to VMs in a different virtual network. Then, you have to use custom DNS servers on both virtual networks, as follows:
- Firstly, set up a DNS server in your target virtual network, on a VM that can also forward queries to the recursive resolver in Azure.
- Secondly, set up a DNS forwarder in the source virtual network on a VM. Then, configure this DNS forwarder to forward queries to the DNS server in your target virtual network.
- After that, configure your source DNS server in your source virtual network’s settings.
- Then, enable virtual network integration for your web app to link to the source virtual network.
- Lastly, in the Azure portal, for the App Service plan hosting the web app, select Sync Network under Networking, Virtual Network Integration.
Public IP addresses
Public IP addresses give access to Internet resources for communicating from inbound to Azure resources. They also enable Azure resources to communicate to Internet and public-facing Azure services. However, a resource without a public IP assigned can communicate outbound. Some of the resources for a public IP address:
- Virtual machine network interfaces
- Internet-facing load balancers
- VPN gateways
- Application gateways
- Azure Firewall
SKU
Public IP addresses are developed with one of the following SKUs:
Standard
Standard SKU public IP addresses:
- Firstly, it always uses a static allocation method.
- Secondly, it is secure by default and close to inbound traffic.
- Thirdly, it is assigned to network interfaces, standard public load balancers, or Application Gateways.
- Lastly, it can be zone-redundant or zonal.
Basic
All public IP addresses developed before introducing SKUs are Basic SKU public IP addresses.
Basic SKU addresses:
- Firstly, they are assigned with the static or dynamic allocation method.
- Secondly, they have adjustable inbound originated flow idle timeout of 4-30 minutes, with a default of 4 minutes.
- Thirdly, they are assigned to an Azure resource that can be a public IP address like Network interfaces, VPN Gateways, Application Gateways, and Public load balancers.
- Lastly, they don’t support Availability Zone scenarios.
Allocation method
Basic and standard both public IPs support static assignment. However, the IP address is launch when the resource is deleted. Basic SKU public IP addresses support a dynamic assignment where Dynamic is the default assignment method. However, the IP is assigned when you associate the public IP address resource with a:
- Virtual machine
- The first virtual machine is in association with the backend pool of a load balancer.
And, the IP address is released when the allocation method is changed from static to dynamic. For ensuring the IP address for the associated resource remains the same, set the allocation method explicitly to static. However, Static public IP addresses work in the following scenarios such as:
- Firstly, when you must update firewall rules to communicate with your Azure resources.
- Secondly, DNS name resolution, where a change in IP address would require updating A records.
- Thirdly, when your Azure resources communicate with other apps or services that use an IP address-based security model.
- Lastly, when you use TLS/SSL certificates linked to an IP address.
Reference: Microsoft Documentation, Documentation 2