Linkedin Profile

clouddevopsinsights

Managing Azure DNS at Scale: From DNS Forwarders to Private DNS Resolver

Abilash Vavilala's photo
Abilash Vavilala
·

5 min read

Cover Image for Managing Azure DNS at Scale: From DNS Forwarders to Private DNS Resolver

Introduction

DNS is a foundational service in any cloud architecture, but it becomes significantly more complex in hybrid environments. As organizations expand into Azure with hub-spoke networks, private endpoints, and on-premises integration, DNS design must evolve to handle scale, reliability, and maintainability.

This article walks through that evolution:

  • Traditional DNS forwarders and their limitations

  • Azure DNS Private Resolver

  • Inbound and outbound endpoints

  • DNS forwarding rulesets

  • Distributed vs centralized DNS architectures

  • Real-world hybrid resolution scenarios

The Traditional Approach: DNS Forwarders

In early Azure architectures, hybrid DNS resolution was typically achieved using custom DNS forwarder virtual machines.

Typical setup

  • On-premises DNS servers forward queries to DNS VMs in Azure

  • Azure VNets are configured to use these custom DNS servers

  • Conditional forwarding is manually configured

Challenges at Scale

This approach introduces several operational and architectural issues:

Operational overhead

  • DNS VMs require patching, monitoring, and backup

  • High availability must be designed and maintained

Scalability limitations

  • DNS traffic grows with workloads

  • Scaling requires manual intervention

Reliability concerns

  • DNS becomes dependent on VM availability

  • Misconfiguration can disrupt name resolution across environments

Complex hybrid resolution

  • Managing Azure Private DNS zones alongside on-premises zones becomes difficult

These challenges led to the need for a managed, cloud-native solution.

Azure DNS Private Resolver

Azure DNS Private Resolver is a fully managed service that provides native DNS resolution between Azure and on-premises environments without requiring DNS VMs.

It enables:

  • On-premises systems to resolve Azure private DNS zones

  • Azure resources to resolve on-premises domains

  • Centralized DNS forwarding logic

This service integrates directly with Azure networking and removes the need for infrastructure management.

Core Components

Inbound Endpoint

An inbound endpoint allows DNS queries from external networks (such as on-premises) to enter Azure.

Key characteristics:

  • Receives DNS queries from on-premises DNS servers

  • Resolves Azure Private DNS zones and private endpoints

  • Deployed in a dedicated subnet

Purpose:
Enable on-premises systems to resolve Azure-hosted private resources.

Outbound Endpoint

An outbound endpoint allows Azure resources to resolve external domains, such as those hosted on-premises.

Key characteristics:

  • Sends DNS queries out of Azure

  • Works with DNS forwarding rulesets

  • Enables conditional forwarding

Purpose:
Enable Azure workloads to resolve on-premises DNS zones.

DNS Forwarding Rulesets

A DNS forwarding ruleset defines how DNS queries should be routed.

Each rule includes:

  • Domain name (e.g., corp.local)

  • Target DNS server IP address

Rulesets can be:

  • Linked to multiple VNets

  • Centrally managed

  • Used to control DNS behavior at scale

This eliminates the need to configure DNS settings individually on each VNet.

DNS Architecture Patterns

Distributed DNS Architecture

In this model:

  • Azure VNets use the default Azure DNS service

  • A Private Resolver is deployed in a hub VNet

  • A forwarding ruleset is linked to spoke VNets

Flow:

  1. A VM in a spoke VNet sends a DNS query

  2. Azure DNS attempts to resolve it

  3. If no match is found, the ruleset is evaluated

  4. Matching queries are forwarded via the outbound endpoint

Key advantage:
Minimal configuration in spoke VNets and high scalability.

Centralized DNS Architecture

In this model:

  • VNets are configured to use a custom DNS server (inbound endpoint IP)

  • All DNS queries are sent to the hub

Flow:

  1. A VM sends a DNS query

  2. Query is directed to the inbound endpoint

  3. Resolver processes the request using:

    • Private DNS zones

    • Forwarding rules

    • External resolution

Key advantage:
Centralized control and consistent DNS behavior.

Building a Scalable and Secure DNS Architecture with vWAN Hub

For enterprise-scale environments, especially those using Virtual WAN (vWAN), DNS design should align with centralized connectivity and security principles.

  • Deploy a dedicated VNet for DNS

  • Host:

    • Private DNS Resolver

    • Inbound endpoint subnet

    • Outbound endpoint subnet

  • Connect this DNS VNet to the vWAN hub

  • Ensure connectivity to:

    • On-premises networks

    • Spoke VNets

    • Shared services

How it works

  • On-premises DNS forwards queries to inbound endpoint via vWAN hub

  • Azure VNets use rulesets linked to the resolver

  • Outbound endpoint routes DNS queries back to on-premises when required

Key Benefits

Scalability

  • DNS is decoupled into a dedicated VNet

  • Can support multiple regions and VNets

Security

  • Traffic flows through secured vWAN hub

  • Enables inspection and policy enforcement

Centralized control

  • Single DNS control plane for entire environment

Separation of concerns

  • DNS is isolated from application VNets

This model is particularly effective in large enterprises adopting hub-and-spoke with vWAN as the global transit hub.

Real-World Scenarios

Scenario 1: On-Premises VM Accessing Azure Storage via Private Endpoint

  1. On-prem VM queries:
    mystorageaccount.privatelink.blob.core.windows.net

  2. On-prem DNS forwards to inbound endpoint

  3. Private Resolver resolves using Azure Private DNS zone

  4. Returns private IP

  5. Traffic flows over private connectivity

Scenario 2: Azure VM Resolving On-Premises Application

  1. Azure VM queries: app.corp.local

  2. Azure DNS checks local zones (no match)

  3. Ruleset forwards request via outbound endpoint

  4. On-prem DNS resolves

  5. Response returned to Azure VM

References