Diagnose Azure Private Endpoint DNS and connectivity

Understand the likely causes

• Likely causes include an incorrect private DNS zone or record, a missing VNet link, a custom resolver path that bypasses the zone, an unapproved connection, or a separate network or service-authorization failure. A private-looking IP is useful evidence only when it matches the intended endpoint.

Define the failing client and service endpoint

Record the workload network, resolver configuration, service FQDN, target subresource and time. A laptop outside the private network and a workload inside it may intentionally receive different answers. Preserve the original service hostname so TLS and application settings remain meaningful. In a public-Azure Blob example, the private-link DNS namespace differs from the ordinary service hostname; other services and sovereign clouds use their documented mappings.

Match approval and DNS records to the actual endpoint

Confirm the intended private endpoint, its target service connection, approval state and assigned private IP. Then compare the query result from the failing client with the endpoint interface information. A stale private IP can point at the wrong destination even though it belongs to a private range. The offline example below compares invented observations with a declared expected value. It performs no lookup and proves nothing about a real network; it demonstrates why matching the actual endpoint is more precise than classifying every private address as correct.

expected = "10.20.0.5"
answers = {
    "workload": "198.51.100.20",
    "approved-test-client": "10.20.0.5",
}
for client, address in answers.items():
    result = "match" if address == expected else "mismatch"
    print(f"{client}: {result}")

workload: mismatch
approved-test-client: match

Trace the resolver and private-zone path

Inspect the appropriate private DNS zone, record and VNet link for the workload location. When custom DNS or on-premises resolvers are involved, trace the documented forwarding design through the approved Azure DNS or Private Resolver architecture. A VPN connection by itself does not supply correct DNS forwarding. Avoid creating a broad authoritative zone that accidentally hides unrelated service names. If other resources in the same namespace stop resolving, investigate that namespace boundary and missing records rather than repeatedly replacing the failing application hostname.

Separate name resolution from network and service access

Once the answer matches the intended private endpoint, inspect the required routes, applicable subnet network policies and approved network-security controls. A valid DNS answer does not prove that TCP, TLS or the service request succeeds. Conversely, a service authorization error after a completed connection can require a data-access investigation rather than a routing change. Keep the error stage and evidence together. Use the normal service hostname and supported connection settings; replacing a hostname with a raw IP can introduce certificate or service-routing errors that obscure the original fault.

Correct one dependency and preserve the privacy boundary

Choose a correction that follows the approved design: the right record, VNet link, forwarding path or endpoint approval. Record the previous state, owner, expected effect and rollback. Do not reopen a public endpoint merely to turn a private-path failure into a superficial success. Review shared DNS changes with the other consumers of that namespace. The diagnostic note below records evidence and a hypothesis, not a deployable configuration. Retest from the original client and verify that the intended public-access restrictions remain effective.

{
  "case": "fictional private Blob access",
  "expectedPrivateAddress": "10.20.0.5",
  "observedAddress": "198.51.100.20",
  "hypothesis": "the workload resolver does not consult the intended private zone",
  "review": "check zone link and approved forwarding path before changing access"
}

Keep it from recurring

• Keep endpoint, zone, VNet-link and forwarding ownership documented together. Test the intended client locations and important negative paths whenever endpoint or resolver configuration changes.