Azure Private DNS

Overview

DNS, DNS, DNS, It's all about DNS. I've circled around this topic for a while, and it's been a common discussion point with many of the clients I have worked with.

DNS is absolutely critical in any environment and if not done correctly it can cause a heap of issues. I am going to talk through some of the options for resolving DNS specifically for private endpoints in Azure and more importantly what Microsoft recommends and, in my opinion, works well.

Private Endpoints

Firstly, let's start with private endpoints. What are they? A private endpoint in Azure is simply a network interface card (NIC) with a private IP address in your virtual network that you can attach to common Azure PaaS services like Azure Storage or Azure SQL that allows you to communicate with that service privately and securely over an internal RFC1918 IP address. Prior to private endpoints these services typically used a service endpoint where in order to connect, your traffic traversed the Microsoft backbone network instead of your virtual network which of course many customers deemed not secure as your traffic is leaving your private network. Service endpoints are still available today. They are by no means unsecure but don't meet the security controls in some heavily regulated environments.

Azure Private DNS

Azure Private DNS is simply a DNS service in Azure that cannot be resolved publicly. It allows you to use your own custom DNS names rather than the DNS names provided by Azure which are public. Azure Private DNS is the fundamental building block of Private Endpoints. Private Endpoints heavily rely on a private DNS zone to resolve a DNS name against the private IP address of the Network Interface Card (NIC) I mentioned previously. For example, if you want to resolve a private endpoint for Azure blob storage then you would create a zone named privatelink.blob.core.windows.net. In order to resolve DNS, the zone must be linked to a virtual network where the originating DNS request is coming from.

Azure Private DNS Resolution Options

Getting into the meat here. There are several options to resolve private DNS in Azure and from on-premises. I will list the most common:

On-Premises to Azure

• DNS Virtual Machine in Azure with a forwarder configured on the on-premises DNS Server (sends all DNS to Azure)
• DNS Virtual Machine in Azure with a conditional forwarder configured on the on-premises DNS Server (sends only specific zones to Azure)
• Azure DNS Private Resolver (DNS Forwarder PaaS Service)

Azure Only & Hybrid Workloads

• Azure Private DNS Zone hosted in your hub virtual network and linked to any spoke virtual networks (Recommended for Azure only workloads)
• Azure Private DNS Zone hosted in your spoke network and linked to your spoke virtual network (Not Recommended)
• Azure DNS Private Resolver Centralised (Recommended for Hybrid Workloads)
• Azure DNS Private Resolver Distributed (Recommended for Hybrid Workloads)

A common approach I see which is not recommended is where a DNS zone is deployed for each spoke or application landing zone deployment which means you might end up with tens or hundreds of zones just for one service for example privatelink.blob.core.windows.net. This is hard to manage and not necessary. You want to manage your DNS centrally similar to managing a hub firewall. You wouldn't deploy an NVA for each spoke network so why do it for DNS.

Azure DNS Private Resolver

Before I dive into the architecture options, DNS Private Resolver is a fairly recent service introduced by Microsoft. It's essentially a DNS Forwarder offered as a PaaS service. This eliminates the need for deploying a DNS forwarded virtual machine. One less IaaS service to patch & maintain. The networking enthusiasts were pretty happy to see this introduced.

I thought I would include a cost comparison. The IaaS option includes a 2 VM high availability setup. The DNS resolver comes out slightly more expensive however this doesn't factor in the operational overhead with managing a virtual machines, backup costs etc. It's fully a PaaS service so you really don't have to do any maintenance apart from updating your forwarding rulesets.

Distributed vs Centralised

With DNS Private Resolver, there are 2 architectures that can be adopted.

Centralised DNS has the Azure DNS Private Resolver as the custom DNS server on all spoke networks meaning all DNS is resolved within the Hub network. In this scenario the DNS Resolver Forwarding Ruleset is linked to the hub virtual network only where the rules are defined.

Distributed DNS uses the default Azure DNS server for all spoke networks with the DNS Resolver Forwarding Ruleset linked to the spoke networks to allow for the resolution to private DNS zones. By default, all DNS is resolved in the spoke virtual network unless it's a private DNS zone.

The first option has the Private DNS Zones linked to the hub only. The second option you can opt in for either. You can link the DNS Zones to each spoke network or link the DNS zone only to the hub but ensure you have forwarding rules in your linked ruleset to resolve private DNS zones. Either approach works. Microsoft references both in 2 different articles with no definitive answer on which is best. Both seem to have the same operational overhead.

In my example I have opted for a direct DNS zone link to the spoke virtual network.

Distributed DNS Architecture

In a typical scenario where you might have a hub network, you can deploy a single zone and link it each spoke virtual network. Now your only managing 1 zone for that service across your whole Azure estate.

Let's break this down visually:

• (1, 2 & 3) All on-premises DNS queries that need to resolve an Azure Private DNS name (i.e. Private Endpoints) are forwarded to the Azure Private Resolver using conditional forwarding on Active Directory DNS.

• (4) Any DNS queries that need to resolve Azure Private DNS from the spoke network are resolved through the private DNS zone link using the default Azure DNS on the virtual network.

• (5,6) Any DNS queries from the spoke virtual network that need to resolve DNS on-premises are forwarded to the on-premises DNS server through a forwarding rule set on the Private DNS resolver that uses the outbound endpoint. This is done through a DNS forwarding virtual network link. Essentially a conditional forwarder for any on-prem DNS queries.

This configuration is referred to as a distributedDNS architecture.

Centralised DNS Architecture

In a centralised DNS architecture, the spoke virtual networks use the Private DNS Resolver inbound endpoint as a custom DNS server.

The key difference here is that the Private DNS Zone is linked to the hub instead of the spokes and the forwarding ruleset is linked to the hub virtual network and not the spoke, so the forwarding rules are managed centrally.

Here is the different visually:

• (1, 2 & 3) All on-premises DNS queries that need to resolve an Azure Private DNS name (i.e. Private Endpoints) are forwarded to the Azure Private Resolver using conditional forwarding on Active Directory DNS.

• (4) Any DNS queries that need to resolve Azure Private DNS from the spoke network are resolved through the Private DNS resolver in the Hub which queries Azure DNS to resolve the Private DNS zone linked to the hub.

• (5) Any DNS queries from the spoke virtual network that need to resolve DNS on-premises are forwarded to the on-premises DNS server through a forwarding rule set on the Private DNS resolver that uses the outbound endpoint. This is done through a DNS forwarding virtual network link. Essentially a conditional forwarder for any on-prem DNS queries.

There is no right or wrong here with both architectures. It depends on how you want to manage this. Some organisations have to inspect all traffic centrally through an NVA so this centralised option would be best suited.

It's worth noting that if you have Azure Firewall, it can act as a DNS proxy if you adopt the centralised DNS architecture:

In this scenario you can forward your DNS requests to the Azure firewall IP. Now you get the advantage of traffic inspection and DNS caching. More on the topic here

If your workloads are only in Azure and you don't have the need for a DNS forwarder then create your private DNS zones in the Hub and link them to all of your spoke networks.

Key takeaway is not to duplicate DNS zones by keeping them centralised.

Hope this was useful and let me know in the comments if you would like to see more on this topic. I am looking to get this setup automated using Terraform as a reference architecture.