Azure private endpoints: verify DNS before changing the firewall

Keep the service hostname in the application

A private endpoint places a network interface with a private address in your virtual network and connects it to a supported service. The application generally continues to use the service's normal hostname. DNS is responsible for making that hostname resolve through the appropriate private mapping on the networks that should use the endpoint.

Hard-coding the endpoint's IP address into an application can bypass the naming behavior the service expects and complicate TLS validation and future changes. Instead, confirm the service-specific DNS zone and records documented for the chosen resource type. Private Link DNS names vary by service and by subresource, so a zone copied from a different service is not a reliable template.

Test from the network that actually runs the workload

A laptop, a VM and a container-hosting environment can use different DNS resolvers. A private resolution that works on a VPN-connected workstation does not prove it works in the application's subnet. Perform the lookup from the affected runtime or a representative diagnostic host with the same resolver path, then record the hostname, CNAME chain and final address.

With Azure-provided DNS, link the appropriate private DNS zone to the virtual networks that need its records. With custom DNS or on-premises networks, design the forwarding path deliberately, including the Azure resolver integration where needed. Linking a zone does not automatically reconfigure every custom resolver. Network peering also does not by itself complete a DNS-forwarding design.

Check the private connection in order

1. Confirm the private endpoint targets the intended service and subresource.
2. Check that its connection is approved and its network interface has the expected private address.
3. Inspect the relevant private DNS zone, record and virtual-network links.
4. Resolve the normal service hostname from the application network.
5. Test the service operation using its normal hostname and runtime identity.

A connection can reach the public endpoint when DNS still returns the public address. Turning off public access before verifying the private resolver path makes that defect more visible, but it also interrupts the application. Rehearse the private connection first and make the network-access change as a controlled deployment step with a recovery plan.

Separate connection failures from permissions

Correct private DNS supplies an address; routing supplies a path; the service's authorization rules decide whether the caller can perform an operation. A managed identity with the correct role can still encounter a timeout because the host cannot reach the private address. A reachable endpoint can still return a permission error. Use the observed failure category to choose the next diagnostic check.

When a private name resolves correctly but a request fails, inspect routes, endpoint connectivity, workload egress rules and service configuration. Avoid treating an endpoint's approved state as proof that every consumer network can use it. The consumer's network path and DNS configuration are independent operational dependencies.

Document the resolver path as part of deployment

Record the public service hostname, private zone name, endpoint subresource, consumer networks and resolver forwarding rules. Test that arrangement when adding another virtual network or connecting an on-premises environment. A short DNS verification procedure is often more valuable than another broad firewall exception because it identifies where the application is actually trying to connect.

References

• Azure Private Endpoint private DNS zone values — Microsoft Learn
• What is a private endpoint? - Azure Private — Microsoft Learn