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 woodgrove.com. 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-10.0.0.2, SecondaryServer2-10.0.0.3), that are acting as name servers in the two different regions. There is a primary writable copy (on PrimaryServer-10.0.0.1), 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.
Create the Secondary Zones
The first step is to create the secondary copy of woodgrove.com 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 "woodgrove.com" -ZoneFile "woodgrove.com.dns" -MasterServers 10.0.0.1 –ComputerName SecondaryServer1
Add-DnsServerSecondaryZone -Name "woodgrove.com" -ZoneFile "woodgrove.com.dns" -MasterServers 10.0.0.1 –ComputerName SecondaryServer2
Configure the Zone transfer settings on Primary Zone
The primary zone settings need to be configured in such a way that:
- It allows zone transfers to the specified secondary servers.
- It sends zone update notifications to these secondary servers.
This can be done using following cmdlet
Set-DnsServerPrimaryZone -Name “woodgrove.com -Notify Notify -SecondaryServers “10.0.0.2,10.0.0.3” –SecureSecondaries TransferToSecureServers –ComputerName PrimaryServer
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
Create the Zone Scopes on the Secondary Server
Similarly, the zone scopes can be created on the secondary server
Get-DnsServerZoneScope -ZoneName "woodgrove.com" –ComputerName PrimaryServer|Add-DnsServerZoneScope -ZoneName "woodgrove.com" –ComputerName SecondaryServer1 –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.
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 "woodgrove.com" –ComputerName PrimaryServer
$policy | Add-DnsServerQueryResolutionPolicy -ZoneName "woodgrove.com" –ComputerName SecondaryServer1
$policy | Add-DnsServerQueryResolutionPolicy -ZoneName "woodgrove.com" –ComputerName SecondaryServer2
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!