The deployment looks tidy. There is a Private Endpoint, a private DNS zone, and a link to the workload’s VNet. Public network access is disabled.

Then someone asks how the application knows which IP to use.

That should not be a difficult question. In practice, the answer often stops at “the private zone is linked.” That is a resource configuration fact, not evidence of what the application resolved or where its request went.

Private connectivity changes the route. It does not make name resolution unimportant. For a workload that trusts a service hostname, DNS remains part of the decision about where that trust travels.

The Mental Model

A client normally asks for a service by name, not by drawing an arrow to a Private Endpoint NIC. DNS participates in turning that name into a destination. A private endpoint can be correctly provisioned while the client resolves through an unexpected resolver path, receives a stale answer, or reaches an address other than the one the design assumes.

There are three distinct claims here:

1. The intended DNS configuration exists.
2. The workload resolves the service name to the intended destination.
3. The request reaches and is authorized by the intended service.

Teams often establish the first claim, infer the second, and treat the third as solved because the answer was private. That is a lot of trust to place in one word.

A private DNS answer is evidence about name resolution. It is not a certificate of service identity or authorization.

How It Really Works

Follow the name the application actually uses

Begin with the service FQDN in the application’s configuration or request log. Do not start with an IP copied from a private endpoint resource. The question is how the real client resolves the name it actually requests.

For Azure Private Link, client applications can continue using the ordinary service hostname. DNS configuration can direct the query through the public CNAME chain and a private-link zone to a private address, depending on resolver context and zone configuration. Azure documents private DNS zones, VNet links, Azure Private Resolver, and forwarding patterns for private endpoint resolution.

The answer can differ across a VNet, a peered network, on-premises DNS, a container-specific resolver, and a developer workstation. A successful lookup from one vantage point is a result for that vantage point. It does not establish what a different resolver or cached client answer will do.

Configuration is not observed behaviour

Inspect the private endpoint’s DNS configuration and NIC addresses, the relevant private DNS zone and records, VNet links, and any custom resolver or forwarding rules. Then query from the workload’s actual execution context. Capture the question, resolver, full answer chain, TTL where available, timestamp, and address selected by the client.

That still leaves a second test: observe the destination used by the connection. A command-line DNS lookup is useful evidence, but the application may use a local cache, proxy, custom resolver library, or a long-lived connection. When practical, instrument the application’s request or test in the same process/container context. If that is not practical, state the gap rather than pretending a nearby VM is identical.

DNS does not replace the service checks

A DNS record does not grant access. Azure’s documentation is explicit that DNS resolution and access control are independent. The public CNAME chain may be resolvable even when a service denies the request, and a private address does not prove that the service accepted the intended identity or operation.

Test the remaining edges separately: connect to the resolved destination over the required protocol, then make a safe request with the workload’s intended identity. If the client reaches an unexpected address, investigate it. If it reaches the expected private IP but the service denies the operation, do not call DNS the failure merely because DNS was the most visible component.

The assumptions need to be visible

This article describes Azure Private Endpoint name resolution generally; a real implementation depends on the service’s supported private DNS zone name, endpoint subresource, resolver design, region, and service configuration. Record those for the environment under review. Do not mix records for multiple same-service private endpoints in one zone without verifying the supported design; Microsoft documents that some arrangements can remove an earlier A record and cause resolution failures.

There is no tested tenant result or specific Azure service instance in this example. If using Azure Private Resolver, identify the SKU/region and endpoint configuration. If relying on DNS logs or network telemetry, specify the source and schema. None is assumed here.

Real-World Impact

DNS failures are often treated as availability issues, and sometimes that is exactly what they are. A record disappears; the workload cannot resolve the service; the application fails. The security relevance is that the same dependency can influence which service the client attempts to reach, even when no route or application deployment changes.

Consider an application using the Storage Blob hostname account.blob.core.windows.net. In the intended private-link design, the resolver chain should lead the client to the private endpoint address for that account. One workload gets that answer. Another, using a different resolver path, gets a public address or an endpoint associated with another environment.

Those outcomes do not mean the second workload has accessed data. Public network access may be disabled; the service firewall, TLS validation, identity, and authorization still matter. But the intended private path was not proven. That distinction changes the incident response: investigate the resolver and client path before widening a firewall rule just to restore service.

