Design Azure Private Endpoint DNS before the first private link

Source facts: the application name stays familiar while DNS changes its answer

Microsoft’s Private Endpoint DNS guidance says the endpoint network interface contains the private IP and fully qualified domain-name information needed for name resolution. Azure public DNS publishes a CNAME that redirects the ordinary service name toward a privatelink namespace. Inside the intended private network, DNS must override that chain with the endpoint’s private address so applications can continue using the normal connection URL.

Microsoft lists recommended private DNS zone names by Azure service and subresource. Automatic private DNS integration depends on using those recommended names. A private zone can be linked to virtual networks, while Azure DNS Private Resolver or a DNS-forwarder design can make linked private-zone answers available to on-premises or other connected clients.

The private namespace can also create a negative-answer trap. When a client queries a name for which the linked private zone has no record, the zone can return NXDOMAIN instead of continuing to the public answer. Microsoft documents an optional “fallback to internet” resolution policy on eligible Private Link zone VNet links. When enabled, Azure’s resolver retries public recursion after an authoritative NXDOMAIN. A static public A record in the private zone is not recommended because the service’s public address can change.

DNS and access control remain separate. A publicly resolvable CNAME does not reveal the private address or grant data-plane access, and disabling public network access can still reject a caller. Conversely, an endpoint marked Approved does not ensure the client received the private DNS answer or has a working route to it.

DSE recommendation: make DNS a required design artifact

For each private endpoint, document the public application FQDN, CNAME chain, Azure service and subresource, recommended private zone, expected A record, endpoint and VNet, every linked client VNet, hybrid resolver path, forwarding rule, public-access posture, owner, and recovery method. Treat this map as part of the application architecture, not a network-team attachment created after failure.

1. Define authority centrally. Decide which platform boundary owns each privatelink zone and record lifecycle. Reuse a governed zone for like service endpoints where the Microsoft guidance supports it; prevent application deployments from creating competing zones that different VNets see inconsistently.
2. Link only intended networks. Verify zone links against the client inventory and hub-spoke design. Remember that peering provides connectivity but does not automatically make a VNet authoritative for another VNet’s private zone.
3. Design hybrid forwarding. Point on-premises or multicloud DNS to an Azure DNS Private Resolver inbound endpoint or supported forwarder inside Azure. Do not point an external resolver directly at Azure’s platform virtual address, which is reachable only inside a VNet.
4. Choose fallback explicitly. Determine whether clients in a linked network must also reach public instances of the same Azure service namespace. If so, evaluate the documented NXDOMAIN fallback policy and its access implications. Avoid unmanaged duplicate public records.
5. Test from every boundary. Resolve the ordinary application FQDN from each VNet, on-premises site, VPN user path, build runner, and recovery network. Capture the complete CNAME chain and final IP, then test route, port, TLS name, service authorization, and the expected denial of public access.
6. Exercise lifecycle events. Test endpoint replacement, record deletion and recreation, zone-link change, resolver failure, regional recovery, cache expiry, and rollback. Monitoring should distinguish DNS failure, public-answer leakage, route failure, and service authorization.

Track endpoints without expected records, zones without owners, missing or excessive VNet links, NXDOMAIN and SERVFAIL trends, public answers where private is required, resolver health, and stale endpoint records. A sound design produces the right answer consistently and can explain why that answer changes by client location.

Official references

• Microsoft Learn, Azure Private Endpoint private DNS zone values, August 10, 2026.
• Microsoft Learn, Fallback to internet for Azure Private DNS zones.
• Microsoft Learn, Troubleshoot private endpoint DNS resolution failure in Azure Private Link.