Cloud Foundation

Private Endpoints at Scale: Make Azure DNS Part of the Network Design

Design private DNS zones, resolver paths and ownership alongside Azure Private Endpoints so workloads resolve services consistently across cloud and hybrid networks.

An Azure Private Endpoint gives a service a private network interface in a virtual network. That does not by itself ensure that applications use the private address. Clients still need to resolve the service name to the endpoint’s private IP address through a DNS path that reaches the right private zone.

At small scale, a manually linked zone can appear to solve the problem. As endpoints spread across subscriptions, virtual networks and on-premises networks, inconsistent zone ownership and forwarding rules can create intermittent failures, unexpected public resolution or hard-to-trace dependencies. Treat DNS as part of the cloud foundation and design it with network connectivity, workload onboarding and operations.

Trace the name-resolution path

A private endpoint depends on a complete DNS path
  1. Workload queryThe application requests the service’s private DNS name.
  2. Resolver pathThe VNet resolver or configured forwarder sends the query to the right DNS service.
  3. Private zoneThe linked private DNS zone returns the endpoint’s private address.
  4. Private endpointTraffic reaches the service through the approved private network path.
  5. Operate the zoneAssign ownership, monitor records and test resolution from each connected network.

Before deploying an endpoint, write down where the client runs, which DNS server it queries, where that server forwards the request and which zone contains the endpoint record. Confirm that every link in the path works for the intended client network. A private endpoint is useful only when the application resolves its service name to the endpoint’s private address from the places that should use it.

Use the service’s documented private DNS zone name and record behavior. Azure services can have different endpoint subresources and DNS names, so a generic zone or a hand-written record may not cover the actual connection. Keep the application’s normal service hostname where possible; DNS should direct the supported name to the private address rather than requiring application code to know the endpoint IP.

Choose who owns shared private zones

Decide whether private DNS zones are centrally managed or created with each workload. A central model can provide consistent name resolution across many landing zones, but it needs clear ownership for zone links, record changes and troubleshooting. A workload-owned model can improve autonomy, but only if duplicate zones and disconnected links do not divide resolution across environments.

For a shared zone, document which subscription owns it, which networks are linked, and who can add or remove links. Coordinate endpoint lifecycle with DNS record lifecycle so that deleting or replacing an endpoint does not leave stale records or remove records still used by another environment. Keep environments isolated where their names or trust boundaries should differ.

Connect Azure and on-premises DNS deliberately

Azure virtual networks using custom DNS servers need a forwarding path to resolve Azure private zones. For hybrid networks, Azure DNS Private Resolver can provide managed inbound and outbound endpoints: on-premises DNS can forward relevant queries to an inbound endpoint, and Azure workloads can forward selected queries to on-premises DNS through an outbound endpoint and ruleset.

Plan the resolver subnets, routes, firewall rules and conditional forwarding together. Resolver endpoints require dedicated subnets, and the network path to those endpoints must be available from the clients and DNS servers that use them. Avoid assuming that a virtual network link alone makes a zone resolvable from every connected network; test the full query path from each client location.

Make DNS changes observable and repeatable

Store zone definitions, virtual network links, resolver endpoints and forwarding rules in the same reviewed infrastructure workflow as the network foundation. Give the platform team ownership of shared DNS components and give workload teams a documented request or onboarding path for endpoint records and network links.

Test resolution from representative locations after deployment and after changes to private endpoints, zones, links or forwarding rules. Check both the returned address and the application connection. A successful lookup from an Azure virtual machine does not prove that an on-premises client, another landing zone or a build agent follows the same path.

Useful operational signals include failed lookups, stale or duplicate records, unexpected public answers, and changes to zone links or resolver rules. Keep a record of the expected zone and forwarding path for each workload so incident responders can distinguish a DNS issue from a route, firewall or service problem.

A practical private DNS design sequence

  1. List the client networks, service hostnames, endpoint subresources and required private zones.
  2. Select central or workload ownership for each zone and document its subscription and maintainers.
  3. Design virtual network links and hybrid forwarding paths, including dedicated resolver subnets where needed.
  4. Define how endpoint creation, replacement and deletion update DNS records safely.
  5. Automate zone, link and resolver changes through reviewed infrastructure code.
  6. Validate private answers and application connectivity from every relevant client network.

Private connectivity depends on predictable name resolution. When the DNS path is designed, owned and tested as part of the foundation, private endpoints can be onboarded consistently without making each workload team rediscover the network architecture.

Watch for overlapping zones and stale records

Private DNS design must account for the exact service zone and the set of networks linked to it. A private zone linked to a virtual network can change how names in that zone resolve there; a missing record is not automatically answered by a public DNS lookup in every configuration. Avoid creating duplicate private zones for the same namespace across connected networks unless their record ownership and forwarding behavior are deliberate. Where a service supports private DNS zone groups, use their lifecycle integration or an equivalent reviewed automation so endpoint replacement and deletion do not leave stale records. Test resolution from each client path after those changes.

Continue reading

References