DNS policies is a new feature in the DNS server role of Windows Server 2016 Technical Preview. You can create DNS policies on the DNS server to control how a DNS Server handles queries based on different parameters. In the previous blogs, we discussed how to achieve traffic management, deploying split-brain DNS and creating DNS query filters using policies. The policies also provide an innovative mechanism to load balance the application server in a user defined manner.
Distributing Responses in a Given Ratio
Take an example of Contoso Gift Services which provides online gifting services. The contosogiftservices.com website is hosted in multiple datacenters with different IP addresses. In North America, which is the primary market for the business, the website is hosted in three datacenters, in Chicago, Texas and Seattle. The Seattle web server has the best configuration and can handle twice as much load as the other two. The Contoso gift service wants the queries be redirected to the application servers in such a fashion that half of the clients are redirected to the Seattle datacenter and the other half are equally divided across the other two (Texas and Chicago) datacenters.
In the previous versions of the Windows DNS server such a configuration was not possible at the DNS layer. The best load balancing, the DNS solution could offer was configuring DNS to return round robin responses. But that was not enough. Using DNS policies, the application servers can be load balanced in any given proportion. The administrator needs to do the following in order to achieve such load balancing
(The names and IP addresses are purely representational)
Create the Scopes of the Zone
The first step is to create the scopes of the zone contosogiftservices.com as per the datacenters they have been hosted in. A zone scope is a unique instance of the zone. A DNS zone can have multiple zone scopes, with each zone scope containing its own set of DNS records. The same record can be present in multiple scopes, with different IP addresses.
Add-DnsServerZoneScope -ZoneName "contosogiftservices.com" -Name "SeattleZoneScope"
Add-DnsServerZoneScope -ZoneName "contosogiftservices.com" -Name "TexasZoneScope"
Add-DnsServerZoneScope -ZoneName "contosogiftservices.com" -Name "ChicagoZoneScope"
Add Records to the Zone Scopes
The next step is to add the records representing the web server host into the zone scopes. In SeattleZoneScope, the record www.contosogiftservices.com is added with IP address 192.0.0.1, which is located in the Seattle datacenter; and in ChicagoZoneScope the same record (www.contosogiftservices.com) is added with IP address 188.8.131.52 in the Chicago datacenter. Similarly in TexasZoneScope, a record (www.contosogiftservices.com) is added with IP address 184.108.40.206 in the Chicago datacenter.
Add-DnsServerResourceRecord -ZoneName "contosogiftservices.com" -A -Name "www" -IPv4Address "192.0.0.1" -ZoneScope "SeattleZoneScope
Add-DnsServerResourceRecord -ZoneName "contosogiftservices.com" -A -Name "www" -IPv4Address "220.127.116.11" -ZoneScope "ChicagoZoneScope"
Add-DnsServerResourceRecord -ZoneName "contosogiftservices.com" -A -Name "www" -IPv4Address "18.104.22.168" -ZoneScope "TexasZoneScope"
Create the Policies
Once the partitions (zone scopes) have been created, the next step is to create policies that distribute the incoming queries across these scopes in such a manner that 50% of queries for contosogiftservices.com are responded with the IP address in Seattle datacenter and the rest 50% are equally distributed equally between the Chicago and Texas Datacenter.
Add-DnsServerQueryResolutionPolicy -Name "AmericaPolicy" -Action ALLOW – -ZoneScope "SeattleZoneScope,2;ChicagoZoneScope,1;TexasZoneScope,1" -ZoneName "contosogiftservices.com"
How it all works
Note the expression –ZoneScope "SeattleZoneScope,2; ChicagoZoneScope,1; TexasZoneScope,1". This expression configures the DNS server with an array of <ZoneScope>,<weight> combination. For every four incoming queries on contosogiftservices.com, the DNS server now returns first two queries with IP address of the web server in Seattle datacenter, the third with IP address of the web server in Chicago datacenter, and the fourth with IP address of the web server in Texas datacenter. The administrator can create hundreds of such load balancing rules across different datacenters in any proportion as required, which will apply dynamically (i.e. without restarting the DNS Service) on the incoming queries. DNS policies have very low overhead i.e. the server configured with policies can still deliver near about the same queries per second as the one without any policies configured.
One of the points to note here is the caching of DNS records by the DNS client as well as by the resolver/LDNS acts as an impediment to the use of DNS for load balancing. However, this issue can be addressed by using low values for TTL of DNS records which need to be load balanced.
Load Balancing With Geo-Location Awareness
Extending the load balancing scenario further, the above example can be coupled with the Geo-Location based traffic management. Suppose the Contoso Gift Services plans to extend and now has presence across the globe. Similar to North America, now it has web servers hosted in European datacenters. The requirement of application load balancing is such that the connections from America should get distributed amongst America Datacenters in the ratio as explained above, while the connections from Europe should get distributed equally amongst Dublin and Amsterdam datacenters and so on. The administrators also want that all queries from elsewhere in the world should get distributed equally amongst all these datacenters.
The steps to achieve this are a combination of the geo-location aware policies and load balancing policies.
Create the DNS Client Subnets
As done while creating the Geo-Location based traffic management policies, the first step is to identify the subnets or IP address space of the America and Europe regions. Such information can be obtained from Geo-IP maps. Based on these Geo-IP distributions, the admin first needs to create the “DNS Client Subnets”. A client subnet is a logical grouping of IPv4 or IPv6 subnets from which queries are submitted to a DNS server.
Add-DnsServerClientSubnet -Name "AmericaSubnet" -IPv4Subnet 192.0.0.0/24,22.214.171.124/24
Add-DnsServerClientSubnet -Name "EuropeSubnet" -IPv4Subnet 126.96.36.199/24,188.8.131.52/24
Create the Scopes of the Zone
Once the client subnets are in place, the next step is to partition the zone contosogiftservices.com into different zone scopes, each for a datacenter. Three of them for America datacenter were already created in the first example above. Here two more are being created for Dublin and Amsterdam datacenters. These can be added without any changes being needed for the 3 existing zone scopes in the same zone and also, there is no restart of the server required.
Add-DnsServerZoneScope -ZoneName "contosogiftservices.com" -Name "DublinZoneScope"
Add-DnsServerZoneScope -ZoneName "contosogiftservices.com" -Name "AmsterdamZoneScope"
Add Records to the Zone Scopes
The next step is to add the records representing the web server host into the zone scopes. The records for the America datacenters were added in the last example. Here records for European datacenters are being added
Add-DnsServerResourceRecord -ZoneName "contosogiftservices.com" -A -Name "www" -IPv4Address "184.108.40.206" -ZoneScope "DublinZoneScope”
Add-DnsServerResourceRecord -ZoneName "contosogiftservices.com" -A -Name "www" -IPv4Address "220.127.116.11" -ZoneScope "AmsterdamZoneScope"
Create the Policies
Once the subnets and zone scopes have been created, the next step is to create policies that connect these two, in a way that
I. When the query comes from a source in America client subnet, 50% of the response point to Seattle data center, 25% answers point to Chicago data center and the remaining 25% point to Texas datacenter.
II. When the query comes from a source in Europe client subnet, 50% of the response point to Dublin data center and 50% answers Amsterdam datacenter.
III. When the query comes from anywhere else in the world, the response distributes them across all the five datacenters.
Add-DnsServerQueryResolutionPolicy -Name "AmericaLBPolicy" -Action ALLOW -ClientSubnet "eq,AmericaSubnet" -ZoneScope "SeattleZoneScope,2;ChicagoZoneScope,1; TexasZoneScope,1" -ZoneName "contosogiftservices.com" –ProcessingOrder 1
Add-DnsServerQueryResolutionPolicy -Name "EuropeLBPolicy" -Action ALLOW -ClientSubnet "eq,EuropeSubnet" -ZoneScope "DublinZoneScope,1;AmsterdamZoneScope,1" -ZoneName "contosogiftservices.com" -ProcessingOrder 2
Add-DnsServerQueryResolutionPolicy -Name "WorldWidePolicy" -Action ALLOW -FQDN "eq,*.contoso.com" -ZoneScope "SeattleZoneScope,1;ChicagoZoneScope,1; TexasZoneScope,1;DublinZoneScope,1;AmsterdamZoneScope,1" -ZoneName "contosogiftservices.com" -ProcessingOrder 3
Note the usage of –ProcessingOrder in the cmdlets. The policy with the lower processing order is matched first. Once a policy is matched at the zone level no further policies of that zone are matched. This ensures that the European and American geo location based load balancing policies take precedence over the world wide load balancing policy.
*Please also note that you will need to delete the earlier policy created (“AmericaPolicy”) so that it does not interfere with AmeircaLBPolicy that we created in the previous step.
How it all works
When a name resolution query is incident on the DNS server so configured, each name resolution request is evaluated against the policies on the DNS server. If the source IP address in the name resolution request matches any of the policy, the associated zone scopes are used to respond to the query in the specified proportion. So, in our example, 50% of the DNS queries for www. contosogiftservices.com that originate from European IP subnets are responded with the IP address of www.contosogiftservices.com in Dublin datacenter (192.0.0.1) and the rest are responded with the IP address of www.contosogiftservices.com in Amsterdam datacenter. Similarly the policies are employed for responding to queries from American clients. For the rest of the world the “WorldWidePolicy” matches and the responses are distributed in a fashion that one out of every five responses point to each of the datacenters.
The load balancing mechanism can be combined with any other criteria to create custom load balancing policies. All the policy settings can be updated on the fly without needing to restart the DNS server.
Call to Action
Now that you have learnt about achieving application load balancing using DNS policies in Windows DNS Server 2016, we request you to try the feature and let us know your feedback. Also tell us how you plan to use such policies in your environment. Use the comment box below or mail us at email@example.com