Azure Private Endpoint: name resolution failures from on-premises and across VNets

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

A private endpoint gives a service a private IP address, but clients only use that address if their DNS query reaches a resolver that can see the right private zone. When a client gets a public address or NXDOMAIN, start with which resolver answered, and whether that resolver's virtual network is linked to the zone.

Microsoft states the rule directly for on-premises clients: DNS queries for private endpoints must originate from the virtual network that is linked to the private DNS zone. Everything below is a way of testing whether that is true for your client.

The commands were not run in a lab for this article. Names and addresses are examples. DNS lookup commands are standard operating system tools, and the Azure commands come from Microsoft's reference.

Why it matters

Private endpoint faults look like application faults. A connection string that worked yesterday now times out, or authentication fails because the client reached the public address and was refused.

These faults also move around. One subnet works because its DNS server has a cached answer. Another fails because a different forwarder handled the query. Testing from the wrong machine gives a misleading pass.

How resolution works

The CNAME chain

The connection string never changes. Azure creates a CNAME record on public DNS that redirects the service name to a privatelink name.

For Azure SQL Database, a healthy private lookup follows this shape:

contoso-sql.database.windows.net
  CNAME contoso-sql.privatelink.database.windows.net
    A     10.20.4.5  (from the private DNS zone)

Public resolvers follow the same CNAME and then get a public answer. The private zone overrides only the last step, and only for resolvers that can see it.

Microsoft notes that this chain is deliberately resolvable from anywhere on the internet. Seeing privatelink in a lookup does not prove you are using the private path. Only the final address does.

DNS and access control are also independent. A private endpoint does not necessarily restrict public network access to the service.

What a query does inside a virtual network

Each VNet's DNS setting sends the query to one place.

With the default setting, VMs use Azure's 168.63.129.16 address, which consults the private zones linked to that VNet. With custom DNS servers set, queries go to those servers instead.

So a link on the spoke does nothing if the spoke's clients ask a custom server elsewhere. The VNet that counts is the one the resolver sits in.

Microsoft's resolution order for default DNS is:

1. Private DNS zones linked to the VNet.
2. Forwarding ruleset links, where the longest matching suffix decides.
3. Azure DNS, if nothing matches.

Why peering does not carry DNS

Peering is about packets. Private zone visibility comes from a zone link. Microsoft notes that cross-VNet resolution has no dependency on peering.

The reverse also holds: a peered spoke with no zone link gets the public answer, even though it could reach the private IP.

Link the same zone to all hub and spoke VNets that contain clients. Do not create a separate zone of the same name per network. Microsoft warns that doing so requires manual operations to merge records.

The on-premises options

An on-premises server cannot use a private zone directly, so a resolver inside Azure has to answer for it. Microsoft documents two patterns.

A DNS forwarder in Azure. This is usually a VM, or Azure Firewall with its DNS proxy enabled, deployed in a VNet linked to the zone, with a server-level forwarder to 168.63.129.16.

Azure DNS Private Resolver. An inbound endpoint gives you a private address to forward to, with no VM to maintain. The on-premises DNS then points a conditional forwarder at it.

Microsoft describes 168.63.129.16 as a virtual IP of the host node. Do not point on-premises forwarders at it directly, because it serves resources inside Azure. That last step is editorial inference from the same documentation. Point them at your Azure resolver.

The most common configuration error

Conditional forwarders must target the public zone name, for example database.windows.net and not privatelink.database.windows.net.

The client asks for the public name first. If on-premises DNS only forwards the privatelink suffix, the first query goes to the internet. As general DNS behaviour, whether the later step comes back to Azure then depends on how your server chases the CNAME. Forward the public suffix and the chain resolves in one place.

Inbound endpoint requirements

Per the Private Resolver overview:

• Each endpoint needs its own subnet, delegated to Microsoft.Network/dnsResolvers, used for nothing else.
• The subnet must be between /28 and /24. A /28 fits current endpoint limits.
• A resolver can reference only one VNet, in its own region, and several resolvers cannot share a VNet.
• VNets with encryption enabled do not support the resolver. Check this before committing to the design.

The virtual network hosting the resolver must also be linked to the zone. That last point is our reasoning from the resolution order above.

An inbound endpoint's address can be static or dynamic. A dynamic address could change if the endpoint is reprovisioned. On-premises forwarders store this address, so use a static one.

Finding the fault

Test each hop from a machine where the failure actually occurs, and record which DNS server answered.

Step 1: read what the client gets

Resolve-DnsName contoso-sql.database.windows.net

dig contoso-sql.database.windows.net +noall +answer

Step 2: ask the resolver directly

Take the client's forwarding chain out of the test by querying each server by address.

dig contoso-sql.database.windows.net @10.0.0.4 +noall +answer

Replace 10.0.0.4 with your inbound endpoint or forwarder. If that returns the private address while the client does not, the fault is between the client and that server: the conditional forwarder, a firewall on port 53, or a cached answer.

