DNS Private Resolver handles both directions of hybrid resolution: inbound endpoints receive queries from on-premises, and outbound endpoints with forwarding rulesets send queries out. Figure 2.1 shows both directions, with the inbound endpoint on the way in and the outbound endpoint and ruleset on the way out.
Endpoints and subnet sizing
- Inbound and outbound endpoints each need a dedicated subnet of at least /28, delegated to
Microsoft.Network/dnsResolvers(subnet delegation). A VNet that only uses the resolver through a ruleset link or peering needs no extra address space. - An inbound endpoint is an IP address in the VNet that on-premises DNS targets; it resolves against the private zones linked to its VNet. An outbound endpoint only sends queries out and can’t be a rule destination.
Common trap: Sizing resolver endpoint subnets as /24 or /25 - /28 is the minimum, and a spoke VNet that uses the resolver only through a ruleset link needs no resolver subnet at all.
Forwarding rulesets
- DNS forwarding ruleset destinations: an Azure private zone namespace goes to the inbound endpoint’s IP; an on-premises namespace goes to the on-premises DNS server’s IP. 168.63.129.16 isn’t a permitted destination.
Common trap: Forwarding the Azure private zone to 168.63.129.16 in a ruleset - it isn’t a permitted destination; forward to the inbound endpoint’s IP instead.
Regional scope and resolver count
- An Azure DNS Private Resolver references only a VNet in its own region, and a ruleset links only to VNets in its own region.
- VNets in two regions that must resolve an on-premises zone need a ruleset in each region, and therefore a resolver with an outbound endpoint in each region: two resolvers minimum. Add an inbound endpoint to one of them for on-premises resolution of Azure zones; no third resolver is needed.