Intelligent DNS Responses Based on the Time of Day

DNS policies is a new feature in the DNS server role of Windows Server 2016 Technical Preview – not to be confused with group policies of the AD fame. 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. We also discussed an innovative mechanism to load balance the application server using the DNS policies. Here we explore the scenario of distributing application traffic across different geo-graphically distributed instances of an application by using DNS policies based on the time of the day.

Application Load Balancing On the basis of Time of Day, with Geo-Location Awareness 

Take an example of Contoso Gift Services which provides online gifting solution across the globe. The contosogiftservices.com website is hosted in two datacenters, one in Seattle (North America) and another in Dublin (Europe). The DNS servers are configured for sending geo-location aware responses using DNS policies. The business has seen a recent surge and the contosogiftservices.com is seeing higher number of visitors every day. Some of the customers have reported service availability issues.

A postmortem analysis reports that every day between 6 PM to 9 PM local time, there is a surge in the traffic to the web servers. The web servers are not able to scale to the increased traffic at these peak hours resulting in denial of service to the customers. The same peak hour behaviour is applicable to both European and American datacenters. At any other time the servers see traffic patterns that are well below their maximum capability.

As one can see, the two datacenters are located in separate time zones (around 8 hours apart). So the 6 PM – 9 PM in Dublin is actually 10 AM – 1 PM in Seattle. The administrators would want that the extra surge of traffic at this time on Dublin Web servers, gets redirected to Seattle Web servers, so that even during peak hours no one sees denial of service but at most a delayed response. For the purpose of this example, let us say that during peak hours 20% of traffic needs to be diverted to the other datacenter.

Using the load balancing with Time of Day as a criteria such an automated response distribution is possible.

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, 182.0.0.0/24”

Add-DnsServerClientSubnet -Name “EuropeSubnet” -IPv4Subnet “141.1.0.0/24, 151.1.0.0/24”

 Explore Add-DnsServerClientSubnet

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.

Add-DnsServerZoneScope -ZoneName “contosogiftservices.com” -Name “SeattleZoneScope”

Add-DnsServerZoneScope -ZoneName “contosogiftservices.com” -Name “DublinZoneScope”

 Explore Add-DnsServerZoneScope

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 a Seattle datacenter. Similarly in DublinZoneScope, a record (www.contosogiftservices.com) is added with IP address 141.1.0.3 in the Dublin 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 “141.1.0.3” -ZoneScope “DublinZoneScope”

 

 Explore Add-DnsServerResourceRecord

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:

  1. The European clients get address of Web server in Dublin datacenter in the response.
  2. The American clients get address of Web server in Seattle datacenter in the response.
  3. At 6 PM- 9 PM in Dublin, 20% of queries from European clients get address of Web server in Seattle datacenter in the response.
  4. At 6 PM- 9 PM in Seattle, 20% of queries from American clients get address of Web server in Dublin datacenter in the response.
  5. Half of the queries from the rest of the world get the IP address in the Seattle datacenter and the other half get the IP address in Dublin datacenter.

Note that in the example, the DNS server is in GMT time zone so the peak hour time periods have to be expressed in the equivalent GMT time. 

Add-DnsServerQueryResolutionPolicy -Name “America6To9Policy” -Action ALLOW –ClientSubnet “eq,AmericaSubnet” -ZoneScope “SeattleZoneScope,4;DublinZoneScope,1” TimeOfDay EQ,01:00-04:00 -ZoneName “contosogiftservices.com” –ProcessingOrder 1

Add-DnsServerQueryResolutionPolicy -Name “Europe6To9Policy” -Action ALLOW –ClientSubnet “eq,EuropeSubnet” -ZoneScope “SeattleZoneScope,1;DublinZoneScope,4” –TimeOfDay “EQ,17:00-20:00” -ZoneName “contosogiftservices.com” –ProcessingOrder 2

Add-DnsServerQueryResolutionPolicy -Name “AmericaPolicy” -Action ALLOW –ClientSubnet “eq,AmericaSubnet” -ZoneScope “SeattleZoneScope,1” -ZoneName “contosogiftservices.com” –ProcessingOrder 3

Add-DnsServerQueryResolutionPolicy -Name “EuropePolicy” -Action ALLOW –ClientSubnet “eq,EuropeSubnet” -ZoneScope “DublinZoneScope,1” -ZoneName “contosogiftservices.com” –ProcessingOrder 4

Add-DnsServerQueryResolutionPolicy -Name “RestOfWorldPolicy” -Action ALLOW –-ZoneScope “DublinZoneScope,1;SeattleZoneScope,1” -ZoneName “contosogiftservices.com” –ProcessingOrder 5

 Explore Add-DnsServerQueryResolutionPolicy

How it all works

