Private endpoints still need a DNS design

The application works from a virtual machine beside the private endpoint and fails from the office network. The endpoint itself is healthy. The two clients are asking different resolvers and receiving different answers.

For the cloud network lead, private connectivity includes a name-resolution design. Creating an endpoint is one step; making the application’s existing service name resolve appropriately across cloud, office and remote environments is another.

Follow the name from the client

Start with the fully qualified name the application actually uses. Identify the resolver selected by the client, any forwarding path and the zone responsible for the final answer. Repeat that trace for each intended client environment. A successful lookup from an administrator’s laptop cannot establish how a workload in another network resolves the same name.

Azure’s private-endpoint DNS guidance explains the use of private zones and resolver options to return the private endpoint address while retaining application connection names. It also warns about overriding zones used for public endpoints. A private zone can therefore solve one resolution requirement while creating another if its scope is chosen carelessly.

Write down the intended answer for each client population. Some callers may legitimately use a public route while others must use the private endpoint. If the service must be private-only, make that an explicit access requirement as well as a DNS decision.

A hosts-file entry can help isolate a problem in a test. It is a poor operating design for a changing fleet because it distributes the answer without a dependable maintenance process.

Test resolution, connection and permission separately

A lookup result tells you where the client intends to connect. It does not establish that routing permits the connection or that the resource will authorise the operation. Microsoft’s guidance explicitly separates public name resolution from data-plane access: the existence of a resolvable name does not grant access to the service.

Use three observations during acceptance. First, confirm the resolved destination from the actual client. Second, verify the supported network connection to that destination. Third, perform the intended resource operation using the correct identity. Keeping these stages separate makes failures much easier to assign to the right team.

For a hypothetical application accessing object storage, a successful DNS lookup followed by an authorisation error can mean that private routing works but the workload identity lacks permission. Changing DNS repeatedly would not fix that problem. Equally, a successful request over an unintended public route can hide a missing private-zone link.

Include negative tests. A client outside the permitted boundary should receive the expected refusal when the requirement is private-only access. The test should verify the service’s public-access setting and resource controls, rather than assuming a private endpoint automatically disables every alternative route.

Keep a resolution matrix for cloud and office clients

Microsoft’s DNS integration scenarios show on-premises resolution through an Azure forwarder or Azure Private Resolver. In the documented SQL example, the conditional forwarder uses the public service zone, database.windows.net, rather than the privatelink zone. Check the service-specific guidance before applying that pattern elsewhere.

Record observed results from each environment rather than copying the intended design into every row. Include another resource using the same public service namespace to detect an unintended private-zone override. Add resolver failure and recovery to the broader DNS resilience exercise.

Design the failure and the next deployment

Use a DNS resilience exercise that crosses the cache boundary to test this design. A successful lookup from a warm cache is not evidence that a new or uncached name will resolve during the outage.

Check what happens when a forwarding resolver is unavailable, a network link is missing or a new resource is provisioned. Decide which component owns record creation and cleanup. Manual records can be appropriate in a controlled case, but their lifecycle still needs an accountable owner.

Pay particular attention to resources of the same service type that use different access patterns. A broad private-zone override can make a previously working public dependency disappear from the client’s view. Test the neighbouring services the application needs, not only the new endpoint.

Keep the DNS configuration in the deployment and recovery documentation. A replacement network or restored application environment needs the right resolution path before its private connections can work. Include that dependency in exercises rather than discovering it when the primary environment is unavailable.

The resulting acceptance record should identify client environments, expected answers, permitted operations and observed refusals. It belongs alongside the cloud control evidence used to approve the service. Private connectivity is defensible when the organisation can explain the complete path from application name to authorised data access.