10.3 DNS Forwarding, Conditional Forwarding & Azure DNS Zone Integration
Key Takeaways
- A standard forwarder sends every unresolved query to a fixed upstream resolver, while a conditional forwarder routes only queries for a named domain suffix to a specific server.
- Forwarders are tried in list order with a configurable timeout per entry, and root hints are used only if the forwarder list is exhausted and Use root hints is left enabled.
- Storing a conditional forwarder in Active Directory replicates it to every DNS server in the domain or forest at once, which is the low-effort way to configure many domain controllers identically.
- Azure Public DNS hosts internet-facing zones and is authoritative for records queried from anywhere, so Windows Server DNS integrates with it by delegation or by an ordinary conditional forwarder to public resolvers.
- Azure Private DNS zones are resolvable only from within linked virtual networks via the platform resolver at 168.63.129.16, which is not reachable across ExpressRoute or VPN.
DNS Forwarding, Conditional Forwarding & Azure DNS Zone Integration
Enterprise cloud adoption requires seamless, bi-directional name resolution across hybrid cloud topologies. Workloads residing in Microsoft Azure Virtual Networks (VNets) must resolve on-premises Active Directory resources (such as domain controllers, database servers, and internal web portals), while on-premises client workstations and servers must resolve Azure IaaS virtual machines and Azure PaaS services utilizing Azure Private Endpoints (privatelink zones). This section covers the forwarding layer that bridges those ecosystems: standard forwarders versus root hints, conditional forwarders and how they replicate in Active Directory, Azure Private DNS zones with their virtual network links, and integration with Azure Public DNS. The Azure DNS Private Resolver PaaS service, with its inbound and outbound endpoints and rule sets, is covered in section 10.4.
1. Standard DNS Forwarders vs. Root Hints
When a Windows DNS server receives a query for a namespace for which it is not authoritative (and does not hold in its local cache), it must use either Root Hints or Forwarders to resolve the query:
+-----------------------------------------------------------------------------+
| ROOT HINTS VS FORWARDERS |
| |
| [ROOT HINTS (Iterative Recursion)] [FORWARDERS (Designated Upstream]|
| - Contains list of 13 Root Servers - Forwards query to upstream DNS |
| (a.root-servers.net to m...) (e.g., 1.1.1.1, ISP, Perimeter)|
| - Server performs full iterative walk: - Upstream resolver handles the |
| Root (.) -> TLD (.com) -> Auth recursive burden & caching |
| - Slower initial response time - Faster, centralized caching |
+-----------------------------------------------------------------------------+
Forwarder Behavior & Failover Mechanics:
- When a forwarder is configured on Windows Server, the DNS server transmits recursive queries to the forwarder's IP address and waits for a response (timeout default is 3 to 5 seconds).
- If the designated forwarders fail to respond, the DNS server will fall back to using its Root Hints to perform iterative root-level recursion, unless the administrator explicitly disables the
Use root hints if no forwarders are availablecheckbox (-EnableRootHints $false).
2. Conditional Forwarders & Active Directory Replication
A Conditional Forwarder instructs a DNS server to forward queries to specific upstream IP addresses based exclusively on the domain suffix of the query.
+-----------------------------------------------------------------------------+
| CONDITIONAL FORWARDING LOGIC FLOW |
| |
| Incoming Query: "sql01.partner.fabrikam.com" |
| | |
| v |
| Does local server hold authoritative zone? ---> NO |
| | |
| v |
| Does query match a Conditional Forwarder? |
| +---------------------------------------------------------------------+ |
| | Domain Name: "fabrikam.com" | |
| | Target Master IPs: 192.168.50.10, 192.168.50.11 | |
| +---------------------------------------------------------------------+ |
| | |
| v (YES) |
| Forward query directly to 192.168.50.10 (Bypasses Root Hints & Standard) |
+-----------------------------------------------------------------------------+
Active Directory Integration for Conditional Forwarders:
Traditional conditional forwarders are stored in local server registry or text files, requiring manual configuration on every domain controller. Storing conditional forwarders in Active Directory (Add-DnsServerConditionalForwarderZone -ReplicationScope Forest / Domain) replicates the conditional forwarding rule automatically across all domain controllers in the domain or forest, ensuring consistent name resolution across the enterprise.
# PowerShell: Creating an AD-Integrated Conditional Forwarder for a Partner Forest
Add-DnsServerConditionalForwarderZone `
-Name 'fabrikam.com' `
-MasterServers @('192.168.50.10', '192.168.50.11') `
-ReplicationScope 'Forest' `
-ForwarderTimeout 3
3. Azure Private DNS Zones & Virtual Network Links
Azure Private DNS Zones provide a secure, reliable DNS service for virtual networks to manage and resolve domain names without requiring custom DNS infrastructure.
+-----------------------------------------------------------------------------+
| AZURE PRIVATE DNS ZONE ARCHITECTURE |
| |
| [Azure Private DNS Zone: corp.internal / privatelink.blob.core.windows.net]|
| | |
| +----------------------------+----------------------------+ |
| | (Resolution Link) | (Registration Link) |
| v v |
| +--------------------------+ +-------------+ |
| | VNet-Spoke01 | | VNet-Dev | |
| | - VMs can resolve records| | - VMs auto- | |
| | - No auto-registration | | register | |
| +--------------------------+ +-------------+ |
+-----------------------------------------------------------------------------+
Virtual Network Link Types:
- Resolution Virtual Network Link: Allows VMs residing in the linked VNet to resolve records hosted in the Private DNS zone. A Private DNS zone supports up to 1,000 resolution links across different VNets and subscriptions.
- Registration Virtual Network Link: Automatically registers the hostname and private IP address of VMs deployed within the linked VNet into the Private DNS zone as A records. The restriction runs the opposite way from the one candidates usually assume: a Private DNS zone can have multiple registration virtual networks, but every virtual network can have only one registration zone. Microsoft states this directly — "A specific virtual network can be linked to only one private DNS zone when automatic registration is enabled. You can, however, link multiple virtual networks to a single DNS zone."
[!NOTE] Auto-registration has three further limits worth memorising: it creates records for virtual machines only (internal load balancers and other resources need manual records), only for the VM's primary NIC, and it never creates reverse-lookup PTR records. Records appear when a VM starts and are removed when it is stopped and deallocated.
4. Integrating Windows Server DNS With Azure Public DNS
Azure hosts two entirely separate zone services, and AZ-800 expects you to keep them straight.
| Azure Public DNS (public zone) | Azure Private DNS (private zone) | |
|---|---|---|
| Answers queries from | Anywhere on the internet | Only virtual networks linked to the zone |
| Authoritative for | Internet-facing names such as contoso.com | Internal names such as corp.internal |
| Resolver used | Azure's global anycast name servers | The platform resolver at 168.63.129.16 |
| Reachable from on-premises | Yes, by any recursive resolver | No, without a bridge such as Azure DNS Private Resolver |
| Registrar delegation | Required (NS records at the registrar) | Not applicable |
Azure Public DNS is authoritative-only. It hosts your zones and answers queries for names inside them; it is not a recursive resolver, so a Windows Server DNS server can never use an Azure Public DNS name server as a forwarder for general internet resolution.
Delegating a Public Zone to Azure
When you create a public zone, Azure assigns four name servers of the form ns1-NN.azure-dns.com, ns2-NN.azure-dns.net, ns3-NN.azure-dns.org, and ns4-NN.azure-dns.info. Delegation is completed at the domain registrar by replacing the existing NS records with those four values.
# Create a public DNS zone and read back its assigned name servers
New-AzDnsZone -Name 'contoso.com' -ResourceGroupName 'rg-dns'
(Get-AzDnsZone -Name 'contoso.com' -ResourceGroupName 'rg-dns').NameServers
# Add an A record to the public zone
New-AzDnsRecordSet -Name 'www' -RecordType A -ZoneName 'contoso.com' `
-ResourceGroupName 'rg-dns' -Ttl 3600 `
-DnsRecords (New-AzDnsRecordConfig -IPv4Address '20.53.10.42')
Alias record sets are the Azure-specific feature worth remembering: an alias record points at an Azure resource — a public IP address, Traffic Manager profile, Azure Front Door endpoint, or another record set in the same zone — and updates automatically when that resource's address changes. A plain A record pointing at the same public IP would go stale the moment the IP was reassigned.
Delegating a Child Zone From Windows Server DNS
An organisation that keeps contoso.com authoritative on-premises can still host a cloud-facing child zone in Azure Public DNS. Create a delegation on the on-premises DNS server for the child label, pointing at the four Azure name servers:
# Delegate cloud.contoso.com to Azure Public DNS from an on-premises DNS server
Add-DnsServerZoneDelegation -Name 'contoso.com' -ChildZoneName 'cloud' `
-NameServer 'ns1-05.azure-dns.com' -IPAddress 40.90.4.5
Split-Brain DNS Is the Common Design
Most hybrid estates end up running the same public namespace in two places: Azure Public DNS answering contoso.com for internet clients, and an AD-integrated contoso.com zone answering the same names internally with private addresses. This is intentional split-brain DNS. The rule is that internal clients must point only at the internal domain controllers, because a domain-joined client that reaches Azure Public DNS instead will receive the public address of a service it should be reaching privately — and will find no _msdcs SRV records at all.
An administrator manages 20 Active Directory domain controllers across multiple physical sites. The administrator needs to configure conditional forwarding for 'partner.contoso.com' on all 20 domain controllers with minimum administrative effort and ensure automatic replication of any future changes. Which configuration approach should be selected?
A hybrid administrator wants on-premises Windows Server DNS servers to forward all unresolved internet queries to Azure. They configure the four Azure Public DNS name servers assigned to their contoso.com zone as standard forwarders. Internet resolution immediately breaks. Why?