Lead Image © mikiel, 123RF.com

Lead Image © mikiel, 123RF.com

Policy-based DNS in Windows Server 2016

High Resolution

Article from ADMIN 42/2017
Inflexible DNS name resolution was solved in Windows Server 2016, thanks to policy-based DNS.

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 ( must be reached from all productive network segments of the German site under www.contoso.com .
  • The same applies for the Canadian ( and Japanese ( locations.
  • From the guest networks, www.contoso.com must resolve to the public IP address

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 ""

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

Listing 1

Placing Client Subnets on DCs

> $dcs = (Get-ADDomainController -Filter *).Name
> foreach ($dc in $dcs) {
    Add-DnsServerClientSubnet -Name "DE-Prod" -IPv4Subnet "" -ComputerName $dc
    Add-DnsServerClientSubnet -Name "CA-Prod" -IPv4Subnet "" -ComputerName $dc
    Add-DnsServerClientSubnet -Name "JP-Prod" -IPv4Subnet "" -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).

Listing 2

Adding Records to Zone Scopes

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

Listing 3

Defining DNS Policies

> $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,


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].

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Resolving problems with DNS, Active Directory, and Group Policy
    Upgrading domain controllers or installing new servers can cause problems with name resolution, Active Directory replication, and Group Policy. A coordinated approach can isolate these errors in Windows Server 2008 or newer.
  • Setting up and managing IPv6 on Windows Server 2016
    Windows Server 2016 automatically prefers IPv6 addresses, if available, but the manual configuration steps differ from IPv4 and necessitate new tools. Here's how to approach IPv6 in your daily admin work.
  • Correctly integrating containers
    If you run microservices in containers, they are forced to communicate with each other – and with the outside world. We explain how to network pods and nodes in Kubernetes.
  • Hands-on Exchange rights management
    Exchange Server 2013 provides a comprehensive, role-based rights management feature. Rights and roles can be managed in the Exchange console, with PowerShell, or with additional tools. We demonstrate all three options.
  • Migrating your network to IPv6
    Abraham Lincoln once said, "Give me six hours to chop down a tree and I will spend the first four sharpening the axe." The transition to IPv6 is a big step for many organizations. Careful planning and a systematic approach are critical to a successful migration.
comments powered by Disqus