Azure DNS Private Resolver

The Problem It Solves

Before DNS Private Resolver existed, if you wanted to resolve Azure Private DNS Zone records from on-premises, or forward on-premises domain queries from Azure, you had to run a custom DNS forwarder VM (e.g., Windows DNS Server or BIND on a Linux VM). This meant managing, patching, scaling, and ensuring high availability of that VM yourself — a maintenance burden and a potential single point of failure.

Azure DNS Private Resolver eliminates that entirely.

What It Is

Azure DNS Private Resolver is a fully managed, cloud-native DNS service deployed inside your VNet that acts as a bridge between:

• Azure (Private DNS Zones, VNet-internal resolution)
• On-premises networks (your corporate DNS servers)

It handles DNS queries coming in from on-premises and DNS queries going out from Azure — without any VMs to manage.

How It Works — The Two Endpoints

The resolver has two distinct components:

1. Inbound Endpoint

• Gets assigned a private IP address inside your VNet
• On-premises DNS servers can forward queries to this IP over ExpressRoute or VPN
• Allows on-premises clients to resolve Azure Private DNS Zone records — something that was previously impossible without a forwarder VM
• Example use case: on-premises user needs to resolve mystorageaccount.privatelink.blob.core.windows.net to its private IP

2. Outbound Endpoint

• Used with DNS Forwarding Rulesets
• Allows Azure VMs to forward specific domain queries to external DNS servers (e.g., on-premises DNS)
• Example use case: Azure VM needs to resolve server01.corp.contoso.local which only exists on-premises

DNS Forwarding Rulesets

A Forwarding Ruleset is a set of rules attached to the Outbound Endpoint that says:

Rulesets are associated with VNets, so multiple Spokes can share the same ruleset without duplicating configuration.

How It Fits Into Hub-and-Spoke

In an enterprise Hub-and-Spoke architecture, DNS Private Resolver lives in the Hub VNet and serves all Spokes centrally:

On-Premises DNS
      │
      │ (conditional forward)
      ▼
DNS Private Resolver ──► Inbound Endpoint (resolves Azure Private DNS Zones)
      │
      │ (outbound ruleset)
      ▼
On-Premises DNS (for corp.contoso.local queries from Azure VMs)
Spoke VNets ──► point DNS setting to Private Resolver inbound IP

All Spoke VNets are configured to use the resolver’s inbound endpoint IP as their DNS server, giving every workload consistent, centralized DNS resolution.

Key Benefits Over a Forwarder VM

A Real-World DNS Flow Example

Scenario: On-premises user wants to access a Storage Account via its private endpoint.

1. User’s machine queries on-premises DNS for mystorageaccount.privatelink.blob.core.windows.net
2. On-premises DNS has a conditional forwarder: send privatelink.blob.core.windows.net queries → DNS Private Resolver inbound endpoint IP
3. DNS Private Resolver receives the query
4. It checks the Azure Private DNS Zone linked to the Hub VNet
5. Finds the A record → returns the private endpoint IP (e.g., 10.1.2.5)
6. Traffic flows from on-premises over ExpressRoute directly to the private endpoint — never touching the public internet

In One Sentence

Azure DNS Private Resolver is a managed service that sits inside your VNet and acts as the intelligent DNS bridge between your on-premises network and Azure — handling both inbound queries from on-premises and outbound forwarding from Azure, without any VMs to maintain.

Here is how to read the diagram step by step:

① Query starts — An on-premises client needs to resolve a private endpoint hostname (e.g. mystorageaccount.privatelink.blob.core.windows.net). It asks the on-premises DNS server.

② Conditional forwarding — The on-premises DNS server has a conditional forwarder rule for privatelink.* domains. It forwards the query through the ExpressRoute/VPN tunnel to the DNS Private Resolver’s inbound endpoint IP inside the Hub VNet.

③ Zone lookup — The DNS Private Resolver receives the query and checks the linked Private DNS Zone inside Azure, which holds the A record for the private endpoint.

④ Private IP returned — The zone returns the private endpoint’s internal IP address (e.g. 10.1.2.5) — never the public IP — back through the chain to the on-premises client.

⑤ Traffic flows privately — The client now connects directly to that private IP over ExpressRoute, completely bypassing the public internet. Traffic never touches a public endpoint.

