A private endpoint puts a service on a private IP inside your virtual network. It also creates a name that a client must resolve correctly, and that second half is where most implementations break.
The symptom is familiar: the endpoint exists, the network security group allows the port, and the application still times out. Nothing looks wrong in the portal because the connection is going to the public address, where it is refused.
What is actually happening
The service keeps its normal public DNS name, for example a database host. When a client queries that name, it receives the public address unless something overrides it.
A private DNS zone overrides it, but only if two things are true: the zone is linked to the virtual network that hosts the client, and the record inside the zone points at the private endpoint’s address.
Miss the link and the override does not apply. Miss the record and the zone is empty. Either way, the client resolves publicly.
The three checks that resolve most cases
- Does a private DNS zone exist for the service’s namespace, and does it contain an A record for the exact hostname the application uses?
- Is that zone linked to every virtual network that needs to resolve it, including peered networks and the hub if resolution is centralised?
- Is the client actually using the DNS server you think it is? A custom DNS server on a virtual machine, or a resolver forwarding ruleset, changes the answer.
The third check is where centralised architectures fail: the zone is linked to the hub, but the spoke’s DNS is not forwarding to the resolver that knows about it.
Why it looks like a firewall problem
Because the timeout is identical. A refused public connection and a blocked private one look the same from the application’s logs.
The quickest way to separate them is to resolve the name from inside the client subnet and compare the returned address with the private endpoint’s IP. If it returns a public address, networking is innocent and DNS is the cause.
Design decisions worth making early
Centralised or per-network zones. One set of zones in a hub, linked to spokes, is easier to govern. Per-network zones multiply records and are easy to leave stale.
Who owns the records. If endpoints are created by several teams, the records must be created by automation, or some will be missed. The endpoint and the record belong in the same change.
Name consistency. Applications sometimes connect by IP or by a legacy hostname. Those bypass the zone entirely and will keep working until the public path is closed, then fail.
The test that should be part of handover
From a machine in the client subnet, resolve the hostname, confirm the private address, then connect. Do it for every service with a private endpoint, and record the result.
That test takes minutes and prevents the most common post-launch incident in Azure environments. It also documents the expected answer, so the next person can tell a DNS failure from a service failure.
Beyond DNS
Private endpoints also change how the service is reached from on-premises and from other regions. Express route, VPN and peering each need their own resolution path, and the same zone-link logic applies.
If the environment is being built from scratch, the endpoint and DNS work belongs in the cloud landing zone rather than being retrofitted later. The Azure-specific build is described under Azure cloud setup, and the pricing for that work is on Azure cloud setup cost.
