Geo-Location Based Traffic Management Using DNS Policies

DNS policies is a new feature in the DNS server role of Windows Server 2016 Technical Preview. You can create DNS policies to control how a DNS Server handles queries based on different parameters. For instance, you may create a DNS policy to respond to a query asking for the IP address of a web server to respond with a different IP address based on the closest datacenter to the client. DNS policies provide a very strong mechanism to control the DNS responses based on following parameters:

 

Name

Description

Client Subnet

Name of a predefined client subnet. Used to verify the subnet from which the query was sent.

Transport Protocol

Transport protocol used in the query. Possible entries are UDP and TCP.

Internet Protocol

Network protocol used in the query. Possible entries are IPv4 and IPv6.

Server Interface IP address

IP address of the network interface of the DNS server which received the DNS request

FQDN

FQDN of record in the query, with the possibility of using a wild card.

Query Type

Type of record being queried (A, SRV, TXT etc.)

Time of Day

Time of day the query is received.

You can combine these criteria with a logical operator (AND/OR) to formulate policy expressions. When these expressions match the policies are expected to perform one of the following actions:

Action

Description

Ignore

The DNS server silently drops the query

Deny

The DNS server responds that query with a failure response

Allow

The DNS server responds back with traffic managed response

One of the key scenarios which is enabled by DNS policies is the ability to achieve traffic redirection on the basis of the source of the DNS query.  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 scenario is roughly represented by the diagram below (The IP addresses and names are purely representational). 

  


Let’s see how the name resolution process normally works. The user tries to connect to www.woodgrove.com. This results in a name resolution request which will be sent to the DNS server configured on the user’s computer. Typically, this is the DNS server provided by the local ISP acting as a caching resolver and is referred as the LDNS. The LDNS server forwards the query to the DNS server authoritative for woodgrove.com – if the DNS name is not present in the local cache of LDNS. The authoritative DNS server responds with the requested record (www.woodgrove.com) to the LDNS server which in turns sends it back to the user’s computer after caching it locally.

Using the Windows DNS server policies the authoritative DNS server hosting contoso.com can be configured to return geo-location based traffic managed responses. The admin needs to perform following steps in order to achieve this:

Create the DNS Client Subnets

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"

Add-DnsServerClientSubnet -Name "EuropeSubnet" -IPv4Subnet "141.1.0.0/24"

 Explore Add-DnsServerClientSubnet

One point to take note of here is the IP address information. As discussed earlier in this blog, the authoritative DNS server, typically, sees the name resolution request coming from the LDNS server and very rarely, from the user’s computer directly. Thus, the source IP address in the name resolution request as seen by the authoritative DNS server is that of the LDNS server and not that of the user’s computer. However, we reckon that using the IP address of the LDNS server would provide a fair estimate of the geo-location of the user for the purpose of traffic management as the user would be using the DNS server of his local ISP.

Create the Scopes of the Zone

Once the client subnets are in place, the next step is to partition the zone woodgrove.com into two different zone scopes, each for America and Europe. 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 "woodgrove.com" -Name "AmericaZoneScope"

Add-DnsServerZoneScope -ZoneName "woodgrove.com" -Name "EuropeZoneScope"

 Explore Add-DnsServerZoneScope

By default a zone scope exists on the DNS zones. This zone scope has the same name as the zone and legacy DNS operations work on this scope.

Add Records to the Zone Scopes

The next step is to add the records representing the web server host into the two zone scopes- AmericaZoneScope and EuropeZoneScope. In AmericaZoneScope, the record www.woodgrove.com is added with IP address 192.0.0.1, which is located in an American datacenter; and in EuropeZoneScope the same record (www.woodgrove.com) is added with IP address 141.1.0.1 in the European datacenter. 

Add-DnsServerResourceRecord -ZoneName "woodgrove.com" -A -Name "www" -IPv4Address "192.0.0.1" -ZoneScope "AmericaZoneScope

Add-DnsServerResourceRecord -ZoneName "woodgrove.com" -A -Name "www" -IPv4Address "141.1.0.1" -ZoneScope "EuropeZoneScope"

 Explore Add-DnsServerResourceRecord

These records are also added into the default zone scope to ensure that rest of the world can still access the woodgrove.com web server from either of the two datacenters.

Add-DnsServerResourceRecord -ZoneName "woodgrove.com" -A -Name "www" -IPv4Address "192.0.0.1"

Add-DnsServerResourceRecord -ZoneName "woodgrove.com" -A -Name "www" -IPv4Address "141.1.0.1"  

Not that no -ZoneScope parameter has been provided when record is being added in default scope. This is same as adding records to a vanilla zone.

Create the Policies

Once the subnets and the partitions (zone scopes) have been created, the next step is to create policies that connect these two, in a way that when the query comes from a source in America client subnet, the answer is returned form the America scope of the zone and so on. No policies are required for mapping default zone scope. 

Add-DnsServerQueryResolutionPolicy -Name "AmericaPolicy" -Action ALLOW -ClientSubnet "eq,AmericaSubnet" -ZoneScope "AmericaZoneScope,1" -ZoneName "woodgrove.com"

Add-DnsServerQueryResolutionPolicy -Name "EuropePolicy" -Action ALLOW -ClientSubnet "eq,EuropeSubnet" -ZoneScope "EuropeZoneScope,1" -ZoneName "woodgrove.com"

 Explore Add-DnsServerQueryResolutionPolicy

How it all works

Now the DNS server has been configured with the required policies. 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 scope is used to respond to the query. So, in our example, the DNS queries for www.woodgrove.com that originate from European IP subnets are responded with the IP address of www.woodgrove.com in European datacenter (192.0.0.1) and the DNS queries that originate from American IP subnets are responded with the IP address of www.woodgrove.com in the American datacenter of Contoso Cloud Services.  The rest of the world gets the two IP addresses and can connect to any one of them. The admin can create hundreds of such policies as per the traffic management requirement, which will apply dynamically (i.e. without restarting the server) on the incoming queries with minimal impact on the QPS.

Note: The policies work on the sender IP as seen in the UDP/TCP packet containing the DNS query. If the query reaches the primary server through multiple resolver/LDNS hops, the policy will consider only the IP of last resolver from which the DNS server receives the query.

Call to Action:

Now that you have learnt a bit about the new policies feature in Windows DNS vNext, we request you to try the feature and let us know your feedback!