Azure Architecture: DNS Management on Azure – Day 3

Introduction

Here comes into the 3rd article for this topic. In the last article, we discussed about the simplest design for handling the DNS query from Azure workload, which is sending the query to the DNS servers in on-prem. However, this may not be the best approach for cloud adoption. In today’s article, we will introduce another approach, using Azure private DNS resolver.

Azure Private DNS resolver

Before we drill into the design, lets first introduce the Azure Private DNS Resolver.

In day 1, we mentioned about the private DNS zone on Azure, which storing some record from Azure service, for example, private link or private endpoint. By default, those DNS zone must query from Azure default DNS (168.63.129.16), they cannot be query by any internal DNS server directly, hence some hybrid environment will face a problem – those DNS record have no way to resolve by on-premises workload.

Azure Private DNS resolver act as a DNS service on Azure, which allowing the on-premises DNS server forward the DNS query for those private DNS zone. As this is SaaS, we do not needed to create any VM based DNS server on Azure. In addition, it is not only receiving the DNS query for the private DNS zone, it allow us to setup the forwarding rule to any DNS server when the connectivity is enabled. Therefore, Azure Private DNS Resolver can be a transitional DNS server replacement.

To learn more about the private DNS resolver, you can read this article.

Assumption

Lets assume we have an Azure environment contain below component:

1. Hybrid networking (IPSec VPN or ExpressRoute) between Azure and on-premises have been formed
2. There are DNS servers (or Active Directory environment) in on-premises environment
3. Private DNS record in on-premises needed to be handled
4. Private DNS zone is in used

With Azure Private DNS resolver

In the above figure, we separated the environment in hub and spoke, which enabling the flexibility on setting up the entire environment. In the hub virtual network, we created 2 subnets for the private DNS resolver:

1. Inbound endpoint subnet
   The inbound endpoint here means the inbound IP address for the private DNS resolver. This subnet is used to contain the private IP address for the DNS resolver, which will receive the DNS queries traffic from spoke network or on-premises.
   
2. Outbound endpoint subnet
   As mentioned in the previous part, Azure private DNS resolver control not only the DNS query from other network, it can also control the traffic to on-premises or any other connected network.
   When there are any domain which is not placed in public DNS or private DNS zone, such as on-premises domain, in traditional DNS server setup, we will create a conditional forward for forwarding the queries to the DNS server that contain the record. In Azure private DNS resolver, it also provide the feature to forward the traffic to other DNS servers once we setup the conditional forward rule.
   The outbound endpoint here means the private IP we will used to communicate with the DNS server we are willing to forward the traffic to.

In simplest design with Azure private DNS resolver, the spoke network can replace the DNS server IP with the inbound endpoint of the resolver, now all the DNS queries will be sent to the resolver. In the resolver network, keep the default DNS server as the Azure DNS server, then the request will be forwarded to the Azure DNS. With virtual network link, the private DNS integrated with the virtual network, now the Azure DNS will be able to resolve the public DNS also the record in private DNS zone.

For the DNS query from on-premises, to resolve the DNS record in private DNS zone, they just needed to setup some conditional forwarder to forward the DNS query to the private DNS resolver inbound IP on Azure, then the private DNS resolver will send the query to Azure DNS and hence return the result to the on-premises DNS server and workload.

Similarly, if there are any request for resolving on-premises DNS record, the only thing to add on the resolver is setup the conditional forwarder ruleset, to define the specific domain and forward the DNS query to on-premises DNS server.

Advantage

The advantage of the approach with using the private DNS resolver on Azure is obvious, that is, it enabled the DNS solution between Azure and on-premises, even if your business is running in multi-cloud mode, the private DNS resolver can let the workload out of Azure can resolve the record in private DNS zone with simple setup.

To fulfill the goal of cloud adoption, one of the principle is to use cloud native service as much as we can. Azure private DNS resolver is a cloud native SaaS, which Microsoft helped to managed the infrastructure at the backend, no backup we needed to take care, then we can focus only on he configuration and use less time on the setup process.

Compared with the approach we discussed in the last article, the private DNS resolver reduce the loading of the hybrid network tunnel, now only the on-premises domain query will be send to the on-premises DNS server, all the public domain query and Azure private DNS zone record will be handle by the Azure DNS, the structure become more cloud native.

Disadvantage

From the architecture point of view, Azure private DNS resolver is a great option to enable the DNS solution on cloud environment. However, as a powerful product to handle the DNS solution, the cost of the resolver reasonable but absolutely more expensive when we are using the on-premises DNS server. We can check the price form here.

If we have not much usage and requirement on cloud, this may be overprice to use the product in a small environment.

Summary

To conclude, the approach to use private DNS resolver is one of the option which fit the cloud adoption principle, efficient and easy to use. It will suitable for the business or environment that have large usage on private DNS zone, there are more workload on Azure required the resolution of on-premises environment.

In the next article, we will discuss another option to extend the AD domain controller to Azure as an DNS server, which is a scenario that most business will face today.