Azure DNS becomes confusing when “the DNS server” is treated as one box that either knows a name or does not. In Azure, name resolution can involve public DNS zones, private DNS zones, VNet links, automatic registration, Azure-provided resolution, custom DNS servers, Private Resolver, conditional forwarding, Private Endpoints, and cached answers. The same FQDN can legitimately resolve differently depending on where the query originates.
For AZ-104, the best mental model is a query path. Start with the client. Ask which resolver it is configured to use. Ask which zone is authoritative for the name in that context. Ask whether the client’s network is linked to that private zone or forwarding queries toward a resolver that can reach it. Then ask what record is returned and whether the client can route to that address.
Imagine an application VM in a spoke VNet trying to reach db.internal.contoso.com. The record exists in an Azure Private DNS zone linked to the hub but not the spoke. The application reports “database unavailable.” Nothing is wrong with the database. The network path may be fine. The failure is that the query never reached a resolver with visibility into the private zone.
Public and private DNS zones answer different visibility questions
An Azure public DNS zone hosts records intended to be resolved through the public DNS hierarchy. A private DNS zone provides records that are visible through Azure private-resolution relationships rather than through the public internet. The record syntax can look identical, but the audience and resolution path are different.
The existing discussion of Azure DNS hosting architecture is useful background for authoritative zones. Private DNS adds another question: which virtual networks are allowed to use that zone as a resolution source?
That visibility is established with virtual network links. A VNet linked to a private zone can resolve records in the zone. Multiple VNets can be linked for resolution, allowing a centrally managed zone to serve workloads in several networks without copying records into each VNet.
Registration links and resolution links solve different problems
When a VNet is linked to a private DNS zone, auto registration can optionally be enabled. With auto registration, Azure creates A records for supported virtual machines in that VNet and updates them as those VMs are created, stopped, or removed. The VNet becomes a registration network for that zone.
A resolution-only link gives workloads in the VNet permission to query the zone but does not automatically create VM records there. This is useful when the zone contains centrally managed application records or when another network is responsible for registration.
The distinction matters because an administrator can create a link, confirm that resolution works, and still wonder why new VM names do not appear. Resolution and registration are separate behaviors. Microsoft also documents restrictions: auto registration is for VMs and does not automatically create records for every Azure resource type.
A VNet can resolve a private zone only if the query reaches the right resolver context
Azure-provided DNS can resolve private zones linked to the VNet. Problems often appear when the VNet uses custom DNS servers. The custom resolver now owns the first step of the query path. Unless it can answer the private zone itself or forward the query appropriately, the Azure private zone may never be consulted.
This is common in hybrid networks where domain controllers or enterprise DNS servers are configured as custom resolvers. Those servers may know corporate zones but not Azure private zones. Conditional forwarding creates a bridge by sending selected namespaces toward an Azure-capable resolver path.
Azure DNS Private Resolver provides managed inbound and outbound endpoints for these hybrid scenarios. An inbound endpoint can accept queries from connected networks for Azure private resolution, while an outbound endpoint and forwarding ruleset can send selected Azure queries toward on-premises or other DNS servers.
Private Endpoints make DNS architecture part of application connectivity
A Private Endpoint assigns a private IP to a service resource in a VNet, but applications usually continue using the service’s normal FQDN. DNS is what maps that familiar name to the private address in the networks that should use the private path.
If the private DNS integration is incomplete, the client may resolve the public service address and either bypass the intended private path or fail because public access has been disabled. This is why Private Endpoint troubleshooting should begin with the DNS answer before firewall or route-table changes.
Private-link DNS zones need to be designed carefully. Microsoft warns against casually overriding namespaces used by public endpoints without the correct forwarding behavior because unrelated names can stop resolving. The safest design follows the service-specific private DNS guidance and tests the FQDN from every required network.
Peering does not automatically make private DNS visibility universal
Network connectivity and DNS visibility are separate relationships. Two VNets can be peered and route packets successfully while only one is linked to the private DNS zone. The second VNet can reach the private IP if it knows it, but normal name resolution may still fail.
This separation becomes especially important in hub-and-spoke architectures. A central hub may host DNS resolver services, while spokes depend on forwarding and zone links. The design needs to state whether every spoke links directly to the zone, whether a resolver in the hub provides the answer, or whether another centralized model is used.
The broader hub-and-spoke network model helps explain the appeal of shared DNS services, but the resolution path still has to be explicit. A peering line on a diagram does not create a DNS forwarding rule.
Caching can preserve an old answer after the network design has already changed
DNS answers are cached according to time-to-live and resolver behavior. During a migration from a public endpoint to a Private Endpoint, some clients may continue using the public answer for a period even after the private record is correct. During rollback, the reverse can happen.
The existing explanations of DNS TTL and DNS caching are directly relevant to those cutovers. TTL is not only a performance setting; it influences how quickly a name-resolution change can become effective across clients and recursive resolvers.
Administrators should therefore distinguish “the zone contains the right record” from “this client is currently receiving the right answer.” Query the resolver the client actually uses, inspect the returned address, and account for caches before assuming propagation is complete.
Authoritative knowledge and recursive behavior should not be conflated
An authoritative DNS server owns the records for a zone. A recursive resolver takes a client’s query and finds the answer, possibly by consulting several authoritative sources or forwarding rules. Azure environments can contain both roles, and troubleshooting becomes much easier when they are separated conceptually.
A private zone can be perfectly configured while a recursive resolver never asks it. Conversely, the resolver can forward correctly while the zone lacks the record. Those are different faults and should produce different remediation.
The general explanation of recursive and iterative DNS queries helps anchor that distinction, even though Azure abstracts much of the public resolution sequence from administrators.
A disciplined DNS troubleshooting path follows one query from client to answer
Start at the failing workload. Confirm the configured DNS server. Query the exact FQDN and record type. Record the returned value. If the answer is wrong, determine which resolver provided it and which zone or forwarding rule it used. If there is no answer, test whether the relevant zone is linked or reachable through the intended resolver path.
If the answer is correct but the application still fails, DNS has done its job and the investigation should move to routing, security policy, service firewall, or the application itself. Keeping that boundary clear prevents administrators from repeatedly editing DNS when the packet is actually being blocked later.
For hybrid designs, test from Azure and on-premises separately. A query that works from a VM in a linked VNet proves only that context. It does not prove the on-premises DNS forwarder knows how to reach the private zone.
Negative answers can be cached as well, so a record that was missing during an early test can appear to remain missing after it has been created. During a migration, administrators should record which resolver produced the negative response, wait for or clear the relevant cache where appropriate, and retest from the original client context. This is another reason to capture the full query path instead of treating DNS propagation as a single global event.
Names also become operational contracts. Applications should use stable service FQDNs rather than embedding private IP addresses simply to avoid DNS troubleshooting. The private address can change when an endpoint is recreated, while the application name can remain stable and follow the new record. DNS is valuable precisely because it decouples service identity from one interface address.
DNS design should be documented as dependencies, not only as zone names
A production diagram should show which resolvers clients use, which private zones exist, which VNets are linked, where auto registration is enabled, where conditional forwarders point, and how on-premises queries reach Azure. For Private Endpoints, it should also show which service FQDN is expected to resolve to which private address.
Azure networking specialists will encounter the same hybrid resolution problems in AZ-700, while administrators encounter them directly when deploying private services and VNets. The overlap is useful because DNS is both an application dependency and a network control plane.
Within the Azure Administrator Associate path, the durable rule is to stop asking “Does Azure DNS work?” and instead ask “Which resolver should answer this name from this network, and why?” Once the query path is explicit, private DNS behavior stops looking mysterious and becomes a sequence that can be tested.
