Private endpoint DNS from on-premises: DNS Private Resolver or a forwarder in Azure

The private endpoint works from inside Azure, the site-to-site VPN or ExpressRoute circuit is healthy, and still a laptop in the office resolves the storage account or SQL server to its public address. Getting private endpoint DNS from on-premises right takes one piece most networks lack: something inside Azure that your own DNS servers can forward to. Azure's resolver at 168.63.129.16 only answers queries that start inside an Azure virtual network, so your data centre's DNS can't ask it directly, however good the link is. This guide sets up the managed way to bridge that gap, Azure DNS Private Resolver, and the older option of a DNS forwarder VM, and shows how to test each hop.

Why the link alone isn't enough

Inside Azure, a virtual machine asks 168.63.129.16, Azure looks in the private DNS zones linked to its network, and the private endpoint's name comes back private. Your on-premises DNS server isn't in a virtual network, so that address isn't reachable from it, and the zone links mean nothing to it. It resolves the name the way the rest of the internet does: public DNS returns the CNAME to the privatelink name and then the public address. Microsoft names this, custom DNS that never reaches Azure DNS, as the most common cause of on-premises clients failing to reach private endpoints.

The fix has two parts: a listener in Azure that accepts DNS queries from your network and asks Azure DNS on their behalf, and rules on your DNS servers that send the right names to it.

Create the resolver and its inbound endpoint

DNS Private Resolver is a managed, zone-redundant service; there's no server to patch. Plan it before you click create:

• Which network. Put it in a virtual network that's linked to all your privatelink zones, typically the hub. It must be in the same region as that network, and one resolver serves one network.
• A dedicated subnet for the inbound endpoint, delegated to Microsoft.Network/dnsResolvers and used for nothing else. It must be between /28 and /24; /28 is enough. If you'll later add an outbound endpoint (for Azure to resolve your on-premises names), it needs a second subnet of its own.
• Restrictions. Networks with virtual network encryption, IPv6-enabled subnets and ExpressRoute FastPath aren't supported.

# Subnet for the inbound endpoint, delegated to the resolver
az network vnet subnet create --resource-group <rg> --vnet-name hub-vnet --name snet-dns-inbound \
  --address-prefixes 10.0.250.0/28 --delegations Microsoft.Network/dnsResolvers

# The resolver, then its inbound endpoint
az dns-resolver create --resource-group <rg> --name hub-dns-resolver \
  --location <hub-region> --id <hub-vnet-resource-id>
az dns-resolver inbound-endpoint create --resource-group <rg> \
  --dns-resolver-name hub-dns-resolver --name inbound \
  --location <hub-region> \
  --ip-configurations "[{private-ip-allocation-method:Dynamic,id:<snet-dns-inbound-resource-id>}]"

Note the inbound endpoint's private address (az dns-resolver inbound-endpoint show); that's what your DNS servers will forward to. Choose a static address instead of dynamic if your firewall team prefers to allow-list a fixed one.

Point your DNS servers at it

On each on-premises DNS server, add a conditional forwarder to the inbound endpoint's address for each service you use privately. Microsoft's scenario guidance forwards the service's public zone name, for example blob.core.windows.net or database.windows.net, rather than its privatelink zone. That way the whole lookup, CNAME included, happens in Azure, where the private zone is consulted.

Microsoft's troubleshooting page shows the narrower form, forwarding only the privatelink zone (privatelink.blob.core.windows.net). It works too: your server follows the public CNAME, then forwards the privatelink part to Azure. Whichever you pick, use it for every service, and don't forward to 168.63.129.16 from on-premises; the inbound endpoint is the address that works from outside Azure.

On Windows DNS Server: Conditional Forwarders > New Conditional Forwarder, enter the zone name and the inbound endpoint's IP address. Domain controllers that serve many sites can store the forwarder in Active Directory so every DNS server gets it.

Test each hop

From an on-premises machine, test in this order, so the first failure tells you where to look:

# 1. Ask the inbound endpoint directly: proves the network path and the zone link
nslookup mystorage.blob.core.windows.net 10.0.250.4

# 2. Ask your own DNS server: proves the conditional forwarder
nslookup mystorage.blob.core.windows.net <office-dns-server>

# 3. Ask the way the application does, after clearing the cache
ipconfig /flushdns
Resolve-DnsName mystorage.blob.core.windows.net

A forwarder VM instead

Before DNS Private Resolver, the usual design was a DNS server VM (Windows DNS, BIND, or Azure Firewall's DNS proxy) in the linked network, forwarding to 168.63.129.16, with your on-premises servers forwarding to that VM. It still works, and Azure Firewall's proxy is a reasonable choice if you already route traffic through it. A VM is yours to patch, scale and make highly available, which is the work the resolver removes.

The other direction

Azure resources that need your on-premises names (intranet.contoso.local) use the resolver's outbound endpoint with a DNS forwarding ruleset: a rule per domain, pointing at your on-premises DNS servers, linked to the networks that need it. Rules match on the longest suffix, and a ruleset holds up to 1,000 of them.

Sources

• What is Azure DNS Private Resolver?, Microsoft Learn (inbound and outbound endpoints, subnet rules and sizes, restrictions, rulesets)
• Azure Private Endpoint DNS integration scenarios, Microsoft Learn (on-premises workloads with the resolver and with a forwarder; forwarding the public zone name)
• Troubleshoot private endpoint DNS resolution failure, Microsoft Learn (custom DNS as the most common on-premises cause; 168.63.129.16 only from inside Azure)
• Azure Private Endpoint private DNS zone values, Microsoft Learn (the zone names and their public forwarders)
• Azure DNS Private Resolver architecture, Azure Architecture Center (the forwarder-VM design it replaces)