Note the expression ClientSubnet “eq,AmericaSubnet” -ZoneScope “SeattleZoneScope,4; DublinZoneScope,1” –TimeOfDay “EQ,01:00-04:00”. This expression configures the DNS server with an array of <ZoneScope>,<weight> combination. For every five incoming queries on contosogiftservices.com, the DNS server now returns first four queries with IP address of the web server in Seattle datacenter, and the fifth with IP address of the web server in Dublin datacenter when the time on the DNS Server is between 0100-0400 hours, i.e. 1800-2100 hours in Seattle. Similarly when the server time is 1700-2000 hours, it is 6 PM- 9 PM in Dublin and the 20% of queries from European subnets are responded with an IP address in Seattle data center. For the rest of the day, the AmericaPolicy and EuropePolicy do the normal geo-location aware traffic management. It has to be noted that for a query, the first policy that matches is applied. Hence, the processing order is very important. Here, the time of day based policies have been given a lower processing order (or higher precedence) and hence, are matched before the default load balancing policies. If the client is from anywhere else in the world apart from America and Europe, they get load balanced across Seattle and Dublin datacenter.

Application Scale Out using Azure

Take the example of Contoso Gift Services which provides online gifting solution across the globe. The contosogiftservices.com website for the sake of this example is hosted only at a single on-premise datacenter in Seattle (with public IP 192.68.30.2). The DNS server is also on the on premise datacenter. Similar to the last scenario, the website sees increase in traffic and subsequent reports of denial of service to certain clients. On postmortem, it is found that there is a traffic surge only between 6-9 PM every day, when the application server is unable to manage the load; and anytime else the load is within the capacity of the application server.

Contoso gift Services decides that during these hours it will rent a VM on Azure to host a copy of its Web Server.  It gets a public IP address from Azure (192.68.31.44) and develops the automation to deploy the Web Server every day on Azure between 5-10 PM (keeping 1 hour contingency window). The DNS servers are configured with scopes and policies in such a way that between 5-9 PM everyday 30% of queries are sent to instance of the web server running in Azure. Following steps have to be performed to achieve such a time-based load balancing.


Create the Scopes of the Zone

The first step is to create a zone scope to host the Azure records

Add-DnsServerZoneScope -ZoneName “contosogiftservices.com” -Name “AzureZoneScope”

 Explore Add-DnsServerZoneScope

Note that by default there exists a “default” zone scope with the same name as the zone i.e. ‘contosogiftservices.com’

Add Records to the Zone Scopes

The next step is to add the records representing the web server host into the zone scopes. In AzureZoneScope, the record www.contosogiftservices.com is added with IP address 192.68.31.44, which is located in the Azure public cloud. Similarly in default zone scope (contosogiftservices.com), a record (www.contosogiftservices.com) is added with IP address 192.68.30.2 of the web server running in the on-premise datacenter

 

Add-DnsServerResourceRecord -ZoneName “contosogiftservices.com” -A -Name “www” -IPv4Address “192.68.31.44” -ZoneScope “AzureZoneScope” TimeToLive 600

Add-DnsServerResourceRecord -ZoneName “contosogiftservices.com” -A -Name “www” -IPv4Address “192.68.30.2”

 Explore Add-DnsServerResourceRecord

Note that in the second cmdlet, we have not provided the –ZoneScope parameter, due to which the records are added in default ZoneScope. Also the TTL of the record for Azure VMs is kept at 600s (10 mins) so that the LDNS do not cache it for longer time which would interfere with load balancing. Also, as mentioned the Azure VMs are available for 1 extra hour for contingency to ensure that even clients with cached records are able to resolve.

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:

  1. At 6 PM- 9 PM, 30% of clients get address of web server in Azure datacenter in the response and 70% get the address of on-premise web server.
  2. At all other time, all the clients get address of on-premise web server.

The time of the day has to be expressed in local time of the DNS server.

Add-DnsServerQueryResolutionPolicy -Name “Contoso6To9Policy” -Action ALLOW –-ZoneScope “contosogiftservices.com,7;AzureZoneScope,3” TimeOfDay EQ,18:00-21:00 -ZoneName “contosogiftservices.com” –ProcessingOrder 1

 Explore Add-DnsServerQueryResolutionPolicy

How it all works

Note the expression -ZoneScope “contosogiftservices.com,7;AzureZoneScope,3” TimeOfDay EQ,18:00-21:00 This expression configures the DNS server with an array of <ZoneScope>,<weight> combination. This configures the DNS server to respond back with records in default zone scope (represented by contosogiftservices.com) and AzureZoneScope in a ratio 7:3 when the time is 6PM to 9pm in Seattle. At all other time, the normal query processing takes place and responses are sent from default zone scope which contains a record for the web server in the on-premise datacenter. The TTL of 10 minutes on the Azure record ensures that the record is expired from the LDNS cache before the VM is removed from Azure. One of the benefits of such scaling is that the administrators can keep their DNS data on premise and keep scaling out to Azure as per the elasticity of demand.

Call to Action

Now that you have learnt about achieving application load balancing based on the time of day 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 windns-users@lists.cloudapp.net 

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