Spoke VNets inside Azure follow the same pattern — their DNS settings point to the resolver, and all resolution flows through the Hub centrally. Click any box in the diagram to explore that component further.

Great question — this is one of the trickiest concepts in hybrid Azure networking. Here is the full picture:

The Core Challenge

By default, Azure Private DNS Zones are only visible inside Azure VNets that are linked to them. An on-premises client has no way to query them directly — it sits outside Azure entirely. So without special architecture, an on-premises client resolving mystorageaccount.privatelink.blob.core.windows.net would get the public IP back, defeating the purpose of a private endpoint.

The solution is to build a DNS resolution chain that bridges on-premises and Azure.

The Resolution Chain — Step by Step

Step 1 — Client queries its local DNS

The on-premises client (laptop, server, application) sends a DNS query to its configured DNS server, just as it always would. Nothing special happens at the client level — it has no knowledge of Azure.

Step 2 — On-premises DNS checks its conditional forwarder

The on-premises DNS server (Windows DNS, BIND, etc.) has a conditional forwarder rule configured by your network team that says:

“Any query for privatelink.blob.core.windows.net — don’t try to resolve it yourself. Forward it to this IP address instead.”

That IP address is the inbound endpoint of Azure DNS Private Resolver, which is a private IP routable over ExpressRoute or VPN (e.g. 10.0.1.4).

Step 3 — Query travels over ExpressRoute or VPN

The forwarded query travels from on-premises, through the private tunnel, and arrives at the DNS Private Resolver’s inbound endpoint inside the Hub VNet. This is just a UDP packet on port 53 — it looks like any other DNS query.

Step 4 — DNS Private Resolver checks the Private DNS Zone

The resolver receives the query and uses Azure’s built-in DNS (168.63.129.16) to look up the answer. Because the Hub VNet is linked to the Private DNS Zone for privatelink.blob.core.windows.net, it can see the A record inside that zone — which contains the private endpoint’s internal IP (e.g. 10.1.2.5).

Step 5 — Private IP is returned all the way back

The resolver returns 10.1.2.5 back through the tunnel to the on-premises DNS server, which passes it back to the client. The client now has the private IP, not the public one.

Step 6 — Traffic flows privately

The client connects to 10.1.2.5 directly over ExpressRoute or VPN. The traffic never touches the public internet — it flows entirely over your private network into Azure.

What Has to Be in Place

For this to work, several things must be correctly configured:

On the Azure side:

• Azure DNS Private Resolver deployed in the Hub VNet with an inbound endpoint assigned a private IP
• The relevant Private DNS Zone (e.g. privatelink.blob.core.windows.net) linked to the Hub VNet
• An A record in that zone pointing to the private endpoint’s IP
• The inbound endpoint’s IP must be reachable from on-premises over ExpressRoute or VPN (NSGs and routing must allow UDP 53)

On the on-premises side:

• A conditional forwarder on the on-premises DNS server for each privatelink.* domain pointing to the resolver’s inbound endpoint IP
• Note: you need a separate conditional forwarder per private link zone (blob, sql, vault, etc.) — there is no wildcard forwarder for all privatelink.* in most DNS servers

The Most Common Misconfiguration

The single most frequent mistake is when Azure VMs also use a custom DNS server (e.g. a forwarder VM), and that custom server does not forward privatelink.* queries to Azure’s resolver at 168.63.129.16.

The result: the custom DNS server tries to resolve the private endpoint hostname itself, fails to find it, and either returns the public IP or returns nothing. The fix is always to ensure your custom DNS server has a forwarder rule sending privatelink.* queries to 168.63.129.16 before any other resolution is attempted.

Why You Can’t Just Use Azure Public DNS from On-Premises

You might wonder — why not just point on-premises clients directly at Azure’s public DNS? The answer is that Azure’s public DNS (168.63.129.16) is a link-local address, only reachable from inside an Azure VNet. It is not routable from on-premises at all. That is precisely why the DNS Private Resolver inbound endpoint exists — it gives you a routable private IP that acts as the on-ramp into Azure’s DNS infrastructure.

In short: the on-premises client never knows any of this is happening. It asks its local DNS, the local DNS quietly forwards to Azure via the tunnel, Azure resolves using its private zone, and the private IP comes back. The entire chain is transparent to the end user.

Would you like a diagram showing this flow for a specific service like Storage or SQL, or would you like to go deeper on the conditional forwarder setup?