Today’s Tip…
Yesterday’s tip discussed the DNS policy processing workflow. It also introduced a few of the objects used to create policy statements. One or two of these are completely new DNS constructs that must be configured prior to use:
- Client Subnets for example, which can be used as evaluation criteria, and
- Zone Scopes, which are essentially a zone partition containing unique sets of resource records for a zone.
Others parameters, such as different types of evaluation criteria and logical operators are added in the policy expression itself.
Today’s tip looks closer at these policy building blocks, and demonstrates how they can be used.
First, A Practical Scenario
To make review of the following policy parameters more meaningful, let’s consider a practical DNS policy scenario. This will allow us to see some of the commands and parameters in action as we go.
Woodgrove.com Geo-Location Scenario
Geo-Location Awareness response policies are a common use-case for Windows Server 2016 DNS Policy and can be very effective in helping reduce latency and improve the user experience. They work by directing client connections to a remote resource to the instance of that resource closest to that client’s physical location.
In this scenario, woodgrove.com has a web resource, with one instance hosted in their Seattle datacenter, and another identical instance hosted in Dublin. To realize the best possible user experience, they want to use DNS policies to ensure that client connections to www.woodgrove.com originating from Europe are directed to the Dublin instance. And client connections originating from North America are directed to the instance located in Seattle.
We will build the required policies as we go through the following content.
Query Evaluation Parameters
Criteria
Criteria is used to evaluate incoming queries. DNS policy criteria can include any one or more of these types.
*This is contrary to some incorrect public documentation stating the value must be expressed in the GMT equivalent.
Operators
One of two operators, EQ (equal) or NE (not equal), is added to each policy criteria to set its evaluation logic.
Condition
An optional AND/OR condition can be added to specify how the policy treats multiple criteria. In the absence of an -condition parameter, the default AND behavior is used, meaning that a query must match all criteria to trigger a policy.
Woodgrove.com Scenario
Geo-Location policies commonly use client subnets in its evaluation criteria. The first step in configuring a policy of this sort is to identify the IP address range for the location/region you want to manage, and create any required client subnet objects. In a real-life situation where you want to direct traffic originating from an entire continent, you would need to use Geo-IP maps to determine the appropriate address ranges. For our scenario however, we are just going to 192.168.1.0/24 and 192.168.2.0/24 to represent North America and Europe respectively:
Creating Client Subnets:
The following commands create an “AmericaSubnet” and “EuropeSubnet” with the values shown.
Add-DnsServerClientSubnet -Name “AmericaSubnet” -IPv4Subnet “192.168.1.0/24”
Add-DnsServerClientSubnet -Name “EuropeSubnet” -IPv4Subnet “192.168.2.0/24”
Note the absence of any reference to either and operator or condition mentioned above. These are added later in the policy statement, as can any of the other criteria types you may want to use.
Policy Action
The action dictates the behavior of a policy and will vary depending on the purpose of the policy. For example, some policies may be created to provide a customized name-response based on the criteria so would use an allow action. Others might be designed to block queries for certain types of records, or malicious FQDNs. These might use either a deny or ignore action.
Woodgrove.com Scenario
At this point, there is nothing to add to the woodgrove policy scenario, as the ALLOW action will be added later when we create the policy statements.
Scopes
Scopes are the key to providing customized responses in a DNS query resolution policy.
Woodgrove.com Scenario
In this scenario, the DNS server already hosts a woodgrove.com zone. However, we will need to create two Zone Scopes: one to hold the records used to respond to North American clients, and the other for the records used to respond to European clients.
Creating Zone Scopes:
The following commands creates two zone scope, “AmericaZoneScope” and “EuropeZoneScope”, within the “woodgrove.com” zone.
Add-DnsServerZoneScope -ZoneName “woodgrove.com” -Name “AmericaZoneScope”
Add-DnsServerZoneScope -ZoneName “woodgrove.com” -Name “EuropeZoneScope”
Adding the Resource Records:
We must also populate the scopes with resource records to be returned in the event of a policy match. For our example, we will use the IP 10.0.0.1 as IP for the web server in Seattle, and 10.2.0.1 for the web server in Dublin.
Add-DnsServerResourceRecord -ZoneName “woodgrove.com” -A -Name “www” -IPv4Address “10.0.0.1” -ZoneScope “AmericaZoneScope”
Add-DnsServerResourceRecord -ZoneName “woodgrove.com” -A -Name “www” -IPv4Address “10.2.0.1” -ZoneScope “EuropeZoneScope”
Note that the addition of the -ZoneScope parameter. This is the only difference between using PowerShell to create a zone scope record, versus creating a regular DNS zone record.
Creating the DNS Policies:
With the ground work laid, we can now create the policies. Two will be required, one to manage North American traffic and another to manage European traffic.
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”
Note the parameters used in the Add-DnsServerQueryResolutionPolicy command.
- The -name parameter is used to create a descriptive name for the policy.
- Both policies include an ALLOW action, meaning queries matching the address space referenced in the -ClientSubnet criteria will receive an answer derived from the scope indicated in the -ZoneScope parameter.
- Note the use of the EQ operator in the -ClientSubnet parameter. Using the NE operator here would reverse the policy logic, causing any query but those originating from the America Subnet to match and trigger the policy.
- Note the numerical value “,1” after the scope name in each policy. The value is meaningless in this scenario, but in a case where you wanted to load-balance using the records from multiple scopes, you can adjust this number to reflect the desired ratio. Here is an example, splitting the load between two datacenters at a 4:1 ratio: -ZoneScope “AmericaZoneScope,4;EuropeZoneScope,1”
- We needn’t specify and AND/OR condition as there is only one evaluation criteria. Had there been multiple criteria, then consideration would have been given to which was most appropriate.
If you’ve gotten this far, thanks for hanging with this unusually long tip. There is so much more to tell including the very important topics; how to control policy processing order through precedence, and how to use PowerShell and other tools to review and troubleshoot policy implementations. Perhaps in another tip…. for now however, you can see more information on DNS policies and DNS policy scenarios here: