Introducing DNS Policies in Windows Server 2016 Technical Preview 2

In this article, we will have a look at DNS Policies – a new feature in the DNS Server role introduced in Windows Server 2016 Technical Preview 2 (TP2):

You can configure DNS policies to specify how a DNS server responds to DNS queries. DNS responses can be based on client IP address (location), time of the day, and several other parameters. DNS policies enable location-aware DNS, traffic management, load balancing, split-brain DNS, and other scenarios.

In the Technical Preview, DNS Policies can be managed through PowerShell only. Whether the feature will be manageable from the DNS Server MMC-console or any other GUI tools is currently unknown, but as Jeffrey Snover stated on Twitter recently, PowerShell management is created before layering a GUI later on for most new things in Windows Server:


Before we can demonstrate the new feature, we must first install the DNS Server role and create a zone on a computer running Windows Server 2016 TP2:

# Install DNS Server
Install-WindowsFeature -Name DNS

# List all DNS policy cmdlets
Get-Command -Module DnsServer -Name *policy*

# Update help for the DnsServer module; the help files already have a lot of content and examples
Update-Help -Module DnsServer

# Create a test zone
Add-DnsServerPrimaryZone -Name powershell.no -ZoneFile powershell.no.dns

Next we create traffic management policies:

# The first two commands create client subnets by using the Add-DnsServerClientSubnet cmdlet. The client subnets are for clients in Oslo and clients in Trondheim.
Add-DnsServerClientSubnet -Name OsloSubnet -IPv4Subnet "" -PassThru
Add-DnsServerClientSubnet -Name TrondheimSubnet -IPv4Subnet "" -PassThru


# The next two commands create zone scopes for Oslo and Trondheim by using the Add-DnsServerZoneScope cmdlet.
Add-DnsServerZoneScope -ZoneName powershell.no -Name "OsloZoneScope" -PassThru
Add-DnsServerZoneScope -ZoneName powershell.no -Name "TrondheimZoneScope" -PassThru


# The next two commands add resource records for the zone powershell.no by using the Add-DnsServerResourceRecord cmdlet.
# The name for both records is the same, staging, but the two records point to different addresses. The records also have different scopes.
Add-DnsServerResourceRecord -ZoneName powershell.no -A -Name staging -IPv4Address "" -ZoneScope "OsloZoneScope" -PassThru
Add-DnsServerResourceRecord -ZoneName powershell.no -A -Name staging -IPv4Address "" -ZoneScope "TrondheimZoneScope" -PassThru


# The final two commands create two policies. The policies allow queries for members of different subnets.
# The policies differ in scope, so that some clients receive one response to a query, while other clients receive a different response to the same query.
Add-DnsServerQueryResolutionPolicy -Name "OsloPolicy" -Action ALLOW -ClientSubnet "eq,OsloSubnet" -ZoneScope "OsloZoneScope,1" -ZoneName powershell.no -PassThru
Add-DnsServerQueryResolutionPolicy -Name "TrondheimPolicy" -Action ALLOW -ClientSubnet "eq,TrondheimSubnet" -ZoneScope "TrondheimZoneScope,1" -ZoneName powershell.no -PassThru


Now we are ready to test if the new policies work as desired. First, we must configure the computers used for testing to use the Windows Server 2016 TP2 DNS Server for DNS queries:

Set-DnsClientServerAddress -InterfaceAlias Ethernet -ServerAddresses

And then, we’ll use Resolve-DnsName from a computer in the Oslo subnet (


Next, we`re doing the same DNS query from a computer in the Trondheim subnet (


As we can see, the expected IP addresses are returned in both scenarios.

Let’s also test another available scenario–Time of the day.

First, we modify the OsloPolicy to apply in a restricted time:

Set-DnsServerQueryResolutionPolicy -Name "OsloPolicy" -ZoneName powershell.no -TimeOfDay "EQ,22:10-23:00" -PassThru

Then we create a function for testing purposes, which will clear the DNS client cache, output the current time and perform a DNS query.

function Test-DnsName {



	Resolve-DnsName -Name $Name


Test-DnsName -Name staging.powershell.no

When running Test-DnsName before the allowed time of day we get an error stating that the DNS name does not exist, while after the allowed time of day the query returns the desired result:


This concludes our introduction to DNS Policies in Windows Server 2016, a feature that will be very useful in real world scenarios when it becomes available for production use.


What’s New in DNS Server in Windows Server Technical Preview (TechNet)

Domain Name System (DNS) Server Cmdlets (MSDN)

Filed in: Articles Tags: 

One Response to "Introducing DNS Policies in Windows Server 2016 Technical Preview 2"

Leave a Reply

Submit Comment

© 2017 PowerShell Magazine. All rights reserved. XHTML / CSS Valid.
Proudly designed by Theme Junkie.
%d bloggers like this: