The VPN is up, routing is correct, the firewall lets traffic through — and still nobody in the data centre can reach the new database in Azure. Usually it is not the network. It is that two DNS worlds know nothing about each other.

Two namespaces that never met

On-prem there is almost always a Windows DNS server on a domain controller. It is authoritative for the internal zone, say corp.example.com, and forwards everything else to an upstream resolver.

In Azure there are Private DNS zones. These are fully fledged DNS zones, but they exist only inside the virtual networks they are connected to through a virtual network link. They are resolved by the platform resolver at 168.63.129.16 — an address every VM in every VNet can reach.

And that is exactly where the problem sits: 168.63.129.16 cannot be reached from on-prem. Not over VPN, not over ExpressRoute. The address is only valid from within the VNet. A conditional forwarder on the Windows DNS pointing straight at it goes nowhere.

Delegation or conditional forwarding?

Before turning to Azure, it is worth separating the two mechanisms properly — they get lumped together often, although they operate on different levels.

With a delegation, a zone hands responsibility for a sub-branch to someone else. The zone example.com holds NS records for azure.example.com pointing at other name servers. This is part of the DNS data itself: anyone following the chain from the root ends up at the same servers. Delegation is authoritative and globally valid.

With conditional forwarding, a single resolver decides where to send queries for a particular zone. This lives in no zone file, only in the configuration of that one server. Anyone who does not ask it knows nothing about it. Conditional forwarding is pure routing of questions, not authority.

The rule of thumb: delegation when the target servers should be discoverable by everyone; conditional forwarding when only your own resolvers need to know the way.

Why delegation to Azure does not work

For Azure Private DNS zones, delegation is off the table as a matter of principle. A delegation needs NS records pointing at reachable name servers. Private zones have no name servers of their own — they are not a service with an IP address you could enter somewhere, but a data store that the platform resolver of a linked VNet reads.

There is simply nothing an NS record could point to. That leaves conditional forwarding as the only option from on-prem to Azure — and it needs a target that is reachable from on-prem.

The DNS Private Resolver

The traditional answer was a VM in the VNet running a DNS service that forwarded to 168.63.129.16. It worked, but it carried every drawback of a VM: patching, availability, licensing, monitoring — for a service that does nothing but pass queries along.

The Azure DNS Private Resolver replaces that construction with a managed service. It is deployed into a VNet and consists of two parts that are best considered separately, because they work in opposite directions.

Inbound endpoint — from on-prem into Azure

The inbound endpoint receives a private IP address from a dedicated subnet in the VNet. That address is reachable from on-prem over VPN or ExpressRoute. The Windows DNS in the data centre gets a conditional forwarder pointing at this IP — and through it resolves everything held in the linked private DNS zones.

Outbound endpoint — from Azure to on-prem

The other direction runs through the outbound endpoint together with a DNS forwarding ruleset. The ruleset holds rules of the form “zone → target DNS servers” and is linked to one or more VNets. A rule for corp.example.com carrying the IP addresses of the domain controllers lets VMs in Azure resolve internal names.

Both endpoints need a dedicated subnet of their own, delegated to Microsoft.Network/dnsResolvers. The subnets cannot be shared with other resources, and a /28 is the smallest permitted size. Plan this in from the start rather than rebuilding a production VNet later.

What it looks like in practice

For a typical hub-and-spoke environment the split looks like this:

Private Resolver in the hub VNet
  Inbound  endpoint  →  10.0.10.4   (subnet 10.0.10.0/28)
  Outbound endpoint  →              (subnet 10.0.11.0/28)

On-prem Windows DNS
  Conditional forwarder
    privatelink.database.windows.net  →  10.0.10.4
    privatelink.blob.core.windows.net →  10.0.10.4

DNS forwarding ruleset, linked to hub and spokes
    corp.example.com  →  10.50.1.10, 10.50.1.11

The spoke VNets need no resolver of their own. They keep their DNS setting on “Azure-provided” and receive the forwarding through the ruleset link. The private DNS zones are linked to every VNet that should resolve them.

Private Link and the privatelink zones

The most common reason for all this effort is private endpoints. Creating a private endpoint for an Azure SQL database produces an A record in the zone privatelink.database.windows.net pointing at the private IP.

The trick sits in public DNS. The regular name of the database does not resolve to an address directly, but through a CNAME:

mydb.database.windows.net
   → CNAME mydb.privatelink.database.windows.net
        → A  10.0.20.5      (from the private DNS zone)
        → A  20.x.x.x       (public, without the private DNS zone)

Whoever can resolve the private zone gets the internal address. Whoever cannot gets the public one. This is why the on-prem conditional forwarder must point at the privatelink.* zones precisely — the CNAME leads there on its own.

Important: forward only the privatelink zone, never database.windows.net or even core.windows.net as a whole. Otherwise every public lookup for those services also travels through the resolver — creating an unnecessary dependency and outages that are hard to trace once the link to Azure is in place.

Pitfalls

The same zone on both sides. If corp.example.com exists both on-prem and as a private DNS zone, whichever resolver happens to be asked decides the answer. Such split-brain setups produce faults that appear or vanish depending on where the client sits. A dedicated subdomain for Azure, for instance az.corp.example.com, avoids the whole class of problem.

Forwarding loops. If the ruleset sends corp.example.com to on-prem and the DNS server there forwards the same zone back to Azure, queries circle. Every zone belongs to exactly one side, and the other side asks there — not the other way round.

Rules that are too broad. A rule for . or for entire provider domains turns the resolver into a single point of failure for all name resolution. Keep rules as narrow as possible.

Forgotten VNet links. Both private DNS zones and the ruleset only take effect in linked VNets. A new spoke that nobody linked will suddenly resolve publicly — and connect over the internet instead of through the private endpoint. That tends to surface only during a security review.

Region. The private resolver lives in the same region as its VNet. Multiple regions mean multiple resolvers, or a conscious decision to accept the detour.

What to remember

Delegation and conditional forwarding solve different problems: one distributes authority, the other merely the route to the question. For Azure Private DNS zones there is no authority to distribute — which leaves forwarding, and forwarding needs a target reachable from on-prem.

That target is exactly what the inbound endpoint of the DNS Private Resolver provides. The outbound endpoint with its ruleset opens the return path. Together they are the intended route today — and considerably less work than the DNS forwarder VM that used to be maintained for the job.