Stackvora.tech

Set Up Conditional Forwarders for Hybrid AD/Cloud DNS

Integrating on-premises Active Directory (AD) DNS with cloud-based services, particularly Microsoft Azure, often necessitates a robust and reliable name…

Integrating on-premises Active Directory (AD) DNS with cloud-based services, particularly Microsoft Azure, often necessitates a robust and reliable name resolution strategy. Conditional forwarders provide a surgical approach to directing DNS queries for specific zones to their authoritative servers, preventing recursive lookups through general forwarders or root hints that might not have visibility into your private networks. This article outlines the setup of conditional forwarders for hybrid AD/Cloud DNS, focusing on Windows DNS and Azure's Private Resolver.

The primary goal is to ensure that resources in one environment can seamlessly resolve names in the other without compromising security or introducing unnecessary latency. This is crucial for hybrid applications, domain-joined virtual machines, and management plane connectivity.

Understanding Conditional Forwarders

A conditional forwarder in Windows DNS is configured to forward DNS queries for a specific DNS domain name (e.g., corp.local) to designated IP addresses. Unlike a standard forwarder, which handles all non-local queries, a conditional forwarder acts only for the specified zone. This directed approach is fundamental in hybrid scenarios where different networks host different authoritative DNS servers.

When to Use Conditional Forwarders

  • Hybrid AD environments: When your on-premises AD domain (e.g., corp.local) needs to be resolved by Azure VMs, and Azure-native services (e.g., privatelink.blob.core.windows.net) need to be resolved by on-premises machines.
  • Mergers and Acquisitions: Integrating separate corporate networks with distinct DNS namespaces.
  • Application-specific DNS: Directing queries for specific application domains to dedicated DNS servers.
  • Avoiding Split-Brain DNS: Preventing scenarios where different DNS servers are authoritative for the same zone, leading to inconsistent resolution. This is a critical principle: never try to make both your on-premises DNS and your cloud DNS authoritative for the exact same domain. Choose one source of truth.

On-Premises DNS Configuration for Azure Resolution

To enable on-premises machines to resolve Azure resources, especially those exposed via Azure Private Link, you'll configure conditional forwarders on your Windows Domain Controllers (DCs) acting as DNS servers.

1. Identifying Azure DNS Servers for Private Zones

Azure-hosted resources using Private Link, or services deployed within Virtual Networks (VNets) with private DNS zones, are typically resolved by Azure's internal DNS resolvers. Within an Azure VNet, the default DNS server is 168.63.129.16. However, this IP address is only reachable from within Azure. For on-premises servers to resolve these, you need an Azure Private Resolver or specific DNS forwarders within Azure.

The recommended approach for hybrid resolution is to deploy an Azure Private Resolver. This service acts as an inbound and outbound endpoint for DNS queries within your VNet and across connected networks (like ExpressRoute or VPN gateways).

2. Deploying Azure Private Resolver

An Azure Private Resolver requires an Inbound Endpoint and an Outbound Endpoint. The Inbound Endpoint exposes a set of IP addresses within your VNet that can receive DNS queries from on-premises. The Outbound Endpoint uses a ruleset to forward specific queries to Azure DNS or other custom DNS servers.

# Example: Deploying Azure Private Resolver via Azure CLI
# Ensure you have a VNet and a subnet for the resolver (e.g., 'snet-dnsresolver')

# Create a Resource Group for the resolver
az group create --name rg-dnsresolver --location eastus

# Create the Private Resolver
az network dns-resolver create \
    --resource-group rg-dnsresolver \
    --name myAzurePrivateResolver \
    --location eastus \
    --virtual-network /subscriptions//resourceGroups//providers/Microsoft.Network/virtualNetworks/

