Private DNS Zones in hub and spoke

Azure Private DNS Zones quickly become a structural layer in a hub and spoke architecture. At first, they may look like a secondary component. A zone contains private records. It is linked to one or more virtual networks. Resources located in those VNets can resolve the names contained in the zone. For a first Private Endpoint, a storage account, or a small set of virtual machines, that mechanism remains easy to understand.

The situation changes as the architecture grows. An Azure landing zone can contain a network hub, several application spokes, multiple subscriptions, separate environments, hybrid connectivity, internal DNS services, and teams that do not all move at the same pace. In that context, the question is no longer only how to create a private zone. The real design work is to decide where it lives, who owns it, which VNets are linked to it, how records are populated, which resolvers are used, and how to prevent every project from building its own variant of private DNS.

A poorly organized private zone does not always break an application immediately. That is what makes the issue dangerous. Initial tests may work, then a network migration, a move to custom DNS, a new Private Endpoint, or an additional spoke reveals that the resolution path was relying on a fragile assumption. The portal shows that the zone exists. The VNet link looks present. The Private Endpoint has a private address. Yet the workload still resolves a public name, receives the wrong address, or fails from a hybrid environment.

Treat private zones as a platform component

The healthiest model is to treat Private DNS Zones as a platform component, not as an application resource created along the way. This does not mean that all zones must necessarily live in the same resource group or subscription. It means that they follow a common convention, appear in the architecture model, and are not left to isolated workload decisions.

Zones associated with Private Endpoints must use the names expected by Azure. A storage account, a Key Vault, a Container Registry, or another service exposed through Private Link will not resolve cleanly through a locally invented zone. The private name must replace public resolution at the right point without breaking other service usages. Internal enterprise zones must also remain separate from privatelink zones, because they do not serve the same purpose. A private zone used for internal company resources does not have the same governance model as an Azure zone populated by Private Endpoints.

In a hub and spoke architecture, the hub generally hosts shared services. It concentrates connectivity, firewalls, resolvers, routes, sometimes bastions, and administration tooling. Private DNS Zones can follow the same logic. They then become part of the network platform, with an owning team, a naming convention, link rules, and a diagnostic strategy.

The risk is to let every spoke create its own private zones. This approach looks fast for a project team because it fixes resolution locally for its Private Endpoint. But it multiplies duplicates and inconsistent behavior. Two zones with the same name can exist in two different subscriptions. One spoke may resolve a service correctly while another uses a different path. Teams eventually diagnose DNS incidents as if they were application issues.

Understand what VNet links really do

A link between a Private DNS Zone and a VNet makes the zone records available from that VNet, provided that the resolution path actually uses the expected Azure mechanism. This point is often underestimated. The link is not a universal DNS tunnel. It does not force all clients in the VNet to query the zone. It makes the zone available to the resolution model associated with the VNet.

When the VNet uses Azure-provided DNS, resolution is usually direct. Private zones linked to the VNet are taken into account, then resolution continues through Azure DNS if needed. In a simple environment, this behavior explains why a Private Endpoint can work shortly after the proper DNS link is created.

The reasoning changes as soon as the VNet uses custom DNS. In many enterprise environments, that is the normal state. Machines point to domain controllers, DNS appliances, security forwarders, or centralized DNS servers. From that point on, the machine no longer directly queries the Azure default path. It sends queries to the configured DNS server. If that server does not know how to forward Azure private domains to the right resolver, the zone can be perfectly configured and still remain invisible to the workload.

This is a frequent source of incidents. A team checks the Private Endpoint. It exists. They check the private zone. It exists. They check the VNet link. It exists. But the VM or container queries an internal DNS server that has no rule for privatelink.blob.core.windows.net, privatelink.vaultcore.azure.net, or another private suffix. The problem is not the zone. The problem is the resolution path.

Workload in a spoke
DNS query sent to the resolver configured on the VNet
  If Azure-provided DNS is used
    Private DNS Zones linked to the VNet are queried
  If custom DNS is used
    The custom DNS service must forward the private suffix to the right resolver

Private DNS Zone
Contains private records
Becomes useful only if the DNS path reaches it

This distinction must appear in the design. A private DNS architecture is not just a list of zones and links. It must describe the exact path of a query from the workload to the final record. Without that view, DNS remains difficult to operate and incidents repeat.

Centralized hub or distributed links

Two models often appear in Azure architectures. The first is to link private zones directly to the spokes that consume the services. The second is to centralize resolution in a hub, with Azure DNS Private Resolver or DNS forwarders, then route queries toward that central point.

Direct linking is easy to understand. A spoke that consumes a service receives a link to the corresponding zone. If the spoke uses Azure-provided DNS, resolution works without many additional components. This model can be acceptable for limited environments, or for isolated workloads without custom DNS.

