Traffic Management with DNS Policies in Primary-Secondary Deployment

In the last few blogs we have seen how Windows DNS server policies can be used to achieve traffic management, application load balancing, deploying split-brain DNS, creating DNS filters etc. These blogs talked about configuring policies on the primary DNS server. But in the internet infrastructure the DNS servers are widely deployed in primary-secondary model, where the writable copy of a zone is kept on select and secure primary server(s) , and read only copies are kept on multiple secondary servers. The secondary servers keep themselves updated with the changes on the primary zone using the zone transfer protocols (AXFR and IXFR). In this blog we will take the example of the ‘Geo-Location Based Traffic Management Using DNS Policies’ scenario and see how the same can be deployed in a primary secondary model.

Consider a company Contoso Cloud Services that provides web and domain hosting solutions. One of its customers is Woodgrove Food Services that provides food delivery services in multiple cities across the globe. Contoso Cloud Services has two datacenters, one in America and another in Europe, where it hosts its food ordering portal for To ensure that the customers get a responsive experience from the website, Woodgrove wishes that the European clients be redirected to Europe datacenter and American clients be redirected to American datacenter. The rest of the world can be directed to any of these datacenters. This is same as what was described in the previous blog, with a difference that now there are two secondary servers (SecondaryServer1-, SecondaryServer2-, that are acting as name servers in the two different regions. There is a primary writable copy (on PrimaryServer-, where the changes are made and it is expected that the secondaries are up to date with these changes. This scenario is roughly represented by the diagram below (The IP addresses and names are purely representational).

Let’s see how the zone transfers normally work. First, the primary zone is created on the primary DNS server. Then, the secondary zones are created on the secondary server, wherein the primary servers are specified. The secondary servers are then added as trusted secondaries on the primary zone. Then, the secondary zones make a full zone transfer request (AXFR) and get the copy of the zone. Afterwards the primary servers can choose to send notifications to the secondary servers about zone updates, and secondary servers can make an incremental zone transfer request (IXFR). Thus, the secondary servers keep in sync with the primary server. However, as we have seen the traffic management scenario requires partitioning the zones into different zone scopes. So a new mechanism is required to transfer the data inside the zone scopes to the secondary servers as well.  Also a mechanism to transfer policies and client subnets on the secondary servers is required. In the following sections we will see how that can be achieved.


The primary server must be configured with zones, zone scopes, client subnets and policies as described in the blog. The following examples will extend over this blog.

Create the Secondary Zones

The first step is to create the secondary copy of on SecondaryServer1 and SecondaryServer2 (assuming the cmdlets are being executed remotely from a single management client). This can be done using following cmdlets

Add-DnsServerSecondaryZone -Name "" -ZoneFile "" -MasterServers –ComputerName SecondaryServer1

Add-DnsServerSecondaryZone -Name "" -ZoneFile "" -MasterServers –ComputerName SecondaryServer2

 Explore Add-DnsServerSecondaryZone

Configure the Zone transfer settings on Primary Zone

The primary zone settings need to be configured in such a way that:

  1. It allows zone transfers to the specified secondary servers.
  2. It sends zone update notifications to these secondary servers.

This can be done using following cmdlet

Set-DnsServerPrimaryZone -Name “ -Notify Notify -SecondaryServers “,” –SecureSecondaries TransferToSecureServers –ComputerName PrimaryServer

 Explore Set-DnsServerPrimaryZone

 Here the parameter -Notify specifies that the primary server will send notifications about updates to the select list of secondaries.

Copy the Client Subnets

The client subnets can be copied from the primary server to the secondary servers using following cmdlet.

Get-DnsServerClientSubnet –ComputerName PrimaryServer | Add-DnsServerClientSubnet –ComputerName SecondaryServer1

Get-DnsServerClientSubnet –ComputerName PrimaryServer | Add-DnsServerClientSubnet –ComputerName SecondaryServer2

Explore Add-DnsServerClientSubnet

Create the Zone Scopes on the Secondary Server

Similarly, the zone scopes can be created on the secondary server

Get-DnsServerZoneScope -ZoneName "" –ComputerName PrimaryServer|Add-DnsServerZoneScope -ZoneName "" –ComputerName SecondaryServer1 –ErrorAction Ignore

Get-DnsServerZoneScope -ZoneName "" –ComputerName PrimaryServer|Add-DnsServerZoneScope -ZoneName "" –ComputerName SecondaryServer2 –ErrorAction Ignore

In the Windows Server 2016, the zone scopes will also start requesting for XFRs to the primary server. For any change on the scopes on the PrimaryServer, a notification would be sent to the secondary servers. The secondary servers can update their zone scopes with incremental change.

 Explore Add-DnsServerZoneScope

The ErrorAction Ignore has been provided, because there exists a default zone scope on every zone, which can neither be created nor destroyed. Pipelining will result in attempt to create that scope and it will fail. Alternatively, the zone scopes can be directly created on two secondary zones.

Configure the policies

The policies can also be configured in the same way as the subnets. 

$policy = Get-DnsServerQueryResolutionPolicy -ZoneName "" –ComputerName PrimaryServer

$policy | Add-DnsServerQueryResolutionPolicy -ZoneName "" –ComputerName SecondaryServer1

$policy | Add-DnsServerQueryResolutionPolicy -ZoneName "" –ComputerName SecondaryServer2

 Explore Add-DnsServerQueryResolutionPolicy

Note that the cmdlets above to copy client subnets, zone scopes and policies are for a one-time setup and validation. The client subnets, zone scopes and policies settings can change on the primary server and automation scripts can be authored to keep the secondaries in sync with the primary server. Sample reference scripts will be published in future for the same.

How it all works

To ensure the Zone scope level transfer, the Windows DNS servers in Windows Server 2016, use the EDNS0 OPT RR. All zone transfer (AXFR or IXFR) requests from the zones with scopes originate with an EDNS0 OPT RR, whose option ID is by default set to “65433”. The value of the OPT RR is the zonescope name for which the request is being sent. When a primary Windows DNS server receives this packet from a trusted secondary server, it interprets the request as coming for that zone scope. If the primary server has that zone scope it responds back with the XFR data from that scope. The response contains an OPT RR with same option ID “65433” and value set to the same zone scope. The secondary servers, get this response, fetch the scope information from the response and update that particular scope of the zone.

The primary server, thereafter maintains a list of trusted secondaries which have sent such a zone scope request for notifications. For any further update in a zone scope, an IXFR notification is sent to the secondary servers, with the same OPT RR. The zone scope receiving that notification makes the IXFR request containing that OPT RR and the same process as described above follows.

Call to Action

The same zone transfer mechanism can be used to deploy other zone level DNS policies scenarios in primary-secondary model. Now that you have learnt about deploying secondary zones with DNS policies in Windows Server 2016, we request you to try the feature and let us know your feedback!

Also See

Geo-Location Based Traffic Management Using DNS Policies

Split-Brain DNS Deployment Using Windows DNS Server Policies

Applying Filters on DNS Queries using Windows DNS Server Policies

Application Load Balancing using DNS Server Policies

Intelligent DNS Responses Based on the Time of Day