Why use Azure DNS Private Resolver?

A lot of people who've been operating in Azure for sometime will be familiar with the classic approach to hybrid DNS between on-premise AD and Azure, however for those who aren't, let me run through a typical scenario below.

Imagine you are a business who still have a couple of VMs, including Domain Controllers (DCs), still on-premise, but you've started to expand into Azure and set yourself up a Hub-Spoke Network. You have two DCs in the Hub Vnet and maybe some VMs in a spoke landing zone network.

Let's say you also have a storage account in that landing zone, which you want to secure access to using Private Endpoint. Great no problem, with the setup described below, you can access the storage account private endpoint from both on-premise VMs and Azure VMs.

From the previous diagram, it's important to highlight that:

• On-premises DNS servers have conditional forwarders configured for each private endpoint public DNS zone, pointing to the DNS servers 10.100.2.4 and 10.100.2.5 hosted in the hub VNet.
• The Azure VM DNS servers 10.100.2.4 and 10.100.2.5 hosted in the hub VNet use the Azure-provided DNS resolver (168.63.129.16) as a forwarder.
• The hub VNet must be linked to the Private DNS zone names for Azure services (such as privatelink.blob.core.windows.net, as shown in the diagram).
• All Azure VNets use the DNS servers hosted in the hub VNet (10.100.2.4 and 10.100.2.5) as the primary and secondary DNS servers.

So if that is all setup and working, and in most instances those VM DNS Forwarders in Azure are actually just your Azure domain controllers, why do we need Azure DNS Private resolver? What's the benefit? It won't reduce the VM count, as we still need those AD Servers, even if they are not used as DNS Forwarders.

The answer to why use DNS private resolver, we can summarise to the following key points:

1. Your workloads are Linux based. The above example scenario assumes you are using AD Servers in Azure to act as DNS Forwarders. If you are using a Linux based solution for DNS resolution, you can reduce VM footprint and reap all the benefits of moving from IaaS to PaaS (and the increased costs).
2. DevOps. If you've moved to managing your Azure environment with IaC, you can configure DNS Private Resolver and Azure DNS entirely programmatically. This also allows for much greater scalability if you have complex DNS requirements.
3. Conditional forwarding for Azure DNS to on-premises servers. The outbound endpoint provides this capability, which hasn't been available in the past. Workloads in Azure no longer require direct connections to on-premises DNS servers. Instead, the Azure workloads connect to the outbound IP address of DNS Private Resolver.

Point 3 highlights a unique ability of DNS Private Resolver compared to traditional methods, and we can see how that works below:

1. VM 1 queries a DNS record. The spoke virtual networks are configured to use the name resolution that Azure provides. As a result, Azure DNS is used to resolve the DNS query.
2. If the query attempts to resolve a private name, the Azure private DNS service is contacted.
3. If the query doesn't match a private DNS zone that's linked to the virtual network, Azure DNS connects to DNS Private Resolver. The Spoke 1 virtual network has a virtual network link. DNS Private Resolver checks for a DNS forwarding rule set that's associated with the Spoke 1 virtual network.
4. If a match is found in the DNS forwarding rule set, the DNS query is forwarded via the outbound endpoint to the IP address that's specified in the rule set.
5. If the Azure private DNS service (2) and DNS Private Resolver (3) can't find a matching record, Azure DNS (5) is used to resolve the query.

Each DNS forwarding rule specifies one or more target DNS servers to use for conditional forwarding. The specified information includes the domain name, target IP address, and port.

There is however some limitations, which are important to call out:

• DNS Private Resolver rule sets can only be linked to virtual networks that are within the same geographical region as the resolver.
• A virtual network can't contain more than one DNS private resolver.
• You need to assign a dedicated subnet to each inbound and outbound endpoint.

Summary

To summarise, DNS Private Resolver definitely has its use cases and for those looking for a highly scalable, redundant and managed solution, it ticks all the boxes. However, I did make a tongue in cheek comment on my first point, about the increased costs from moving to PaaS. Cost is a big factor when considering any service, and clocking in at approximately £280 a month retail DNS Private Resolver isn't cheap. Especially compared to, for example, three burstable VMs running a highly available DNS solution. Having said that, you don't have to worry about patching, backup, or any other kind of maintenance overhead which comes with VMs. Overall, I still think DNS Private Resolver represents a good value proposition if you fit into it's use cases.