Resolve Azure and on-premises domains

• 
  

Hybrid DNS resolution

This article provides guidance on how to configure hybrid DNS resolution by using an Azure DNS Private Resolver with a DNS forwarding ruleset. In this scenario, your Azure DNS resources are connected to an on-premises network using a VPN or ExpressRoute connection.

Hybrid DNS resolution is defined here as enabling Azure resources to resolve your on-premises domains, and on-premises DNS to resolve your Azure private DNS zones.

Azure DNS Private Resolver

The Azure DNS Private Resolver is a service that can resolve on-premises DNS queries for Azure DNS private zones. Previously, it was necessary to deploy a VM-based custom DNS resolver, or use non-Microsoft DNS, DHCP, and IPAM (DDI) solutions to perform this function.

Benefits of using the Azure DNS Private Resolver service vs. VM-based resolvers or DDI solutions include:

• Zero maintenance: Unlike VM or hardware based solutions, the private resolver doesn't require software updates, vulnerability scans, or security patching. The private resolver service is fully managed.
• Cost reduction: Azure DNS Private Resolver is a multitenant service and can cost a fraction of the expense that is required to use and license multiple VM-based DNS resolvers.
• High availability: The Azure DNS Private Resolver service has built-in high availability features. The service is availability zone aware, thus ensuring that high availability and redundancy of your DNS solution can be accomplished with much less effort. For more information on how to configure DNS failover using the private resolver service, see Tutorial: Set up DNS failover using private resolvers.
• DevOps friendly: Traditional DNS solutions are hard to integrate with DevOps workflows as these often require manual configuration for every DNS change. Azure DNS private resolver provides a fully functional ARM interface that can be easily integrated with DevOps workflows.

DNS forwarding ruleset

A DNS forwarding ruleset is a group of rules that specify one or more custom DNS servers to answer queries for specific DNS namespaces. For more information, see Azure DNS Private Resolver endpoints and rulesets.

Procedures

The following procedures in this article are used to enable and test hybrid DNS:

• Create an Azure DNS private zone
• Create an Azure DNS Private Resolver
• Configure an Azure DNS forwarding ruleset
• Configure on-premises DNS conditional forwarders
• Demonstrate hybrid DNS

Create an Azure DNS private zone

Create a private zone with at least one resource record to use for testing. The following quickstarts are available to help you create a private zone:

• Create a private zone - portal
• Create a private zone - PowerShell
• Create a private zone - CLI

In this article, the private zone azure.contoso.com and the resource record test are used. Autoregistration isn't required for the current demonstration.

 Important

A recursive server is used to forward queries from on-premises to Azure in this example. If the server is authoritative for the parent zone (contoso.com), forwarding is not possible unless you first create a delegation for azure.contoso.com.

Requirement: You must create a virtual network link in the zone to the virtual network where you deploy your Azure DNS Private Resolver. In the following example, the private zone is linked to two VNets: myeastvnet and mywestvnet. At least one link is required.

Create an Azure DNS Private Resolver

The following quickstarts are available to help you create a private resolver. These quickstarts walk you through creating a resource group, a virtual network, and Azure DNS Private Resolver. The steps to configure an inbound endpoint, outbound endpoint, and DNS forwarding ruleset are provided:

• Create a private resolver - portal
• Create a private resolver - PowerShell

When you're finished, write down the IP address of the inbound endpoint for the Azure DNS Private Resolver. In this example, the IP address is 10.10.0.4. This IP address is used later to configure on-premises DNS conditional forwarders.

Configure an Azure DNS forwarding ruleset

Create a forwarding ruleset in the same region as your private resolver. The following example shows two rulesets. The East US region ruleset is used for the hybrid DNS demonstration.

Requirement: You must create a virtual network link to the vnet where your private resolver is deployed. In the following example, two virtual network links are present. The link myeastvnet-link is created to a hub vnet where the private resolver is provisioned. There's also a virtual network link myeastspoke-link that provides hybrid DNS resolution in a spoke vnet that doesn't have its own private resolver. The spoke network is able to use the private resolver because it peers with the hub network. The spoke vnet link isn't required for the current demonstration.

Next, create a rule in your ruleset for your on-premises domain. In this example, we use contoso.com. Set the destination IP address for your rule to be the IP address of your on-premises DNS server. In this example, the on-premises DNS server is at 10.100.0.2. Verify that the rule is Enabled.

 Note

Don't change the DNS settings for your virtual network to use the inbound endpoint IP address. Leave the default DNS settings.

Configure on-premises DNS conditional forwarders

The procedure to configure on-premises DNS depends on the type of DNS server you're using. In the following example, a Windows DNS server at 10.100.0.2 is configured with a conditional forwarder for the private DNS zone azure.contoso.com. The conditional forwarder is set to forward queries to 10.10.0.4, which is the inbound endpoint IP address for your Azure DNS Private Resolver. There's another IP address also configured here to enable DNS failover. For more information about enabling failover, see Tutorial: Set up DNS failover using private resolvers. For the purposes of this demonstration, only the 10.10.0.4 inbound endpoint is required.

