Introduction to DNS Forwarders on Windows Server 2022
When a DNS server receives a query for a domain it is not authoritative for, it has two options: recurse using root hints, or forward the query to another DNS server. DNS forwarders let you specify exactly which upstream DNS servers your Windows Server 2022 DNS resolver should consult when it cannot resolve a name locally. This is critical in enterprise environments where you want to control outbound DNS traffic, enforce security policies, or improve resolution speed by routing queries to known, reliable resolvers.
Root hints are a list of the 13 root DNS server addresses baked into Windows Server. By default, if no forwarders are configured, Windows DNS falls back to root hints and performs iterative resolution across the public DNS hierarchy. In most corporate environments this is undesirable — you want all external queries to go through a controlled path, such as your ISP’s resolvers or a public DNS provider like Google (8.8.8.8) or Cloudflare (1.1.1.1). Forwarders replace root hints as the primary resolution path for non-authoritative queries.
Setting Up DNS Forwarders Using DNS Manager
The DNS Manager console (dnsmgmt.msc) provides a GUI to configure forwarders. Open DNS Manager, right-click your server name in the left panel, and choose Properties. Select the Forwarders tab. Click Edit to add forwarder IP addresses. You can add multiple forwarders — Windows DNS will query them in order. If the first forwarder does not respond within the configured timeout, the next one is tried.
There is also a checkbox labeled “Use root hints if no forwarders are available.” If you want to prevent any fallback to root hints (for instance, to block all direct external DNS resolution), uncheck this box. In high-security environments, disabling root hint fallback ensures all resolution passes through your approved forwarder chain.
Configuring Forwarders with PowerShell
PowerShell provides the DnsServer module for all DNS configuration tasks. To view currently configured forwarders on the local server, run:
Get-DnsServerForwarderThis returns the list of forwarder IP addresses, the timeout in seconds, and whether root hint fallback is enabled. To replace all existing forwarders with Google and Cloudflare DNS:
Set-DnsServerForwarder -IPAddress "8.8.8.8","8.8.4.4","1.1.1.1","1.0.0.1" -UseRootHint $falseTo add a forwarder without replacing the existing list, use Add-DnsServerForwarder:
Add-DnsServerForwarder -IPAddress "9.9.9.9"To remove a specific forwarder:
Remove-DnsServerForwarder -IPAddress "9.9.9.9"The timeout controls how long the DNS server waits for a response from a forwarder before trying the next one. The default is 5 seconds. To adjust it:
Set-DnsServerForwarder -Timeout 3Conditional Forwarding: Concept and Use Cases
Conditional forwarders extend the forwarder concept by allowing you to specify different upstream DNS servers for different domain namespaces. Instead of sending all non-authoritative queries to the same forwarder, you can say: “For queries about contoso.com, forward to 192.168.10.5; for everything else, forward to 8.8.8.8.”
This is valuable in several scenarios. In split DNS environments, internal and external clients resolve the same domain names to different IP addresses. Conditional forwarders allow internal DNS servers to resolve partner or subsidiary domains without exposing them to the public internet. In Active Directory trust scenarios, when two AD forests have a trust relationship, DNS conditional forwarders ensure each forest’s DNS can resolve names in the other forest. Without this, cross-forest Kerberos authentication and resource access will fail.
Another use case is cloud hybrid environments. If you have Azure resources in a private DNS zone (e.g., privatelink.blob.core.windows.net), you configure a conditional forwarder on your on-premises DNS pointing to an Azure DNS Private Resolver so those private names resolve correctly for on-premises clients.
Creating Conditional Forwarders with PowerShell
To add a conditional forwarder zone using PowerShell, use Add-DnsServerConditionalForwarderZone. The following example forwards all queries for fabrikam.com to the DNS servers at 10.1.1.53 and 10.1.2.53:
Add-DnsServerConditionalForwarderZone -Name "fabrikam.com" -MasterServers "10.1.1.53","10.1.2.53" -ForwarderTimeout 5 -ReplicationScope "Forest"The -ReplicationScope parameter controls where this conditional forwarder is stored. Options are: None (local DNS server only), Forest (replicated to all DNS servers in the AD forest), Domain (replicated to all DNS servers in the current AD domain), or Legacy (replicates to all domain controllers, not just DNS servers). Using Forest or Domain scopes is strongly preferred in multi-DC environments because it eliminates the need to manually configure the conditional forwarder on each DNS server.
To view all conditional forwarder zones:
Get-DnsServerZone | Where-Object { $_.ZoneType -eq "Forwarder" }To remove a conditional forwarder:
Remove-DnsServerZone -Name "fabrikam.com"To update the master servers on an existing conditional forwarder:
Set-DnsServerConditionalForwarderZone -Name "fabrikam.com" -MasterServers "10.2.1.53"Configuring Conditional Forwarders in DNS Manager
In DNS Manager, expand your server, then expand the Conditional Forwarders node. Right-click Conditional Forwarders and select New Conditional Forwarder. Enter the DNS domain name (e.g., fabrikam.com), then add the IP addresses of the master DNS servers for that domain. Check “Store this conditional forwarder in Active Directory” if you want replication across domain controllers, and choose the replication scope from the dropdown. Click OK to save.
Stub Zones Versus Conditional Forwarders
Stub zones are sometimes confused with conditional forwarders, but they serve a different purpose. A stub zone contains only NS records, SOA records, and the glue A records for a zone — enough to discover the authoritative DNS servers for that zone. Unlike a conditional forwarder with static master servers, a stub zone automatically updates when the authoritative servers for the target zone change. This makes stub zones better suited for scenarios where the remote zone’s name server infrastructure may change over time.
Conditional forwarders are simpler and require less DNS traffic overhead. They are preferred for quick inter-forest resolution or forwarding to external providers. Stub zones are preferred when you need automatic discovery of authoritative servers and are willing to accept slightly more DNS traffic for the zone transfer updates.
To create a stub zone:
Add-DnsServerStubZone -Name "fabrikam.com" -MasterServers "10.1.1.53" -ReplicationScope "Forest" -ZoneFile "fabrikam.com.dns"Testing DNS Resolution with Resolve-DnsName
After configuring forwarders or conditional forwarders, verify that resolution is working correctly using Resolve-DnsName. This PowerShell cmdlet provides detailed output including which DNS server was queried and the returned records.
To test resolution of a public name through your forwarder:
Resolve-DnsName -Name "www.microsoft.com" -Server "127.0.0.1" -Type ATo test conditional forwarding for the fabrikam.com domain:
Resolve-DnsName -Name "dc01.fabrikam.com" -Server "127.0.0.1" -Type AYou can also use nslookup for quick tests. To query a specific forwarder:
nslookup www.google.com 8.8.8.8To check that root hint fallback is disabled (i.e., resolution fails when forwarder is unreachable), temporarily point to a non-existent forwarder and observe that queries time out rather than falling back to the public DNS hierarchy.
DNS Response Policy Zones
DNS Response Policy Zones (RPZ) allow you to intercept and override DNS responses based on policy. Windows Server 2022 supports Response Policy Zones natively. An RPZ can be used to block malicious domains (DNS sinkholing), redirect internal traffic, or enforce access controls at the DNS layer.
To create an RPZ:
Add-DnsServerResponsePolicyZone -Name "BlockList.rpz" -PassThruTo add a policy that drops all queries for a specific domain (e.g., malware-domain.com):
Add-DnsServerResourceRecord -ZoneName "BlockList.rpz" -Name "malware-domain.com" -RecordType "A" -IPv4Address "0.0.0.0" -TimeToLive 00:05:00When a client queries for malware-domain.com, the DNS server returns 0.0.0.0 instead of the real IP, effectively blocking access. RPZ policies can also redirect to an internal web server that displays a block page. RPZ is a powerful complement to forwarder configurations, allowing fine-grained control over what DNS responses clients receive regardless of what upstream forwarders return.
Forwarder Reordering and High Availability
Windows DNS tries forwarders in the order they are listed. If the first forwarder is slow or unreliable, all clients will experience the timeout delay before the second forwarder is tried. To minimize latency, list your most reliable and geographically nearest forwarder first. In branch office scenarios, consider configuring the branch site DNS server to forward to a hub site DNS server first, with the public resolver as a backup.
Windows Server 2022 also supports per-forwarder timeouts. Monitor forwarder response times using DNS debug logging. Enable DNS debug logging temporarily:
Set-DnsServerDiagnostics -All $true -LogFilePath "C:dns-debug.log" -MaxMBFileSize 100Review the log to identify which forwarder is responding slowest and reorder accordingly. After debugging, disable the logging to avoid disk usage:
Set-DnsServerDiagnostics -All $falseDNS forwarder configuration is deceptively simple but critical to get right. Incorrectly configured forwarders can cause resolution failures, slow authentication, and broken inter-forest trusts. Regularly validate forwarder configurations as part of your DNS health checks, especially after network changes or the addition of new DNS servers.