This is why I would not use “resolves to RFC1918” as a success criterion. It says the answer is private address space. It does not say whose address it is, which service is listening there, or whether the intended service accepted the request.

Two remediation options can both look reasonable on a status board. Adding a broad network allow rule may make the application healthy again quickly. Correcting the zone link or forwarding path may take longer and require coordination with the DNS owner. If the failure is a wrong answer, the allow rule treats the symptom and expands the set of destinations the workload can reach. The right fix depends on observed DNS and connection evidence, not which team can close its ticket first.

Use a small resolution-to-destination record to support that decision:

This makes a resolver change reviewable. It also gives incident responders something better than a screenshot of a zone link taken months earlier.

For a bounded validation, compare the exact hostname’s answer from the workload context against the private endpoint NIC address and then observe the address used by a safe client request. The expected result is a match for the intended endpoint and an authorized service response. If the test differs, record whether the divergence is in the resolver answer, client-used destination, or service authorization. That is a test criterion, not a tenant result reported here.

For platform and security leaders, this record also exposes an ownership decision. If the workload team cannot change or independently validate the resolver path, then DNS is a shared security dependency, not just a central IT service. The platform owner needs a change process, a defined incident escalation route, and a way to establish which clients may be affected. If those controls are not available, the architecture review should record the dependency as accepted risk rather than calling the application network isolated.

Gotchas and Edge Cases

DNS is a small protocol sitting in the middle of a large operational system. The edge cases are usually not exotic; they are the normal consequences of shared ownership, caching, and migration.

A private zone can change public-name behaviour

Linking a private zone that matches a public service namespace can affect queries for names without private records. Microsoft warns that resolution may fail unless public fallback or forwarding is configured appropriately. Avoid overriding a zone actively used for public endpoint resolution without understanding how missing records behave.

Multiple endpoints can collide

Microsoft’s Private Endpoint DNS guidance warns that associating a Private DNS zone for a service with multiple similar Private Endpoints can remove an earlier A record and break resolution. The exact supported design depends on service and DNS architecture. Don’t copy a “one zone per environment” pattern blindly; verify the current service guidance and test each consumer path.

Caches hide the change window

Resolvers and clients cache answers. A record update does not guarantee every process switches destinations at the same moment. Do not describe a DNS change as an immediate cutover unless you tested the relevant TTLs and client behaviour. Long-lived connections can continue using the destination selected earlier.

Central DNS is an authority decision

Centralizing DNS can simplify operations and support hybrid resolution. It also concentrates the ability to influence name answers. That may be the right trade-off, but it belongs in the threat model and change-approval path. “Platform-owned” does not mean “outside the workload’s trust boundary.”

If the central team cannot tell which workload depends on a zone, it cannot confidently scope an emergency change. If the application team cannot see what the resolver returned, it cannot confidently distinguish a DNS issue from a service outage. Shared ownership without shared evidence is not a control model; it is a hand-off gap.

Best Practices

Review DNS and network reachability as one path, but keep their evidence distinct. Record the resolver and actual answer from the workload, then identify the address the application connected to. Validate the service operation independently with the intended identity.

When you change a zone, link, forwarder, or resolver endpoint, test both the expected private service and a representative name without a private record. That second test can catch a private-zone configuration that quietly breaks public resolution. Use a safe non-production workload where possible.

Give each shared DNS dependency an owner and an incident path. Decide who can change it, how changes are reviewed, and what telemetry can show what answer clients received. DNS telemetry may not exist or may not capture every client; say what the evidence covers.

Agree the response lane before an incident: a wrong resolver answer routes first to DNS ownership; an expected private answer with a failed connection routes to network and endpoint diagnostics; a successful connection with a denied service operation routes to identity/service authorization. Reclassify if the evidence contradicts the first hypothesis. This avoids the familiar cycle where teams widen access while arguing about which dashboard is authoritative.

Most importantly, don’t call a private IP a trusted destination. Confirm it belongs to the intended endpoint, confirm the connection uses it, and confirm the service authorizes the intended operation. Each of those checks closes a different gap.

Learn More

• Azure Private Endpoint private DNS zone values
• Azure Private Resolver overview
• Azure Private DNS overview
• Private Endpoint overview
• Authorize blob access with Microsoft Entra ID