Demonstrate hybrid DNS

Using a VM located in the virtual network where the Azure DNS Private Resolver is provisioned, issue a DNS query for a resource record in your on-premises domain. In this example, a query is performed for the record testdns.contoso.com:

The path for the query is: Azure DNS > inbound endpoint > outbound endpoint > ruleset rule for contoso.com > on-premises DNS (10.100.0.2). The DNS server at 10.100.0.2 is an on-premises DNS resolver, but it could also be an authoritative DNS server.

Using an on-premises VM or device, issue a DNS query for a resource record in your Azure private DNS zone. In this example, a query is performed for the record test.azure.contoso.com:

The path for this query is: client's default DNS resolver (10.100.0.2) > on-premises conditional forwarder rule for azure.contoso.com > inbound endpoint (10.10.0.4)

 

Azure DNS Private Resolver endpoints and rulesets

• 
  

In this  you learn about components of the Azure DNS Private Resolver. Inbound endpoints, outbound endpoints, and DNS forwarding rulesets are discussed. Properties and settings of these components are described, and examples are provided for how to use them.

The architecture for Azure DNS Private Resolver is summarized in the following figure. In this example network, a DNS resolver is deployed in a hub VNet that peers with a spoke VNet.

Figure 1: Example hub and spoke network with DNS resolver

• Ruleset links are provisioned in the DNS forwarding ruleset to both the hub and spoke VNets, enabling resources in both VNets to resolve custom DNS namespaces using DNS forwarding rules.
• A private DNS zone is also deployed and linked to the hub VNet, enabling resources in the hub VNet to resolve records in the zone.
• The spoke VNet resolves records in the private zone by using a DNS forwarding rule that forwards private zone queries to the inbound endpoint VIP in the hub VNet.
• An ExpressRoute-connected on-premises network is also shown in the figure, with DNS servers configured to forward queries for the Azure private zone to the inbound endpoint VIP. For more information about enabling hybrid DNS resolution using the Azure DNS Private Resolver, see Resolve Azure and on-premises domains.

 

Inbound endpoints

As the name suggests, inbound endpoints ingress to Azure. Inbound endpoints provide an IP address to forward DNS queries from on-premises and other locations outside your virtual network. DNS queries sent to the inbound endpoint are resolved using Azure DNS. Private DNS zones that are linked to the virtual network where the inbound endpoint is provisioned are resolved by the inbound endpoint.

The IP address associated with an inbound endpoint is always part of the private virtual network address space where the private resolver is deployed. No other resources can exist in the same subnet with the inbound endpoint.

Static and dynamic endpoint IP addresses

The IP address assigned to an inbound endpoint can be static or dynamic. If you select static, you can't choose a reserved IP address in the subnet. If you choose a dynamic IP address, the fifth available IP address in the subnet is assigned. For example, 10.10.0.4 is the fifth IP address in the 10.10.0.0/28 subnet (.0, .1, .2, .3, .4). If the inbound endpoint is reprovisioned, this IP address could change, but normally the 5th IP address in the subnet is used again. The dynamic IP address does not change unless the inbound endpoint is reprovisioned. The following example specifies a static IP address:

The following example shows provisioning of an inbound endpoint with a virtual IP address (VIP) of 10.10.0.4 inside the subnet snet-E-inbound within a virtual network with address space of 10.10.0.0/16.

Outbound endpoints

Outbound endpoints egress from Azure and can be linked to DNS Forwarding Rulesets.

Outbound endpoints are also part of the private virtual network address space where the private resolver is deployed. An outbound endpoint is associated with a subnet, but isn't provisioned with an IP address like the inbound endpoint. No other resources can exist in the same subnet with the outbound endpoint. The following screenshot shows an outbound endpoint inside the subnet snet-E-outbound.

DNS forwarding rulesets

DNS forwarding rulesets enable you to specify one or more custom DNS servers to answer queries for specific DNS namespaces. The individual rules in a ruleset determine how these DNS names are resolved. Rulesets can also be linked one or more virtual networks, enabling resources in the VNets to use the forwarding rules that you configure.

Rulesets have the following associations:

• A single ruleset can be associated with up to 2 outbound endpoints belonging to the same DNS Private Resolver instance. It can't be associated with 2 outbound endpoints in two different DNS Private Resolver instances.
• A ruleset can have up to 1000 DNS forwarding rules.
• A ruleset can be linked to up to 500 virtual networks in the same region.

A ruleset can't be linked to a virtual network in another region. For more information about ruleset and other private resolver limits, see What are the usage limits for Azure DNS?.

Ruleset links

