In a previous post, I provided an overview of Azure’s DNS Private Resolver service and how it may be used for two fairly basic but common name resolution scenarios -
Azure virtual machines (VMs) to on-premises name resolution
On-premises to Azure Private DNS zone name resolution
As a quick recap, this topology is shown below -
Encountering a customer or project where requirements fit neatly into a default architecture is quite rare in my experience. Typically, a customer will have their own unique set of requirements, quirks and general “messiness” within their IT estate, which requires thinking through more carefully.
This post shows how DNS Private Resolver can be deployed in additional scenarios that hopefully help you with your customer deployments.
Scenario 1 — One resolver, multiple rulesets
As a quick recap, a ruleset consists of one or more rules that routes DNS resolution requests for specific domains to a specific DNS server i.e. on-premises, Internet etc..
In the default scenario above, we have a single DNS Forwarding ruleset used by all of our Azure VMs. Whilst having a single ruleset is convenient from a manageability perspective, there may be scenarios where different Azure clients require different forwarding rules.
For example, if we take the scenario where we have the following Azure VM workloads -
Windows Server servers joined to an on-premises Active Directory domain
Linux workloads
The Windows Servers need to resolve on-premises Active Directory domain controllers. However, the Linux servers need to resolve a different set of on-premises domains using different on-premises DNS servers.
On-premises, the customer already utilizes different DNS servers for these workload types, i.e. domain controllers with AD-integrated DNS zones for Windows clients. For Linux clients, the BIND DNS service is installed on several Linux servers.
Using multiple DNS Forwarding rulesets with their own unique rules makes it possible to direct DNS requests from Azure to the appropriate on-premises DNS servers.
The features of DNS Private Resolver that make this possible are -
Different Azure virtual networks can be bound to different rulesets
Multiple rulesets can be bound to a single DNS Private Resolver and outbound endpoint
By taking the original architecture and modifying it slightly, we end up with this topology -
Scenario 2 — BareMetal resources
When we deploy an Azure resource, i.e. a virtual machine, Azure SQL DB, etc. and a plethora of other IaaS and PaaS Azure services, we typically consume them from the Azure Marketplace.
These are what we think of as Azure “native” resources. They’re deployed using the native ARM providers (Bicep, Terraform etc.) and managed using a standard set of tooling (Azure Portal, AZ CLI, PowerShell etc.)
However, a different, less well-known type of Azure deployment is called “BareMetal”.
Some Azure customers with specialized workloads have specific compute or storage requirements that can’t be met with native Azure services.
Example BareMetal deployments include HPE Cray supercomputers, SAP HANA and Nutanix clusters. Deployments are typically completed in partnership with an ISV and Microsoft. They undertake the deployment and configuration of the physical hardware and ensure it’s made available via the Azure data plane.
It’s not a very “cloudy” model, as often, physical hardware has to be wheeled into an Azure datacenter at a high cost.
So, how does this relate to DNS resolution? Most BareMetal services don’t leverage the native Azure DNS service (168.63.129.16). Therefore, we need a way to resolve Azure Private DNS zones and forward DNS requests to the Internet or on-premises.
In this scenario, the BareMetal services are pointed at the DNS Private Resolver’s private IP address. DNS Private Resolver takes care of the rest by -
Resolving any Private DNS zones linked to the resolver’s VNET
Forwarding requests for specific DNS zones (via the outbound endpoint) based on the ruleset linked to the resolver’s VNET
Resolving any Internet domains via Azure’s 168.63.129.16 DNS server
Scenario 3 — Cross-tenant name resolution
Some Azure customers may, for various reasons, have their subscriptions distributed across multiple Azure AD tenants. Alternatively, some organisations need to integrate with other organisations in another tenant.
In this scenario, organisations have a requirement to resolve DNS hostnames in another tenant.
Azure offers some cross-tenant capabilities, such as VNET peering. However, from a DNS Private Resolver perspective, VNETs can only be linked to a forwarding ruleset in the same tenant.
In the topology shown below, we have -
separate DNS Private Resolvers for each tenant
different forwarding rulesets configured for the corresponding resolvers
Effectively, each resolver is unaware that the corresponding IP address represents another resolver. As far as it’s concerned, it’s just a regular DNS server. In fact, one organization could be using a resolver and the other a traditional VM running a DNS forwarding service.
Scenario 4 — Protective DNS integration
Within Azure, you may have noticed a particular IP address, 168.63.129.16, cropping up in a few places.
It is a unique virtual IP that provides integration with the underlying Azure platform. From a DNS perspective, it also acts as the default DNS server for virtual machines within a VNET.
For example, if a VM requests a specific hostname, Azure will initially check whether the domain matches a linked DNS private zone. If not, Azure will then attempt to resolve the hostname as an Internet hostname. Typically, we don’t need to configure the resolution of Internet hostnames; it just works.
However, some organizations require a Protective DNS (PDNS) service to resolve Internet hostnames for compliance and security reasons.
Several commercial PDNS solutions are available from well-known vendors such as Cloudflare and Akamai. These vendors claim to provide increased security for DNS requests such as blocking specific sites, anti-malware, policies and reporting.
Integrating such a service into our Azure DNS topology is relatively straightforward. We require -
a wildcard DNS forwarding rule for the . domain pointing at the PDNS service
an Azure NAT Gateway on the outbound endpoint subnet
As commercial services, most PDNS vendors will only allow DNS requests from a known list of public IP addresses. Therefore, we add a NAT Gateway to ensure Internet DNS requests originating from the outbound endpoint always have the same public IP address.
The topology looks like this -
With this wildcard rule in place, the DNS resolution behaviour is now -
Matching DNS private zones and more specific forwarding rules will handle requests first
The . wildcard rule has the lowest priority and will apply to any other non-matching domains, i.e. Internet hosts
Conclusion
I’ve separated out the different scenarios for clarity, but ultimately, they’re just Lego-like building blocks. Combine and fit them together as you need to based on your particular requirements.
I haven’t touched on disaster recovery or hybrid resolution from on-premises. I’ve added some links below.
As always, I hope you found this helpful. If you have any questions or comments, please let me know.
Additional information
Configuring hybrid name resolution from on-premises
Additional architectural guidance for higher resiliency and enabling disaster recovery scenarios.
In-depth information on how to configure conditional forwarding rules
Comments