It becomes less comfortable when the number of spokes grows. Each zone must be linked to several VNets. Modification rights become sensitive. Teams may add links to fix a one-off incident and then forget them. A zone eventually becomes linked to VNets that do not need it. Private resolution becomes too broad, which reduces readability and complicates segmentation.

The centralized model is more demanding, but more robust for a platform. Private zones live under the network or platform responsibility. The hub hosts a resolver. Internal DNS services or spokes send the relevant suffixes to the hub. Forwarding rules become the control point. The goal is no longer to link every zone to every VNet. The goal is to decide which suffixes are resolved through which path.

Azure DNS Private Resolver fits this model. The inbound endpoint receives queries from other networks, for example from on premises environments or from internal DNS services. The outbound endpoint allows the resolver to use forwarding rules toward other DNS servers for specific suffixes. Rulesets define the forwarded suffixes and can be linked to VNets that need them. The hub then becomes the articulation point for private resolution.

Connectivity hub
Platform Private DNS Zones
Azure DNS Private Resolver
Inbound endpoint for incoming queries
Outbound endpoint for forwarding rules
Rulesets associated with private and hybrid suffixes

Application spokes
Consume only the required suffixes
Do not create local private zones without convention
Use the DNS path defined by the platform

Hybrid environment
Forwards Azure private suffixes to the inbound endpoint
May receive some internal suffixes from Azure
Documents responsibilities between internal DNS and Azure DNS

The choice between these models depends on the size of the environment, the expected level of centralization, and the presence of custom DNS. For Naxaya, the important point is less to defend one unique model than to make the chosen model explainable. A private DNS design must allow a simple question to be answered quickly: if a machine in this spoke queries this FQDN, which DNS server receives the query, which rule applies, and which zone provides the record?

Avoid the reflex of linking everything everywhere

When a DNS incident occurs, the temptation is often to add a VNet link or broaden a rule. This can restore a service quickly, but it leaves operational debt. If all zones are linked to all VNets, resolution sometimes works because it is permissive, not because it was designed.

This model is difficult to audit. An application spoke can resolve private names that have nothing to do with its scope. A team may believe a service is isolated while its private name can be resolved from other segments. DNS is not an access control by itself, but it contributes to the understanding of the private surface. Overly broad resolution blurs that understanding.

A cleaner approach is to define consumption profiles. A standard application spoke needs a limited number of zones. An administration spoke may have a broader profile. A data spoke may consume zones related to storage, databases, and secret services. An isolated environment may receive only the strictly required zones. This logic forces needs to be documented instead of adding links by reflex.

It also helps with permissions. Application teams do not always need to modify private zones. They need to request a Private Endpoint, verify the result, and test resolution. Zone creation, VNet linking, and naming convention can remain with the platform. This reduces configuration errors and prevents orphaned zones.

Manage records and lifecycle

Records are as important as zones. For Private Endpoints, DNS integration should follow the endpoint lifecycle as much as possible. When the resource is created, the private record should appear in the right zone. When the endpoint is removed, the record should not remain as a dead trace.

Manual records must remain exceptions. They can be useful for a transition, a migration, a test, or a particular integration. But if they become the norm, the zone loses reliability. A private address can change. An endpoint can be recreated. A resource can be moved. A manually maintained record can keep answering for months even though the real service no longer exists or no longer sits at the same address.

This problem often appears during migrations. A team moves a service to Private Link, adds a record to restore resolution, then never revisits the decision. A few months later, another project creates an endpoint of the same type. The zone already contains names, some automatic, some manual, and nobody knows which are still required.

Good operations therefore require regular zone review. It must be possible to associate a record with a resource, a Private Endpoint, a team, or a documented decision. When that link does not exist, the record becomes suspicious. Private DNS must remain a living inventory, not an accumulation of exceptions.

Hybrid DNS and shared responsibility

Hybrid environments often reveal the limits of the initial design. As long as workloads are only in Azure and use Azure-provided DNS, resolution can remain fairly simple. As soon as a datacenter, an industrial network, an Active Directory domain, or an external platform must resolve Azure private names, forwarding must be designed explicitly.

The internal DNS service must know which suffixes to send to Azure. Azure may also need to know which suffixes to send back to internal DNS. Rules must be precise. Forwarding a domain that is too broad can produce side effects. Forwarding a domain that is too narrow can leave some services outside the expected path. privatelink suffixes must be treated carefully because they correspond to specific Azure services and must follow the service naming model.

The most important operational point is responsibility. If a query starts from an on premises server and fails, who diagnoses it? The internal network team sees a query leaving toward Azure. The Azure team sees a resolver that receives or does not receive the query. The application team only sees a timeout. Without clear responsibility, DNS becomes a shared subject without a real owner.

