High Resolution

GeoDNS providers help manage external access to an application as a function of the requesting client's location. Using these services, you can define which IP address is returned in response to a DNS request or whether the request is answered at all, making it easy to roll out and manage access to your application: You only need to publish a name, and the client automatically connects to the best available data center site. However, the internal publication of applications in distributed Windows infrastructures forces administrators to resort to workarounds when assigning IP addresses to a DNS request.

This lack of flexibility is compensated for either by the application itself controlling client access as a function of the Active Directory (AD) location (e.g., Exchange) or by administrators publishing the application on various locations under different names and passing these names to the right clients. For clients that permanently remain in one location, this workaround usually works quite well, but with frequent relocations, things often go wrong. Additionally, web services make it difficult to manage multiple names, for example, because SSL certificates must be issued in different names and if wildcard certificates are not available.

Policy-Based DNS

Windows Server 2016 gives you a tool – policy-based DNS – that lets you provide DNS resolution with the utmost flexibility. The possible applications of policy-based name resolution go far beyond geographically based load balancing and also help you increase the security of your entire IT landscape.

Consider a practical example: A company (call it "Contoso," in the typical Microsoft way) with offices in Germany, Japan, and Canada has decided to introduce an internal web-based collaboration platform. The client farm is made up of corporate and private devices, including smartphones and tablets, because employees love to make use of the bring-your-own-device policy. Centralized management of devices using Group Policy is therefore impossible, and you cannot issue trusted internal certificates. To tackle these challenges, you use the name of the public company's website www.contoso.com for the internal collaboration platform. A high-quality SSL certificate by a large provider, which all devices trust, already exists. However, this is also the namespace of the company's AD domain. DNS is provided exclusively on domain controllers (DCs), and you want to keep it this way, if possible.

The original plan to operate the entire platform at the Canadian data center had to be revised in the pilot phase because the latency of the WAN links to the other locations affected usability. This results in the following requirements:

• The German web server farm (10.0.101.99) must be reached from all productive network segments of the German site under www.contoso.com .
• The same applies for the Canadian (10.0.102.99) and Japanese (10.0.103.99) locations.
• From the guest networks, www.contoso.com must resolve to the public IP address 40.84.199.233.

This challenge can be solved with policy-based DNS in just a few steps, but to do so, you need PowerShell with DNS and AD modules (e.g., on a DC), which needs to be launched with increased rights. First, define the default entry for www.contoso.com :

> Add-DnsServerResourceRecordA -Name "www" -ZoneName "contoso.com" -IPv4Address "40.84.199.233"

Now place the client subnets on all domain controllers (Listing 1).

> $dcs = (Get-ADDomainController -Filter *).Name
> foreach ($dc in $dcs) {
    Add-DnsServerClientSubnet -Name "DE-Prod" -IPv4Subnet "10.0.101.0/24" -ComputerName $dc
    Add-DnsServerClientSubnet -Name "CA-Prod" -IPv4Subnet "10.0.102.0/24" -ComputerName $dc
    Add-DnsServerClientSubnet -Name "JP-Prod" -IPv4Subnet "10.0.103.0/24" -ComputerName $dc
  }

Depending on which client subnet the request comes from, the DNS server must give different answers. For this purpose, a so-called "zone scope" is necessary in the DNS zone contoso.com for each site:

> Add-DnsServerZoneScope -ZoneName "contoso.com" -Name "DE"
> Add-DnsServerZoneScope -ZoneName "contoso.com" -Name "CA"
> Add-DnsServerZoneScope -ZoneName "contoso.com" -Name "JP"

Now, add an A record for www.contoso.com with the respective IP address to each zone scope (Listing 2). To establish the location dependency, you will be defining three DNS policies that must be rolled out individually on each server (Listing 3).

> Add-DnsServerResourceRecordA -Name "www" -ZoneName "contoso.com" -ZoneScope "DE" -IPv4Address "10.0.101.99"
> Add-DnsServerResourceRecordA -Name "www" -ZoneName "contoso.com" -ZoneScope "CA" -IPv4Address "10.0.102.99"
> Add-DnsServerResourceRecordA -Name "www" -ZoneName "contoso.com" -ZoneScope "JP" -IPv4Address "10.0.103.99"

