2.2 Azure Private DNS Resolver & Hybrid Name Resolution

Azure Private DNS Resolver & Hybrid Name Resolution

In hybrid cloud architectures connecting on-premises corporate datacenters to Azure via Site-to-Site VPN or ExpressRoute, bidirectional Domain Name System (DNS) resolution is an absolute operational requirement. On-premises workloads must seamlessly resolve Azure Private Endpoints and private services, while Azure workloads must resolve internal Active Directory domains and on-premises servers.

Historically, this required deploying, patching, and maintaining highly available pairs of IaaS virtual machine DNS forwarders (such as Windows Server DNS or BIND Linux VMs). Azure Private DNS Resolver replaces this operational burden with a fully managed, highly available, scalable PaaS offering.

---

The Hybrid DNS Dilemma & The PaaS Evolution

To understand why Azure Private DNS Resolver is transformative, consider the limitations of the traditional IaaS VM approach:

+-----------------------------------------------------------------------------------------+
|                        Legacy IaaS DNS Forwarder Architecture                           |
|                                                                                         |
|   On-Premises DNS   <=== S2S VPN / ExpressRoute ===>   Hub VNet DNS VMs (IaaS)          |
|   (Forwarder: *.azure)                                (Forwarder: 168.63.129.16)        |
|                                                                                         |
|   Pain Points: OS patching, clustering, single points of failure, custom VNet DNS IPs  |
+-----------------------------------------------------------------------------------------+
                                            vs.
+-----------------------------------------------------------------------------------------+
|                        Modern Azure Private DNS Resolver (PaaS)                         |
|                                                                                         |
|   On-Premises DNS   <=== S2S VPN / ExpressRoute ===>   Inbound Endpoint (Private IP)    |
|                                                        Outbound Endpoint + Rulesets     |
|                                                                                         |
|   Benefits: Zero VM maintenance, native AZ resiliency, 10,000 QPS/endpoint, PaaS SLA   |
+-----------------------------------------------------------------------------------------+

Advantages of Azure Private DNS Resolver

• Zero Infrastructure Management: No virtual machine patching, OS licensing, or availability set/zone configuration.
• High Availability & High Throughput: Native multi-zone availability supporting up to 10,000 queries per second (QPS) per endpoint.
• Native VNet DNS Preservation: VNets retain default Azure-provided DNS (168.63.129.16), avoiding manual custom DNS IP maintenance across hundreds of spoke VNets.

---

Architecture & Subnet Delegation Prerequisites

An Azure Private DNS Resolver is deployed within a Virtual Network (typically the Central Hub VNet in a Hub-and-Spoke topology). It requires dedicated subnets delegated to the Microsoft DNS resolver resource provider.

Subnet Requirements

1. Inbound Endpoint Subnet:
   • Must be delegated to Microsoft.Network/dnsResolvers.
   • Contains the static private IP address that listens for incoming DNS queries.
   • Minimum recommended subnet size: /28 (provides 16 IP addresses; minimum supported is /28).
2. Outbound Endpoint Subnet:
   • Must be delegated to Microsoft.Network/dnsResolvers.
   • Acts as the egress interface for queries sent from Azure to external/on-premises DNS servers.
   • Minimum recommended subnet size: /28.
3. Subnet Isolation Rules:
   • Inbound and Outbound endpoints cannot share the same subnet.
   • The subnets cannot host any other workloads, VMs, or private endpoints.
   • Network Security Groups (NSGs) and User-Defined Routes (UDRs) attached to delegated resolver subnets must allow UDP/TCP port 53 traffic.

// Azure Bicep: Dedicated Subnet Delegation for Private DNS Resolver
resource inboundDnsSubnet 'Microsoft.Network/virtualNetworks/subnets@2023-05-01' = {
  name: 'snet-dns-inbound'
  parent: hubVnet
  properties: {
    addressPrefix: '10.0.10.0/28'
    delegations: [
      {
        name: 'dnsResolverDelegation'
        properties: {
          serviceName: 'Microsoft.Network/dnsResolvers'
        }
      }
    ]
  }
}

---

Inbound Endpoints: On-Premises to Azure Resolution

An Inbound Endpoint allows name resolution queries originating from outside Azure (on-premises datacenters, remote branches, or other cloud providers) to query Azure Private DNS Zones.

How Inbound Endpoints Work

1. The Inbound Endpoint allocates a private IP address within its delegated subnet (e.g., 10.0.10.4).
2. The endpoint listens on UDP and TCP port 53 for standard DNS requests.
3. When a query arrives over ExpressRoute or S2S VPN, the Inbound Endpoint forwards the query to the Azure platform resolver (168.63.129.16).
4. The Azure platform resolver queries all Azure Private DNS Zones linked to the resolver's VNet (such as privatelink.blob.core.windows.net or corp.internal).
5. The resolved private IP address is returned back to the on-premises client.

On-Premises DNS Configuration

On the on-premises DNS servers (Windows Active Directory DNS or BIND), the administrator configures Conditional Forwarders:

• Forwarding Domain: privatelink.blob.core.windows.net (or *.azure.contoso.com)
• Master / Target IP: 10.0.10.4 (Inbound Endpoint IP)

---

Outbound Endpoints & DNS Forwarding Rulesets: Azure to On-Premises Resolution

An Outbound Endpoint enables Azure VMs and workloads to conditionally resolve on-premises or third-party DNS domains without changing the VNet's default DNS server settings.

Core Components

1. Outbound Endpoint: The egress network interface in the resolver VNet that transmits forwarded queries to external IP destinations.
2. DNS Forwarding Ruleset: A management resource that groups one or more forwarding rules. The ruleset is attached to one or more Outbound Endpoints and then linked to target Virtual Networks.
3. Forwarding Rules: Individual conditional rules defined inside a Ruleset, consisting of:
   • Domain Name: The target domain suffix (e.g., onprem.contoso.com. or root . for catch-all).
   • Target DNS Servers: List of external IPv4/IPv6 addresses and ports (default: port 53).
   • Rule Priority: An integer between 100 and 1000 (lower numbers indicate higher priority).
   • Rule State: Enabled or Disabled.

Longest Domain Match Rule Evaluation

When a VM in a linked VNet issues a query, the DNS Forwarding Ruleset evaluates the domain matching using Longest Suffix Match:

• If a VM queries server01.emea.corp.contoso.com:
  • Rule 1: contoso.com (Priority 500) -> Target: 192.168.1.10
  • Rule 2: corp.contoso.com (Priority 200) -> Target: 192.168.2.10
  • Result: Rule 2 matches because corp.contoso.com is a longer, more specific match than contoso.com, regardless of priority number. Priority numbers resolve ties when duplicate domain names exist.

---

Legacy IaaS Forwarders vs. Azure Private DNS Resolver