# Create an Inbound Endpoint (requires a dedicated subnet)
# Note: The subnet should be delegated to 'Microsoft.Network/dnsResolvers'
az network dns-resolver inbound-endpoint create \
    --resource-group rg-dnsresolver \
    --dns-resolver-name myAzurePrivateResolver \
    --name ie-dnsresolver \
    --location eastus \
    --subnet /subscriptions//resourceGroups//providers/Microsoft.Network/virtualNetworks//subnets/snet-dnsresolver

# After creation, retrieve the IP addresses of the Inbound Endpoint
az network dns-resolver inbound-endpoint show \
    --resource-group rg-dnsresolver \
    --dns-resolver-name myAzurePrivateResolver \
    --name ie-dnsresolver \
    --query "ipConfigurations[].ipAddress" -o tsv
# Output will be one or more IP addresses, e.g., 10.10.1.4

3. Configuring On-Premises Conditional Forwarders

Once you have the IP address(es) of the Azure Private Resolver's Inbound Endpoint (e.g., 10.10.1.4), configure conditional forwarders on your on-premises Windows DNS servers.

For each Azure Private DNS Zone (e.g., privatelink.blob.core.windows.net, privatelink.database.windows.net, or your custom VNet DNS zone), create a conditional forwarder. This should be done on all your primary DNS servers.

  1. Open DNS Manager on a Domain Controller.
  2. Expand your server name, then right-click on Conditional Forwarders.
  3. Select New Conditional Forwarder...
  4. For the DNS Domain, enter the private DNS zone name (e.g., privatelink.blob.core.windows.net).
  5. For the Master servers' IP addresses, enter the IP address(es) of your Azure Private Resolver Inbound Endpoint (e.g., 10.10.1.4).
  6. Check "Store this conditional forwarder in Active Directory, and replicate it as follows:" and select "All DNS servers in this forest" (recommended for AD-integrated zones).
  7. Click OK.

Repeat for all relevant Azure Private DNS Zones. Common zones include:

  • privatelink.blob.core.windows.net
  • privatelink.queue.core.windows.net
  • privatelink.file.core.windows.net
  • privatelink.table.core.windows.net
  • privatelink.database.windows.net (for Azure SQL Database)
  • privatelink.postgres.database.azure.com (for Azure Database for PostgreSQL)
  • privatelink.mysql.database.azure.com (for Azure Database for MySQL)
  • privatelink.monitor.azure.com
  • Any custom private DNS zones you've created (e.g., internal.azure.contoso.com).

Azure DNS Configuration for On-Premises Resolution

For Azure-hosted VMs and services to resolve on-premises Active Directory domains (e.g., corp.local), you'll use the Azure Private Resolver's Outbound Endpoint and its associated DNS forwarding rulesets.

1. Creating a DNS Forwarding Ruleset

An Azure Private Resolver's Outbound Endpoint uses a ruleset to define how queries for specific zones are handled.

# Create a DNS Forwarding Ruleset
az network dns-resolver forwarding-ruleset create \
    --resource-group rg-dnsresolver \
    --dns-resolver-name myAzurePrivateResolver \
    --name frs-onpremdns \
    --location eastus \
    --target-virtual-network /subscriptions//resourceGroups//providers/Microsoft.Network/virtualNetworks/

2. Adding a Forwarding Rule to the Ruleset

This rule will direct queries for your on-premises AD domain (e.g., corp.local) to your on-premises Domain Controller IP addresses.

# Add a forwarding rule for corp.local
# Replace 192.168.1.10 and 192.168.1.11 with your actual on-premises DC IPs
az network dns-resolver forwarding-rule create \
    --resource-group rg-dnsresolver \
    --dns-resolver-name myAzurePrivateResolver \
    --ruleset-name frs-onpremdns \
    --name corp-local-rule \
    --domain-name corp.local \
    --target-dns-servers "[{ipAddress:'192.168.1.10',port:53},{ipAddress:'192.168.1.11',port:53}]" \
    --forwarding-rule-state Enabled

