Azure hybrid DNS: when to use Private Resolver, on-premises forwarders and private zones

Azure hybrid DNS becomes fragile when each incident is fixed locally. A forwarder is added on a Windows DNS server, a private zone is linked to a spoke, a custom resolver is deployed in a hub, then a team adds a Private Endpoint and discovers that the same name does not answer the same way from Azure and from on premises.

Azure DNS Private Resolver helps make this model cleaner, but it does not choose the architecture by itself. You still need to decide which side queries which resolver, where private zones live, which suffixes are forwarded, and how to avoid turning every spoke into an exception.

Define resolution directions

A hybrid DNS design should first say who needs to resolve what. Query direction matters. Azure workloads may need to resolve internal on-premises zones. On-premises servers may need to resolve Azure private names, especially privatelink zones. Azure workloads may also need to resolve Private Endpoints without going through on premises.

From Azure to on premises
vm-app-01 -> dc01.corp.example.local
VNet-integrated Function -> api.mgmt.example.local

From on premises to Azure
admin-workstation -> myvault.vault.azure.net
tooling-server -> mystorage.blob.core.windows.net

From Azure to private Azure
spoke workload -> privatelink.vaultcore.azure.net
spoke workload -> privatelink.blob.core.windows.net

Without this matrix, the design often goes in the wrong direction. Teams create an outbound endpoint while the problem is a query coming from on premises, or configure an on-premises conditional forwarder while the failing spoke is not linked to the right Azure ruleset.

Role of Private Resolver

Azure DNS Private Resolver provides two building blocks. The inbound endpoint receives DNS queries from other networks, typically on premises, into Azure. The outbound endpoint lets the Azure resolver forward selected zones to external DNS servers through a ruleset.

Inbound endpoint
Receives queries coming from on premises
Acts as a target for conditional forwarders
Helps resolve Azure private zones from outside the VNet

Outbound endpoint
Forwards to on-premises DNS according to rules
Used by Azure workloads through linked rulesets
Does not provide an IP address to target directly

A common confusion is expecting the outbound endpoint to expose an address that on-premises DNS servers can target. That is not its role. For queries entering Azure, look at the inbound endpoint. For Azure queries leaving toward on-premises zones, look at the ruleset associated with the outbound endpoint.

Where to link private zones

Azure Private DNS zones can be linked to a hub, spokes or several VNets depending on the operating model. The choice must stay readable. Linking every zone to every spoke quickly becomes difficult to control. Centralizing everything without validating DNS paths can also prevent some workloads from resolving private names correctly.

Centralized pattern
Private zones in a central network resource group
VNet links to the hub or required spokes
Hybrid resolution through inbound endpoint

Controlled distributed pattern
Zones linked only to consuming VNets
Less implicit reach
More discipline required when creating Private Endpoints

Pattern to avoid
Links added over time without inventory
Duplicate privatelink zones in multiple places
Conflicting forwarders between hub and on premises

The right answer depends on the organization, but the principle does not change: the team must be able to explain why a zone is linked to a given VNet.

On-premises conditional forwarders

On premises, DNS servers must know which suffixes to send to Azure. For private PaaS services, public names such as myvault.vault.azure.net eventually resolve through a privatelink private zone. Do not break global public resolution. Forward only the necessary suffixes to the inbound endpoint and keep standard behavior for the rest.

Possible forwarders to the Azure inbound endpoint
privatelink.vaultcore.azure.net
privatelink.blob.core.windows.net
privatelink.azurewebsites.net

Document
Inbound endpoint IP address
Configured on-premises DNS servers
Exact suffixes
Test from a workstation and from an application server

Also validate that firewalls allow UDP and TCP 53 where needed. Intermittent DNS issues sometimes come from a blocked TCP path, visible only with larger responses.

Azure rulesets toward on premises

For Azure workloads that must resolve internal names, a DNS forwarding ruleset defines the suffixes sent to on-premises DNS servers. That ruleset must be linked to consuming VNets. An unlinked spoke will not get the expected behavior.

Azure ruleset
corp.example.local -> 10.0.0.10, 10.0.0.11
mgmt.example.local -> 10.0.0.10, 10.0.0.11

VNet links
vnet-spoke-app-prod
vnet-spoke-tools-prod

Validation
nslookup dc01.corp.example.local
nslookup api.mgmt.example.local
Compare from each consuming VNet

Conclusion

Reliable Azure hybrid DNS depends on clear directions. The inbound endpoint serves queries entering Azure. The outbound endpoint and rulesets serve Azure queries leaving toward other DNS servers. Private zones hold Azure private answers. On-premises forwarders direct required suffixes without breaking everything else.

Useful documentation fits in a few objects: source/suffix/resolver matrix, private zone link inventory, on-premises forwarders, Azure rulesets and validation commands from each important network. It is less spectacular than a large diagram, but much more effective when a name stops resolving in the right place.