> $dcs = (Get-ADDomainController-Filter *).Name
> foreach ($dc in $dcs) {
    Add-DnsServerQueryResolutionPolicy -Name "Client Subnet DE" -ClientSubnet "EQ,DE-Prod" -ZoneName "contoso.com" -ZoneScope "DE,1" -Action ALLOW -ComputerName $dc
    Add-DnsServerQueryResolutionPolicy -Name "Client Subnet CA" -ClientSubnet "EQ,CA-Prod" -ZoneName "contoso.com" -ZoneScope "CA,1" -Action ALLOW -ComputerName $dc
    Add-DnsServerQueryResolutionPolicy -Name "Client Subnet JP" -ClientSubnet "EQ,JP-Prod" -ZoneName "contoso.com" -ZoneScope "JP,1" -Action ALLOW -ComputerName $dc
  }

From now on, the response from the respective zone scope is returned for requests from the individual production client subnets, even if a DNS server from the "wrong" location is requested. Clients from all other subnets (thus, also those on guest networks) receive a response from the default scope.

System Internal Processes

If you were now to take a look at the DNS management console, you would probably not find any trace of the recently executed action. Indeed, client subnets, zone scopes, and DNS policies can be managed exclusively in PowerShell. To see where the zone scopes with their respective entries are stored, use AdsiEdit.msc to connect to the name context,

DC=DomainDNSZones,DC=contoso,DC=com

as shown in Figure 1. However, even a file-based DNS zone can include zone scopes. The scope data is here, along with the zone, with the same name as the subdirectory: C:\Windows\System32\DNS\ (Figure 2).

Figure 1: Zone scopes with their respective entries hide in the system and only show up when using ADSI Edit.

Figure 2: File-based DNS zones store their zone scope data in a subdirectory of C:\Windows\System32\.

The files have the default DNS format and both the zone scope container in AD and the subdirectory in the DNS folder will only be created if a zone scope is created for the zone. However, the zone scopes of a file-based DNS zone will not be transmitted, even between two Windows Server 2016 machines. If you really want to assign zone scopes to file-based zones, you need to manage the zone scopes and their respective records separately on each server or transfer the scope files from the master server by some other means. In each case, however, you need to create the zone scope for each server; otherwise, the files are not found (Figure 3).

Figure 3: Zone scopes must be created separately on each server.

The client subnets and DNS policies are only ever stored by the server and in the registry branch HKLM\Software\Microsoft\Windows NT\CurrentVersion\DNS Server\. The names of keys and values and the content of the registry entries are available here and therefore allow inventory, documentation, and diagnostics using tried and trusted tools if no tools geared specifically to policy-based DNS are available.

How DNS Policies Work

The operating principles of DNS policies are more like firewall rules than Group Policy. For one thing, only the first policy for which all conditions apply actually works. For another, the DNS policies do not configure any settings; they only decide whether the DNS server responds to the request (ALLOW), ignores it (IGNORE), or refuses a response (DENY). The response returned in the above example for the IPv4 address to the request for www.contoso.com is included in the DNS configuration. Therefore, the DNS policies for each standards-compliant DNS client are completely transparent.

To plan and implement your DNS policies optimally, you need to know these simple rules, which the policies follow:

• When a DNS request is received, the policies at server level are first checked in the order in which they were defined (-ProcessingOrder). If all the conditions of a policy apply, it is used, and processing is complete. Because at this moment it is not yet ensured that the server actually hosts the requested zone, server-level policies can only have DENY or IGNORE as a result.
• If none of the server-level policies apply, the requested DNS zone comes into play. If the server is authoritative for this zone, the zone-level policies are checked and executed if the conditions are met. If the server is not authoritative, it will answer the request.
• Conditions within a policy are ANDed by default. In other words,

-ClientSubnet 'EQ,JP-Guest' -QueryType 'NE,SRV'

will apply to all requests that come from the JP-Guest subnet and are not of the SRV type. If you want to change this behavior, and OR the criteria of different types, use the -Condition parameter, which accepts the values AND (default) and OR.

• Each condition has to include one or both of the EQ,value1,value2,… or NE,value1,value2,… expressions. The possible values in the EQ clause are ANDed (condition applies if none of the NE values fit). Whereas, values within the NE clause are ANDed (condition applies if none of the NE values fit).
• Multiple policies on the same level (i.e., server level or in the same zone) need to have different rank numbers (processing order). If you add a new policy and specify an assigned rank number, your new policy receives the requested processing order, and existing policies in the ranking move down a slot.

You can use the following types of criteria to control the behavior of your DNS server: client subnet, transport protocol (TCP or UDP), Internet protocol (IPv4 or IPv6), IP address of the DNS server (if it listens on multiple interfaces), fully qualified domain name (FQDN) of the request (wildcards are allowed at the beginning, e.g., *.contoso.com ), type of request (A, TXT, SRV, MX, etc.), and the time in the local time zone of the DNS server. The individual criteria are described in detail on TechNet [1].