In a clean architecture, the hybrid resolution path must be documented with endpoint addresses, forwarded suffixes, associated VNets, rulesets, and expected tests. It is not enough to say that hybrid DNS is configured. It must be possible to prove from both sides that the correct path is being used.

Test DNS as an application dependency

Private DNS must be tested as an application dependency. An application that uses a private storage account, Key Vault, or database depends on name resolution as much as on network connectivity. Testing only the port or the route is not enough if the name resolves to the wrong address.

Tests must start from the real locations. A test VM in the hub does not prove that the application spoke works. A test from an administration workstation does not prove that a container in an isolated subnet uses the right resolver. Each spoke profile should have at least one simple verification scenario.

# From a machine located in the spoke to validate
nslookup myaccount.blob.core.windows.net
nslookup myvault.vault.azure.net

# Check the resolver path explicitly
nslookup myaccount.blob.core.windows.net 168.63.129.16

# Compare with the DNS configuration on the system
cat /etc/resolv.conf
systemd-resolve --status 2>/dev/null || resolvectl status

The expected result is not only a DNS response. The returned address must be a private address consistent with the expected Private Endpoint. The canonical name and resolution chain must also match the service. A test that returns a public address can go unnoticed if the application still has Internet egress. The risk is then to believe that the Private Endpoint is being used while traffic is still leaving through another path.

For Windows environments, the same principle applies with nslookup, Resolve-DnsName, and the DNS servers configured on the interface. The important point is to test from the right network zone, through the same path as the workload.

Resolve-DnsName myaccount.blob.core.windows.net
Resolve-DnsName myvault.vault.azure.net
Get-DnsClientServerAddress

# Explicit test against a given resolver
Resolve-DnsName myaccount.blob.core.windows.net -Server 168.63.129.16

These tests should be part of deployment. A Terraform, Bicep, or Ansible pipeline that creates a Private Endpoint should ideally produce a resolution check as well. Otherwise, the deployment can be technically successful but unusable for the workload.

Common mistakes

The first mistake is to create a private zone with an approximate name. For Azure services exposed through Private Endpoint, the expected zone name depends on the service. A wrongly named zone can contain records, but fail to intercept the resolution path expected by the client.

The second mistake is to forget custom DNS. Many incidents come from that point. The VNet link exists, but the client queries an internal DNS service that does not forward the private suffix. Diagnosis then goes in the wrong direction because everything looks correct in Azure.

The third mistake is to create duplicate zones across several subscriptions. In the short term, every team thinks it saves time. In the medium term, the environment becomes inconsistent. Two zones with the same name can contain different records. The result depends on the VNet, the resolver, or the rule that is used.

The fourth mistake is to mix responsibilities. One application team creates the Private Endpoint, one network team creates the DNS link, one identity team manages internal DNS, and nobody owns the end-to-end path. This model works until there is an incident. When a problem appears, each team validates its own piece without seeing the whole chain.

The fifth mistake is to use DNS as a quick fix. Adding a manual record can unblock a situation, but the decision must then be brought back into an automated or documented model. Otherwise, the zone gradually becomes a stock of exceptions.

A simpler operating model

To keep the architecture readable, implicit decisions must be reduced. Platform private zones need a known location. VNet links must match consumption profiles. Forwarded suffixes must be documented. Manual records must remain exceptional. Resolution tests must be executed from the actual networks concerned.

A simple convention is often enough. It must answer a few questions: where does the zone live, who can modify it, which VNets can consume it, which resolver is used, how is a new Private Endpoint added, how is a record removed, and how does a team prove that resolution works?

Platform decision
privatelink zones are centralized or created under a documented convention
VNet links follow consumption profiles
Custom DNS must forward private suffixes to the expected resolver

Application decision
Private resolution needs are declared with the Private Endpoint
Tests are executed from the consuming spoke
Manual DNS exceptions remain limited and documented

Operations decision
Zones are reviewed regularly
Orphaned records are cleaned up
The DNS path is known before the incident

This approach prevents Private DNS Zones from becoming an invisible subject. Private DNS becomes an explicit part of the network architecture. It is no longer created only to satisfy an Azure configuration wizard, but operated as a central workload dependency.

Conclusion

Private DNS Zones in hub and spoke are not an implementation detail. They form an architecture layer that conditions the real usage of Private Endpoints and the consistency of a private platform. A correct model is not limited to creating the expected zones. It describes the resolution path, the role of custom DNS, the required links, forwarding rules, and operational responsibilities.

In an existing Azure architecture, the useful question remains very concrete: when a workload queries the name of a private service, which resolver receives the query, which rule applies, which zone answers, and which address is returned? If that chain can be explained and tested simply, the DNS model is operable. If it depends on random links, manual records, or undocumented forwarders, private DNS becomes a recurring source of incidents.