When you link a ruleset to a virtual network, resources within that virtual network use the DNS forwarding rules enabled in the ruleset. The linked virtual networks aren't required to peer with the virtual network where the outbound endpoint exists, but these networks can be configured as peers. This configuration is common in a hub and spoke design. In this hub and spoke scenario, the spoke vnet doesn't need to be linked to the private DNS zone in order to resolve resource records in the zone. In this case, the forwarding ruleset rule for the private zone sends queries to the hub vnet's inbound endpoint. For example: azure.contoso.com to 10.10.0.4.

The following screenshot shows a DNS forwarding ruleset linked to the spoke virtual network: myeastspoke.

Virtual network links for DNS forwarding rulesets enable resources in other VNets to use forwarding rules when resolving DNS names. The VNet with the private resolver must also be linked from any private DNS zones for which there are ruleset rules.

For example, resources in the vnet myeastspoke can resolve records in the private DNS zone azure.contoso.com if:

• The ruleset provisioned in myeastvnet is linked to myeastspoke
• A ruleset rule is configured and enabled in the linked ruleset to resolve azure.contoso.com using the inbound endpoint in myeastvnet

Rules

DNS forwarding rules (ruleset rules) have the following properties:

Property	Description
Rule name	The name of your rule. The name must begin with a letter, and can contain only letters, numbers, underscores, and dashes.
Domain name	The dot-terminated DNS namespace where your rule applies. The namespace must have either zero labels (for wildcard) or between 1 and 34 labels. For example, contoso.com. has two labels.1
Destination IP:Port	The forwarding destination. One or more IP addresses and ports of DNS servers that are used to resolve DNS queries in the specified namespace.
Rule state	The rule state: Enabled or disabled. If a rule is disabled, it's ignored.

1Single-label domain names are supported.

If multiple rules are matched, the longest prefix match is used.

For example, if you have the following rules:

Rule name	Domain name	Destination IP:Port	Rule state
Contoso	contoso.com.	10.100.0.2:53	Enabled
AzurePrivate	azure.contoso.com.	10.10.0.4:53	Enabled
Wildcard	.	10.100.0.2:53	Enabled

A query for secure.store.azure.contoso.com matches the AzurePrivate rule for azure.contoso.com and also the Contoso rule for contoso.com, but the AzurePrivate rule takes precedence because the prefix azure.contoso is longer than contoso.

 Important

If a rule is present in the ruleset that has as its destination a private resolver inbound endpoint, do not link the ruleset to the VNet where the inbound endpoint is provisioned. This configuration can cause DNS resolution loops. For example: In the previous scenario, no ruleset link should be added to myeastvnet because the inbound endpoint at 10.10.0.4 is provisioned in myeastvnet and a rule is present that resolves azure.contoso.com using the inbound endpoint.

The rules shown in this article are examples of rules that you can use for specific scenarios. The examples used aren't required. Be careful to test your forwarding rules.

If you include a wildcard rule in your ruleset, ensure that the target DNS service can resolve public DNS names. Some Azure services have dependencies on public name resolution.

Rule processing

• If multiple DNS servers are entered as the destination for a rule, the first IP address that is entered is used unless it doesn't respond. An exponential backoff algorithm is used to determine whether or not a destination IP address is responsive.
• Certain domains are ignored when using a wildcard rule for DNS resolution, because they're reserved for Azure services. See Azure services DNS zone configuration for a list of domains that are reserved. The two-label DNS names listed in this article (for example: windows.net, azure.com, azure.net, windowsazure.us) are reserved for Azure services.

 Important

• You can't enter the Azure DNS IP address of 168.63.129.16 as the destination IP address for a rule. Attempting to add this IP address outputs the error: Exception while making add request for rule.
• Do not use the private resolver's inbound endpoint IP address as a forwarding destination for zones that aren't linked to the virtual network where the private resolver is provisioned.

Design options

How you deploy forwarding rulesets and inbound endpoints in a hub and spoke architecture ideally depends on your network design. Two configuration options are discussed briefly in the following sections. For a more detailed discussion with configuration examples, see Private resolver architecture.

Forwarding ruleset links

Linking a forwarding ruleset to a VNet enables DNS forwarding capabilities in that VNet. For example, if a ruleset contains a rule to forward queries to a private resolver's inbound endpoint, this type of rule can be used to enable resolution of private zones that are linked to the inbound endpoint's VNet. This configuration can be used where a Hub VNet is linked to a private zone and you want to enable the private zone to be resolved in spoke VNets that aren't linked to the private zone. In this scenario, DNS resolution of the private zone is carried out by the inbound endpoint in the hub VNet.

The ruleset link design scenario is best suited to a distributed DNS architecture where network traffic is spread across your Azure network, and might be unique in some locations. With this design, you can control DNS resolution in all VNets linked to the ruleset by modifying a single ruleset.