Context
Azure DNS Private Resolver connects name-resolution paths between Azure and other private networks. Its inbound endpoint receives queries into Azure. Its outbound endpoint and rules send matching queries toward other DNS servers. Configuring both directions without tracing the full path can send a query back to its starting point.
Prerequisites are a failing fully qualified name, the client network and configured DNS servers, and read access to endpoints, private zone links and rulesets. Capture a working name from the same client as a comparison. Use authorized diagnostic hosts on each side of the hybrid connection.
1. Trace the first resolver decision
Run a lookup from the failing client and record the DNS server that answers or times out. Query the corporate DNS server explicitly, then query the Azure inbound endpoint explicitly where access permits. A direct inbound answer with failure through the default resolver narrows the issue to forwarding.
Record the complete suffix. Conditional forwarders match namespaces, so a typo or overly broad parent suffix can affect unrelated records. Include both UDP and TCP port 53 reachability in the network review. Large responses and fallback behavior can expose a transport rule missed by a small successful lookup.
2. List every matching forward
Record the corporate conditional forwarder, inbound endpoint VNet, private zone links and any ruleset linked to that VNet. Then inspect ruleset links for the client spoke. Mark the target DNS server for each rule matching the failing suffix, including broader fallback rules.
A rule forwarding to an inbound endpoint can loop when its ruleset is linked to that same endpoint's VNet. Microsoft explicitly warns against this topology. Another loop can span systems: corporate DNS forwards a namespace into Azure, while Azure forwards it back to corporate DNS. Each rule looks reasonable without the opposite side's configuration.
3. Correct namespace ownership
Identify the authoritative system for each private namespace and the networks that require access. Correct the particular rule or link sending queries back to an already visited resolver. Preserve valid forwarding for other suffixes. Treat a catch-all rule carefully because its effect extends beyond the failing application.
For a hub-and-spoke design, determine whether spokes use ruleset links or custom DNS pointing at an inbound endpoint. Both require deliberate zone visibility. Do not combine instructions from both designs without evaluating the resulting query path. Review the change against a small set of corporate and Azure names before deployment.
Diagnostic checkpoints
| Observation | Suspected boundary | Next evidence |
|---|---|---|
| Direct inbound query works | Upstream forwarding | Corporate forwarder |
| One suffix repeatedly times out | Loop or wrong target | Rules on both sides |
| Hub works, spoke fails | Different visibility | Spoke DNS and links |
| Response size changes behavior | Transport handling | UDP and TCP checks |
Illustrative scenario
A hypothetical spoke ruleset forwards an application zone to a hub inbound endpoint. Someone also links that ruleset to the hub itself. Queries can return to the inbound endpoint instead of resolving normally. The review identifies this unintended relationship while preserving forwarding for corporate names. The example describes a possible topology, not a real incident.
Verification and DNS SOP
Test from each affected network using explicit and default resolvers. Allow relevant caches to expire or use the approved cache procedure. Verify expected answers and an application connection; DNS success alone does not demonstrate network reachability.
Maintain namespace ownership, forwarding targets and VNet links in the SOP. Monitor resolver failures and review DNS paths during network onboarding. Require reviewers to trace each new broad suffix through the opposite system's rules, so loops are found before application clients encounter them.
Explore Clouvenix cloud architecture for implementation and operational handover.