Windows Server DNS Zones and Conditional Forwarders

A Windows Server DNS deployment usually starts simple — one zone, one forwarder — and then grows into a mix of Active Directory-integrated zones, stub zones for delegated namespaces, and conditional forwarders for partner domains. Each of those exists to solve a specific resolution problem, and using the wrong one produces confusing symptoms: names that resolve on one domain controller and not another, or slow resolution because queries leave the network unnecessarily. This guide covers creating each zone type with PowerShell, configuring conditional forwarders, and verifying the result.

Choosing the Zone Type

• Primary zone — the authoritative copy. In an AD environment, make it Active Directory-integrated so it replicates with domain replication instead of zone transfers.
• Secondary zone — a read-only copy pulled from a primary. Useful for load distribution where AD replication is not available.
• Stub zone — holds only the NS records of the authoritative name servers for a zone. The server keeps that list current automatically, which is exactly what you want for a parent zone that delegates a child namespace.
• Conditional forwarder — forwards queries for one domain to specific servers. The right tool for resolving partner or acquired-company namespaces.

Zone types and when to use each

A common mistake is using a secondary zone where a stub zone is correct: the secondary copies the whole namespace and needs zone transfer permissions, while the stub keeps only delegation information and is far lighter.

Create Zones with PowerShell

AD-integrated primary zone, replicated to every DNS server in the domain by default:

Add-DnsServerPrimaryZone -Name "corp.example.com" -ReplicationScope "Domain" -PassThru
Add-DnsServerPrimaryZone -Name "north.contoso.com" -ReplicationScope "Forest" -PassThru

File-backed primary zone when the zone is not part of AD:

Add-DnsServerPrimaryZone -Name "east.contoso.com" -ZoneFile "east.contoso.com.dns"

Secondary zone, pointed at the primary server that holds the writable copy:

Add-DnsServerSecondaryZone -Name "south.contoso.com" -ZoneFile "south.contoso.com.dns" -MasterServers 172.23.90.124

Stub zone, pointed at an authoritative server for the delegated namespace:

Add-DnsServerStubZone -Name "west.contoso.com" -MasterServers 172.23.90.124 -ReplicationScope "Domain"

Reverse lookup zone for a /24, which is required for tools that resolve IP addresses back to names:

Add-DnsServerPrimaryZone -NetworkID "172.23.90.0/24" -ReplicationScope "Domain"

Configure Conditional Forwarders

Conditional forwarders send queries for a specific domain to designated servers, which is how you resolve a partner's namespace without sending those queries to the internet:

Add-DnsServerConditionalForwarderZone -Name "partner.example.net" -MasterServers 10.50.0.10, 10.50.0.11
Add-DnsServerConditionalForwarderZone -Name "contoso.com" -MasterServers 172.23.90.124
Get-DnsServerZone | Where-Object { $_.ZoneType -eq "Forwarder" } | Format-Table ZoneName, MasterServers

A conditional forwarder is not a delegation. If your server hosts the parent zone contoso.com, it uses its own delegation records before consulting forwarders — you cannot conditionally forward a zone you are already authoritative for. To forward between separate namespaces, put the conditional forwarder on the server that is not authoritative for that name, or on a server that holds a stub zone for it.

Tune Global Forwarders and Reordering

Global forwarders handle everything not covered by a hosted zone or a conditional forwarder. Dynamic Forwarder Reordering is enabled by default: the server maintains a dynamic list ordered by response time, and resets to the configured order roughly every 15 minutes. Beginning with Windows Server 2022, if no forwarder in the list responds, the server keeps using only the first entry on the dynamic list until the DNS service restarts — a behaviour worth knowing when a single broken forwarder seems to become the only one used.

Add-DnsServerForwarder -IPAddress 10.0.0.53 -PassThru
Get-DnsServerForwarder

Verify Resolution Behaviour

Get-DnsServerZone
Get-DnsServerZone -Name "corp.example.com" | Format-List
Get-DnsServerZoneTransferPolicy -Name "corp.example.com"
Get-DnsServerResourceRecord -ZoneName "corp.example.com" -RRType A | Format-Table HostName, RecordData
Resolve-DnsName -Name server1.partner.example.net -Server dc01.corp.example.com -DnsOnly
Resolve-DnsName -Name host.corp.example.com -Server dc01.corp.example.com
Get-DnsServerStatistics -ComputerName dc01

Testing a specific DNS server

Resolve-DnsName with an explicit -Server is the correct way to test a specific DNS server rather than the client's configured resolver. Testing from the client instead is how "it resolves fine for me" turns into an unfixable ticket.

To confirm which server actually answered, inspect the response flags for recursion and authority, then cross-check with Get-DnsServerStatistics to see whether the query count is rising. If a conditional forwarder is configured but queries are still going to the internet, confirm the zone name matches exactly — a conditional forwarder for example.net does nothing for example.com.

Operational Notes

• Make all zones AD-integrated where possible — replication, security and multi-master updates come free.
• Use stub zones for delegated namespaces and conditional forwarders for external namespaces.
• You cannot conditionally forward a zone you are authoritative for; the delegation wins.
• Always test with Resolve-DnsName -Server against each DNS server before concluding that resolution is broken.
• Replicate zones to the right scope (Domain or Forest) — a Forest-scoped zone adds replication traffic that a Domain-scoped one avoids.

Related reading: our BIND9 authoritative DNS zone configuration guide, the dig and nslookup troubleshooting commands guide, and the systemd-resolved and resolvectl troubleshooting article.

原文链接：https://learn.microsoft.com/en-us/windows-server/networking/dns/manage-dns-zones