One of the areas within Azure that has previously been lacking is a DNS forwarding capability.
Previously, this would require customers to deploy a virtual machine (VM) in an Azure virtual network, install a DNS service and configure forwarding rules. A typical deployment topology would look like this —
Whilst this approach works, we have the typical drawbacks associated with IaaS services, i.e. additional management overhead, backups, disaster recovery, etc.
We now have Azure’s native DNS Private Resolver service to solve this. According to Microsoft -
Azure DNS Private Resolver is a new service that enables you to query Azure DNS private zones from an on-premises environment and vice versa without deploying VM-based DNS servers.
This post will look at the different components and how they are deployed as a fully integrated DNS forwarding solution in Azure.
DNS Private Resolver service replaces a DNS forwarding VM with a native PAAS service. Benefits of this include -
Fewer IaaS VMs to manage — big win! 🎉
Transparent integration with Azure networking, DNS private zones, etc.
Deploy and configure via native Bicep / ARM, PowerShell / CLI
I’ve tested the service with a customer from its early private preview. Now that it's generally available (October 2022), I wanted to share some of my experiences and thoughts.
Key components
The DNS resolver related components are -
DNS Private Resolver
Inbound Endpoint
Outbound Endpoint/s
DNS Forwarding Rulesets
Forwarding rule/s
Links to Azure virtual network/s
Within the Azure Portal, these two services look like this -
There are a few different components to the solution. I’ll walk through these below and explain how they relate to each other.
It’s worth highlighting that DNS Private Resolver is simply a forwarding service. It doesn’t host any DNS zones but acts as the “glue”, allowing DNS resolution requests to be resolved across your Azure subscriptions and on-premises.
DNS Private Resolver
The DNS Private Resolver service is responsible for forwarding DNS requests from clients to other DNS servers. Within the service itself, we configure -
1 x inbound endpoint
1 (or more) x outbound endpoints
From a networking perspective, each endpoint requires a dedicated, delegated subnet.
The inbound endpoint is exposed as a private IP address within the subnet. This endpoint is typically used by on-premises clients that wish to resolve hostnames within Azure DNS Private zones.
The outbound endpoint is associated with DNS Forwarding Ruleset/s (see below). Azure uses this to forward requests for a specific domain to a DNS server that can resolve it. This endpoint requires network line-of-sight from its subnet to the target DNS server.
DNS Forwarding Rulesets
The DNS Forwarding Ruleset contains one or many forwarding rules (up to 1,000) and has the following characteristics -
Is mapped to one or more outbound endpoints
Linked to one or more VNETs where our Azure clients reside
Integrates transparently with Azure’s native DNS capabilities
When an Azure client makes a hostname request for a domain specified in a linked ruleset, it is transparently sent to the outbound endpoint and the specified DNS server for resolution.
Next, we’ll look at some common name resolution scenarios and how these two services work together.
Common Name Resolution Scenarios
Let’s look at some common name resolution scenarios using the above topology as our example.
Azure VM to on-premises DNS resolution
In this scenario, an Azure VM in the Marketing spoke VNET wants to resolve onpremvm01.onpremise.contoso.com -
The Azure VM sends the DNS request to the default Azure DNS server (168.63.129.16)
Azure DNS recognizes that the VNET has a matching rule within the ruleset
The DNS request is sent to the outbound endpoint
The outbound endpoint forwards the request to the specified DNS server (10.25.1.1)
The on-premises DNS server returns the IP address of onpremvm01 to the outbound endpoint
The outbound endpoint returns the IP address to the Azure VM
As you can see, this is a very simple flow. Other than linking the ruleset to the VNET, no additional configuration is required on the Azure VM or its VNET to resolve the hostname.
Similarly, if the Azure VM requested a hostname within the external.contoso.com domain, this would be resolved similarly but via the specified Internet DNS servers (8.8.8.8 or 8.8.4.4).
On-premises to Azure DNS Private Zone resolution
The other scenario is where an on-premises client wants to resolve a hostname within an Azure DNS Private Zone. For example, onpremvm01 wants to resolve sales-vm.sale.azure.contoso.com -
onpremvm01 sends the DNS request to its default DNS server, onpremdns01
onpremdns01 has a conditional forwarder configured for the azure.contoso.com domain and sends the request to the inbound endpoint
The inbound endpoint recognizes that the sales.azure.contoso.com private zone is linked to its VNET and can resolve it directly
The inbound endpoint returns the IP address for sales-vm to onpremdns01
onpremdns01 returns the IP address to onpremvm01
Conclusion
I hope you found this walkthrough helpful. DNS Private Resolver is a significant and well-overdue step forward (if you’ll pardon the pun!) for DNS forwarding within Azure.
When I think back to previous projects where we’ve ended up with complex solutions with multiple DNS forwarder VMs across the Azure estate, this has the potential to simplify it greatly.
Here are what I think are a few highlights of the service -
DNS Resolver and rulesets integrate seamlessly with existing Azure VNETs
For on-premises DNS servers, simply point to the Azure DNS Resolver’s private IP address
VNETs can be linked to Forwarding Rulesets in another subscription. This allows ruleset/s to be hosted in a hub subscription and shared across multiple spoke or “consumer” subscriptions
Rulesets can be shared across multiple VNETs
As always, comments and questions are welcome.
If you’d like to dive deeper into different DNS Private Resolver scenarios, please check out my latest post.
Useful Links
Microsoft docs
Bicep / PowerShell / Azure CLI reference
Terraform provider (as of Oct 2022, this is a work in progress)
コメント