Configuring Hybrid DNS Conditional Forwarders for Azure and AD

#Operational requirement

You are the engineer who inherits the hybrid DNS ticket queue the week workloads start moving into Azure. KBY Technologies runs Active Directory

That failure does not present as a single clean error. It presents as a wave of tickets: Hybrid Azure AD Join failing on some machines, Group Policy

Your task is to build a production forwarding path using Azure DNS Private Resolver on the Azure side and Windows conditional forwarders on-premises. This is the current Microsoft-recommended pattern. It replaces the older approach of running IaaS DNS forwarder VMs in Azure — technical debt you will still find in older client tenants, and something you should flag for retirement whenever you encounter it.

#Prerequisites and required permissions

Confirm every item below before you open a change record. Missing permissions mid-change is how a thirty-minute task turns into a half-day escalation.

• Azure RBAC: DNS Resolver Contributor and Network Contributor on the target subscription or resource group.
• An existing hub VNet with ExpressRoute or Site-to-Site VPN already established, with routing confirmed to the on-premises DNS server subnet (10.0.1.0/24 in this walkthrough).
• Two unused /28 subnets in the hub VNet reserved for the resolver’s inbound and outbound endpoints. These subnets cannot host any other resource — Azure rejects the delegation if the subnet already contains NICs.
• On-premises: membership of the DNS Admins group, or Domain Admins, on the Windows Server
  The KBY Lexicon

  Windows Server

  Windows Server is Microsoft's server operating system family, providing directory, network and application services as installable roles.

  Read Full Context
  DNS role holders — typically the domain controllers themselves.
• Firewall and NSG rules reviewed in advance: UDP and TCP port 53 must be permitted in both directions between the on-premises DNS subnet and the resolver subnet across the VPN or ExpressRoute path.
• A change record raised and approved in your ITSM tool before touching production DNS. DNS changes with no rollback plan are how outages become incidents.

#Step 1 — Deploy the Azure DNS Private Resolver and delegated subnets

Create the two dedicated subnets first. The resolver service refuses to attach to a subnet that has not been delegated correctly, and it fails without a helpful message if you skip this.

1az network vnet subnet create 
2  --resource-group rg-network-hub 
3  --vnet-name vnet-hub 
4  --name snet-dns-inbound 
5  --address-prefixes 10.10.4.0/28 
6  --delegations Microsoft.Network/dnsResolvers
7
8az network vnet subnet create 
9  --resource-group rg-network-hub 
10  --vnet-name vnet-hub 
11  --name snet-dns-outbound 
12  --address-prefixes 10.10.4.16/28 
13  --delegations Microsoft.Network/dnsResolvers
14
15az dns-resolver create 
16  --name dnspr-hub 
17  --resource-group rg-network-hub 
18  --location uksouth 
19  --virtual-network "/subscriptions/<sub-id>/resourceGroups/rg-network-hub/providers/Microsoft.Network/virtualNetworks/vnet-hub"

Keep the delegated subnets in place even after you roll back the resolver resource. Recreating delegated subnets under incident pressure is slower and riskier than leaving them provisioned but empty.

#Hands-on task

In a non-production subscription, deploy the resolver, create one forwarding rule for a test domain, and configure a conditional forwarder on a lab domain controller pointing at the inbound endpoint IP. Capture Resolve-DnsName output proving resolution succeeds in both directions, then execute the rollback sequence above and confirm the zones and rules are fully removed, with Get-DnsServerZone and az dns-resolver forwarding-rule list both returning empty results.

#Operational Summary

Hybrid DNS forwarding is not a one-off setup task. It is production infrastructure and needs the same change control, monitoring and rollback discipline you would apply to a firewall rule or a routing table change. Azure DNS Private Resolver replaces the older self-managed forwarder VM pattern and removes a whole category of patching and availability debt, but it still depends entirely on correct NSG rules, correct subnet delegation and correctly terminated domain names in the forwarding rule. Test resolution from both sides of the link before you close any change record, retain the Log Analytics query evidence, and never delete the resolver resource before removing the dependent rulesets and on-premises forwarder zones in the documented order. Get this wrong once during onboarding and you will remember the trailing dot for the rest of your career; get it right and hybrid name resolution stops being a source of unexplained tickets and becomes just another line item on the monitoring dashboard.