If the forwarder also returns a public address, the fault is in Azure. Continue below.

Also test TCP, since a truncated UDP response tells the client to retry over TCP. With dig, add +tcp. A firewall that allows only UDP port 53 can produce partial failures.

Step 3: test from a VM in the resolver's VNet

Run the same lookup from a VM in the linked VNet using default DNS. A correct answer there proves the zone, record and link are right.

The conclusion depends on step 2. If the forwarder returned the private address, you have already narrowed the fault to the path between client and forwarder. If the forwarder returned a public address while this VM gets the private one, suspect the forwarder itself: its server-level forwarder, its own DNS setting, or the link on its VNet.

Step 4: inspect the zone and its links

az network private-dns link vnet list \
  --resource-group <zone-rg> --zone-name privatelink.database.windows.net \
  --output table

az network private-dns record-set a list \
  --resource-group <zone-rg> --zone-name privatelink.database.windows.net \
  --output table

az network private-endpoint dns-zone-group list \
  --resource-group <endpoint-rg> --endpoint-name <endpoint-name> --output json

Check three things:

• The link exists for the VNet the resolver sits in, and shows Link Status Completed. A new link can take a few minutes.
• The A record matches the private endpoint's interface. The interface holds the FQDN and private IP address, and that IP stays the same for the endpoint's lifetime.
• A zone group exists if you expected records to be managed automatically. Without one, records are maintained by hand and can be left behind.

Automatic configuration only works with the recommended zone names, so a slightly different name quietly falls out of that process.

Step 5: if DNS is right, check the network

Once the client resolves the private address and still cannot connect, DNS is no longer the problem.

Look at routing over the VPN or ExpressRoute to the endpoint's subnet, and at firewalls on that path. Private endpoints support network security groups and user-defined routes through network policies, and these are disabled by default and need enabling on the subnet.

Two diagnostic blind spots apply. Effective routes and security rules are not displayed for a private endpoint's interface in the Azure portal, and NSG flow logs are unavailable for inbound traffic to a private endpoint. Capture on the client or an appliance in the path.

The failure that breaks other resources

Linking a privatelink zone can change the answer for resources of that type that have private endpoint connections elsewhere, including ones you do not own.

Microsoft cautions that networks using a private zone for a resource type can only resolve public resources if those have no existing private endpoint connections elsewhere, unless more DNS configuration is added. Otherwise the zone answers NXDOMAIN, because it holds no matching record.

So a storage account owned by someone else, with a private endpoint in their tenant, can vanish from your network as soon as you link privatelink.blob.core.windows.net.

Microsoft's managed remedy is fallback to internet, set on the virtual network link. The resolutionPolicy property takes NxDomainRedirect, or the portal option Enable fallback to internet, and needs API version 2024-06-01 or later. The resolver then retries publicly after an NXDOMAIN from the private zone. Microsoft scopes this to Private DNS zones for Private Link.

Fallback has a cost. A record that is missing by mistake no longer produces an error, and the client silently takes the public path (our reasoning from the behaviour above). Where private-only access matters, keep public network access disabled on the service, so a fallback fails visibly.

A hand-entered public A record also works, but Microsoft does not recommend it, because the record will not follow changes to the public address.

A negative answer may also be cached. After you fix a record, a client can keep failing until that entry expires, so clear caches on the client and on forwarders before retesting.

What to choose and why

These are editorial recommendations.

Microsoft recommends the hosts file only for testing, and an entry left behind is its own later outage.

Use one private endpoint per resource for a network with a common DNS configuration, as Microsoft recommends, to avoid duplicate entries.

Risks and limits

Warning: linking a privatelink zone to a VNet, or replacing a conditional forwarder, changes name resolution for every client using it. Roll out in stages, starting with a test VNet, and have the previous configuration recorded.

• Existing Azure Files connections must be remounted if they were connected to the public endpoint.
• Do not attach a zone tied to one service to private endpoints for two different Azure services. Microsoft says this deletes the initial A record.
• A DNS zone group supports up to five zones and one zone per name.
• Private DNS limits at the time of writing are 1,000 VNet links per zone and 1,000 zones per VNet. A VNet can register automatically to only one zone, though that applies to VM records.

Sources

Opened 9 November 2026. Sources behind the corrections reopened 10 November 2026.

• Azure Private Endpoint DNS configuration
• Azure Private Endpoint DNS integration
• What is a private endpoint?
• What is Azure DNS Private Resolver?
• Private Resolver endpoints and rulesets
• What is Azure Private DNS?
• Virtual network links for private DNS
• Fallback to internet for private DNS zones
• What is IP address 168.63.129.16?
• Azure subscription and service limits
• Azure Firewall DNS settings
• Manage network policies for private endpoints
• RFC 7766: DNS Transport over TCP
• az network private-dns link vnet
• az network private-dns record-set a
• az network private-endpoint dns-zone-group

This article was originally published on 10 November 2026.