Azure private DNS over VPN: resolver endpoint or forwarder
Both designs answer private zones over the tunnel. Compare a managed inbound endpoint with a forwarder VM, then check the path that must exist either way.
An on-premises server reaches an Azure VM by private address and still cannot resolve its private hostname, which sends people looking for a broken tunnel. The tunnel is fine. What is missing is a DNS boundary: nothing on the on-premises side knows that a particular Azure private zone should be answered by a resolver inside the VNet. Two designs close that gap, and they differ in what you end up operating rather than in whether queries work.
The tunnel carries queries, not zone knowledge
A site-to-site connection gives packets a route between the two networks. It does not tell the on-premises DNS server which namespace belongs to Azure or which address should answer it, so the query either goes to the internet and comes back empty or never leaves the local resolver.
The fix has two halves that are easy to separate. One half is a resolver inside the VNet that accepts queries arriving over the tunnel. The other half is a conditional forwarder on the on-premises side that sends exactly one namespace to that resolver. Neither half works alone.
Assume the zone is cloud.corp.example for the rest of this walkthrough, and treat every address as illustrative.
Option A: the managed inbound endpoint
Azure DNS Private Resolver provides an inbound endpoint that accepts DNS queries from outside the VNet. You deploy it into a dedicated delegated subnet, link the private zone to that VNet, and note the inbound address the service assigns.
On the on-premises DNS server you then create a conditional forwarder for the exact namespace toward that address:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Microsoft's hybrid DNS procedure documents both the zone link and the forwarder step. The managed path leaves you with no DNS software to patch, and the endpoint address stays stable for the life of the resource.
The trade is that you now own a resolver resource, its subnet delegation and its cost, which is real even when the query volume is tiny.
Option B: a forwarder VM inside the VNet
The older design runs DNS software on an ordinary VM in the VNet: Windows DNS, BIND or dnsmasq, with the private zone either hosted locally or forwarded to the Azure-provided resolver at 168.63.129.16. The on-premises conditional forwarder points at that VM's private address.
This option is familiar to teams that already run DNS servers, and it can carry extra logic such as logging or split-horizon answers. It also inherits every operational duty of a DNS server: patching, a second instance for availability, monitoring, and a rebuild path when the VM is replaced and its address changes.
An ordinary VNet host is not a DNS proxy until the service is installed and permitted to answer those clients, which is the step people skip when cloning a VM.
Which one fits your operation
The comparison is not about which design is faster. It is about whether you want to operate DNS software at all, and whether the query volume justifies a managed resource that bills by the endpoint and by the query.
| Question | Managed inbound endpoint | Forwarder VM |
|---|---|---|
| Software to patch | None | The DNS service on every instance |
| Address stability | Fixed for the resource lifetime | Tied to the VM or its reserved address |
| Availability work | Handled by the service | Second instance, health checks, failover |
| Extra logic | Limited to resolver features | Whatever the DNS software supports |
Whichever row decides it, the forwarder rule on-premises looks the same. That is the part that must exist in both designs, and it is the part that is most often missing when someone reports that resolution works from inside Azure but not from the office.
Check the path in order
Confirm the zone is linked to the VNet that holds the resolver, and confirm the on-premises forwarder names the namespace rather than a parent domain. A forwarder for corp.example will not match cloud.corp.example unless the resolver itself delegates, and the mismatch produces a clean negative answer that looks like a missing record.
Then check that the query reaches the endpoint: the on-premises source needs a route to the resolver address and a return path, and both UDP and TCP port 53 should be permitted where the policy allows it. An NSG cannot supply a missing zone record, and a correct zone cannot answer a query that never arrives.
Keep the requested FQDN next to the resolver you selected when you diagnose, and separate a timeout from a negative response. A timeout is a path or policy problem. A negative answer means the query arrived and the namespace did not match. Order of work: link the zone, add the conditional forwarder, open port 53 both ways, test one name from on-premises, and only then look at the application's own authorization.