Ensure that the Azure VNet hosting the Private Resolver has network connectivity (e.g., via VPN Gateway or ExpressRoute) to your on-premises DCs on TCP/UDP port 53.

3. Associating the Ruleset with a VNet

Finally, associate the DNS forwarding ruleset with the Azure VNet(s) where your VMs needing on-premises resolution reside. This configures the VNet to use the Outbound Endpoint for DNS resolution based on the ruleset.

# Associate the ruleset with your VNet
az network dns-resolver forwarding-ruleset vnet-link create \
    --resource-group rg-dnsresolver \
    --ruleset-name frs-onpremdns \
    --name vnet-link-frs \
    --virtual-network /subscriptions//resourceGroups//providers/Microsoft.Network/virtualNetworks/ \
    --no-wait

After this, VMs in the associated VNet that are configured to use Azure-provided DNS (or the resolver's VNet IP) will automatically leverage these rules.

Testing and Verification

Thorough testing is crucial to confirm successful hybrid DNS resolution.

From an Azure VM:

Ensure the Azure VM uses the default Azure DNS (168.63.129.16) or the VNet's custom DNS servers pointing to the Private Resolver's VNet IP. Then, test resolution for an on-premises resource:

# From an Azure VM (Windows)
nslookup onpremserver.corp.local

# Expected output should show your on-premises DC resolving the name
# Example:
# Server:  UnKnown
# Address:  168.63.129.16 (or your VNet's custom DNS IP)
#
# Name:    onpremserver.corp.local
# Address: 192.168.1.50

If you've configured custom DNS servers in the VNet pointing to your Private Resolver, use nslookup onpremserver.corp.local to test directly.

From an On-Premises Machine:

Test resolution for an Azure resource, especially a Private Link endpoint or a VM in your VNet.

# From an on-premises machine (Windows)
nslookup mywebapp.privatelink.azurewebsites.net 192.168.1.10 (your on-prem DC IP)

# Or for a VM in Azure
nslookup azurevm.internal.azure.contoso.com 192.168.1.10

# Expected output should show your on-premises DC forwarding to the Azure Private Resolver,
# which then resolves the Azure resource.

Ensure your on-premises firewall permits UDP/53 traffic from your DCs to the Azure Private Resolver's Inbound Endpoint IP(s).

Common Pitfalls and Troubleshooting

  • Network Connectivity: The most common issue. Verify IP connectivity (ICMP, TCP/53) between on-premises DCs and Azure Private Resolver Inbound Endpoints, and between the Azure Private Resolver Outbound Endpoint and on-premises DCs. Use Test-NetConnection -Port 53 or telnet 53.
  • Firewall Rules: Ensure firewalls (on-premises, Azure Network Security Groups, Azure Firewall) permit DNS traffic (UDP/53, TCP/53) between all relevant components.
  • Incorrect IP Addresses: Double-check the IP addresses used for conditional forwarders and forwarding rules.
  • DNS Cache: Clear DNS cache on clients and DNS servers after making changes (ipconfig /flushdns on Windows clients, Clear-DnsServerCache on Windows DNS servers).
  • Private Resolver Subnet Delegation: The subnet used for the Azure Private Resolver's Inbound Endpoint must be delegated to Microsoft.Network/dnsResolvers.
  • VNet DNS Configuration: For Azure VMs to use the Private Resolver's rules, their VNet's DNS server settings should either be left as "Default (Azure-provided)" or explicitly point to the Private Resolver's VNet IP addresses (if using custom DNS settings for the VNet).
  • Split-Brain DNS: Avoid creating a situation where both on-premises DNS and Azure DNS are authoritative for the *same* exact private zone. For example, do not create a corp.local zone in an Azure Private DNS Zone if corp.local is already your on-premises AD domain. This leads to unpredictable resolution.
  • AD Replication: If conditional forwarders are stored in Active Directory, allow time for AD replication to propagate changes to all DCs.

Back to the knowledge base · Ask the AI assistant