What’s New in DNS Server in Windows Server

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

This topic describes the Domain Name System (DNS) server functionality that is new or changed in Windows Server 2016.

In Windows Server 2016, DNS Server offers enhanced support in the following areas.

Functionality	New or Improved	Description
DNS Policies	New	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.
Response Rate Limiting (RRL)	New	You can enable response rate limiting on your DNS servers. By doing this, you avoid the possibility of malicious systems using your DNS servers to initiate a denial of service attack on a DNS client.
DNS-based Authentication of Named Entities (DANE)	New	You can use TLSA (Transport Layer Security Authentication) records to provide information to DNS clients that state what CA they should expect a certificate from for your domain name. This prevents man-in-the-middle attacks where someone might corrupt the DNS cache to point to their own website, and provide a certificate they issued from a different CA.
Unknown record support	New	You can add records which are not explicitly supported by the Windows DNS server using the unknown record functionality.
IPv6 root hints	New	You can use the native IPV6 root hints support to perform internet name resolution using the IPV6 root servers.
Windows PowerShell Support	Improved	New Windows PowerShell cmdlets are available for DNS Server.

DNS Policies

You can use DNS Policy for Geo-Location based traffic management, intelligent DNS responses based on the time of day, to manage a single DNS server configured for split-brain deployment, applying filters on DNS queries, and more. The following items provide more detail about these capabilities.

Application Load Balancing. When you have deployed multiple instances of an application at different locations, you can use DNS policy to balance the traffic load between the different application instances, dynamically allocating the traffic load for the application.

Geo-Location Based Traffic Management. You can use DNS Policy to allow primary and secondary DNS servers to respond to DNS client queries based on the geographical location of both the client and the resource to which the client is attempting to connect, providing the client with the IP address of the closest resource.

Split Brain DNS. With split-brain DNS, DNS records are split into different Zone Scopes on the same DNS server, and DNS clients receive a response based on whether the clients are internal or external clients. You can configure split-brain DNS for Active Directory integrated zones or for zones on standalone DNS servers.

Filtering. You can configure DNS policy to create query filters that are based on criteria that you supply. Query filters in DNS policy allow you to configure the DNS server to respond in a custom manner based on the DNS query and DNS client that sends the DNS query.

Forensics. You can use DNS policy to redirect malicious DNS clients to a non-existent IP address instead of directing them to the computer they are trying to reach.

Time of day based redirection. You can use DNS policy to distribute application traffic across different geographically distributed instances of an application by using DNS policies that are based on the time of day.

You can also use DNS policies for Active Directory integrated DNS zones.

For more information, see the DNS Policy Scenario Guide.

Response Rate Limiting

You can configure RRL settings to control how to respond to requests to a DNS client when your server receives several requests targeting the same client. By doing this, you can prevent someone from sending a Denial of Service (Dos) attack using your DNS servers. For instance, a bot net can send requests to your DNS server using the IP address of a third computer as the requestor. Without RRL, your DNS servers might respond to all the requests, flooding the third computer. When you use RRL, you can configure the following settings:

Responses per second. This is the maximum number of times the same response will be given to a client within one second.

Errors per second. This is the maximum number of times an error response will be sent to the same client within one second.

Window. This is the number of seconds for which responses to a client will be suspended if too many requests are made.

Leak rate. This is how frequently the DNS server will respond to a query during the time responses are suspended. For instance, if the server suspends responses to a client for 10 seconds, and the leak rate is 5, the server will still respond to one query for every 5 queries sent. This allows the legitimate clients to get responses even when the DNS server is applying response rate limiting on their subnet or FQDN.

TC rate. This is used to tell the client to try connecting with TCP when responses to the client are suspended. For instance, if the TC rate is 3, and the server suspends responses to a given client, the server will issue a request for TCP connection for every 3 queries received. Make sure the value for TC rate is lower than the leak rate, to give the client the option to connect via TCP before leaking responses.

Maximum responses. This is the maximum number of responses the server will issue to a client while responses are suspended.

Allowlist domains. This is a list of domains to be excluded from RRL settings.

Allowlist subnets. This is a list of subnets to be excluded from RRL settings.

Allowlist server interfaces. This is a list of DNS server interfaces to be excluded from RRL settings.

DANE support

You can use DANE support (RFC 6394 and 6698) to specify to your DNS clients what CA they should expect certificates to be issued from for domains names hosted in your DNS server. This prevents a form of man-in-the-middle attack where someone is able to corrupt a DNS cache and point a DNS name to their own IP address.

For instance, imagine you host a secure website that uses SSL at www.contoso.com by using a certificate from a well-known authority named CA1. Someone might still be able to get a certificate for www.contoso.com from a different, not-so-well-known, certificate authority named CA2. Then, the entity hosting the fake www.contoso.com website might be able to corrupt the DNS cache of a client or server to point www.contoto.com to their fake site. The end user will be presented a certificate from CA2, and may simply acknowledge it and connect to the fake site. With DANE, the client would make a request to the DNS server for contoso.com asking for the TLSA record and learn that the certificate for www.contoso.com was issues by CA1. If presented with a certificate from another CA, the connection is aborted.

Unknown record support

An «Unknown Record» is an RR whose RDATA format is not known to the DNS server. The newly added support for unknown record (RFC 3597) types means that you can add the unsupported record types into the Windows DNS server zones in the binary on-wire format. The windows caching resolver already has the ability to process unknown record types. Windows DNS server will not do any record specific processing for the unknown records, but will send it back in responses if queries are received for it.

IPv6 root hints

The IPV6 root hints, as published by IANA, have been added to the windows DNS server. The internet name queries can now use IPv6 root servers for performing name resolutions.

Windows PowerShell support

The following new Windows PowerShell cmdlets and parameters are introduced in Windows Server 2016.

Add-DnsServerRecursionScope. This cmdlet creates a new recursion scope on the DNS server. Recursion scopes are used by DNS policies to specify a list of forwarders to be used in a DNS query.

Remove-DnsServerRecursionScope. This cmdlet removes existing recursion scopes.

Set-DnsServerRecursionScope. This cmdlet changes the settings of an existing recursion scope.

Get-DnsServerRecursionScope. This cmdlet retrieves information about existing recursion scopes.

Add-DnsServerClientSubnet. This cmdlet creates a new DNS client subnet. Subnets are used by DNS policies to identify where a DNS client is located.

Remove-DnsServerClientSubnet. This cmdlet removes existing DNS client subnets.

Set-DnsServerClientSubnet. This cmdlet changes the settings of an existing DNS client subnet.

Get-DnsServerClientSubnet. This cmdlet retrieves information about existing DNS client subnets.

Add-DnsServerQueryResolutionPolicy. This cmdlet creates a new DNS query resolution policy. DNS query resolution policies are used to specify how, or if, a query is responded to, based on different criteria.

Remove-DnsServerQueryResolutionPolicy. This cmdlet removes existing DNS policies.

Set-DnsServerQueryResolutionPolicy. This cmdlet changes the settings of an existing DNS policy.

Get-DnsServerQueryResolutionPolicy. This cmdlet retrieves information about existing DNS policies.

Enable-DnsServerPolicy. This cmdlet enables existing DNS policies.

Disable-DnsServerPolicy. This cmdlet disables existing DNS policies.

Add-DnsServerZoneTransferPolicy. This cmdlet creates a new DNS server zone transfer policy. DNS zone transfer policies specify whether to deny or ignore a zone transfer based on different criteria.

Remove-DnsServerZoneTransferPolicy. This cmdlet removes existing DNS server zone transfer policies.

Set-DnsServerZoneTransferPolicy. This cmdlet changes settings of an existing DNS server zone transfer policy.

Get-DnsServerResponseRateLimiting. This cmdlet retrieves RRL settings.

Set-DnsServerResponseRateLimiting. This cmdlet changes RRL settigns.

Add-DnsServerResponseRateLimitingExceptionlist. This cmdlet creates an RRL exception list on the DNS server.

Get-DnsServerResponseRateLimitingExceptionlist. This cmdlet retrieves RRL excception lists.

Remove-DnsServerResponseRateLimitingExceptionlist. This cmdlet removes an existing RRL exception list.

Set-DnsServerResponseRateLimitingExceptionlist. This cmdlet changes RRL exception lists.

Add-DnsServerResourceRecord. This cmdlet was updated to support unknown record type.

Get-DnsServerResourceRecord. This cmdlet was updated to support unknown record type.

Remove-DnsServerResourceRecord. This cmdlet was updated to support unknown record type.

Set-DnsServerResourceRecord. This cmdlet was updated to support unknown record type

For more information, see the following Windows Server 2016 Windows PowerShell command reference topics.

DNS Policies Overview

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can use this topic to learn about DNS Policy, which is new in Windows Server 2016. You can use DNS Policy for Geo-Location based traffic management, intelligent DNS responses based on the time of day, to manage a single DNS server configured for split-brain deployment, applying filters on DNS queries, and more. The following items provide more detail about these capabilities.

Application Load Balancing. When you have deployed multiple instances of an application at different locations, you can use DNS policy to balance the traffic load between the different application instances, dynamically allocating the traffic load for the application.

Geo-Location Based Traffic Management. You can use DNS Policy to allow primary and secondary DNS servers to respond to DNS client queries based on the geographical location of both the client and the resource to which the client is attempting to connect, providing the client with the IP address of the closest resource.

Split Brain DNS. With split-brain DNS, DNS records are split into different Zone Scopes on the same DNS server, and DNS clients receive a response based on whether the clients are internal or external clients. You can configure split-brain DNS for Active Directory integrated zones or for zones on standalone DNS servers.

Filtering. You can configure DNS policy to create query filters that are based on criteria that you supply. Query filters in DNS policy allow you to configure the DNS server to respond in a custom manner based on the DNS query and DNS client that sends the DNS query.

Forensics. You can use DNS policy to redirect malicious DNS clients to a non-existent IP address instead of directing them to the computer they are trying to reach.

Time of day based redirection. You can use DNS policy to distribute application traffic across different geographically distributed instances of an application by using DNS policies that are based on the time of day.

New Concepts

In order to create policies to support the scenarios listed above, it is necessary to be able to identify groups of records in a zone, groups of clients on a network, among other elements. These elements are represented by the following new DNS objects:

Client subnet: a client subnet object represents an IPv4 or IPv6 subnet from which queries are submitted to a DNS server. You can create subnets to later define policies to be applied based on what subnet the requests come from. For instance, in a split brain DNS scenario, the request for resolution for a name such as www.microsoft.com can be answered with an internal IP address to clients from internal subnets, and a different IP address to clients in external subnets.

Recursion scope: recursion scopes are unique instances of a group of settings that control recursion on a DNS server. A recursion scope contains a list of forwarders and specifies whether recursion is enabled. A DNS server can have many recursion scopes. DNS server recursion policies allow you to choose a recursion scope for a set of queries. If the DNS server is not authoritative for certain queries, DNS server recursion policies allow you to control how to resolve those queries. You can specify which forwarders to use and whether to use recursion.

Zone scopes: a DNS zone can have multiple zone scopes, with each zone scope containing their own set of DNS records. The same record can be present in multiple scopes, with different IP addresses. Also, zone transfers are done at the zone scope level. That means that records from a zone scope in a primary zone will be transferred to the same zone scope in a secondary zone.

Types of Policy

DNS Policies are divided by level and type. You can use Query Resolution Policies to define how queries are processed, and Zone Transfer Policies to define how zone transfers occur. You can apply Each policy type at the server level or the zone level.

Query Resolution Policies

You can use DNS Query Resolution Policies to specify how incoming resolution queries are handled by a DNS server. Every DNS Query Resolution Policy contains the following elements:

Field	Description	Possible values
Name	Policy name	— Up to 256 characters — Can contain any character valid for a file name
State	Policy state	— Enable (default) — Disabled
Level	Policy level	— Server — Zone
Processing order	Once a query is classified by level and applies on, the server finds the first policy for which the query matches the criteria and applies it to query	— Numeric value — Unique value per policy containing the same level and applies on value
Action	Action to be performed by DNS server	— Allow (default for zone level) — Deny (default on server level) — Ignore
Criteria	Policy condition (AND/OR) and list of criterion to be met for policy to be applied	— Condition operator (AND/OR) — List of criteria (see the criterion table below)
Scope	List of zone scopes and weighted values per scope. Weighted values are used for load balancing distribution. For instance, if this list includes datacenter1 with a weight of 3 and datacenter2 with a weight of 5 the server will respond with a record from datacentre1 three times out of eight requests	— List of zone scopes (by name) and weights

Server level policies can only have the values Deny or Ignore as an action.

The DNS policy criteria field is composed of two elements:

Name	Description	Sample values
Client Subnet	Name of a predefined client subnet. Used to verify the subnet from which the query was sent.	— EQ,Spain,France — resolves to true if the subnet is identified as either Spain or France — NE,Canada,Mexico — resolves to true if the client subnet is any subnet other than Canada and Mexico
Transport Protocol	Transport protocol used in the query. Possible entries are UDP and TCP	— EQ,TCP — EQ,UDP
Internet Protocol	Network protocol used in the query. Possible entries are IPv4 and IPv6	— EQ,IPv4 — EQ,IPv6
Server Interface IP address	IP address for the incoming DNS server network interface	— EQ,10.0.0.1 — EQ,192.168.1.1
FQDN	FQDN of record in the query, with the possibility of using a wild card	— EQ,www.contoso.com — resolves to true only the if the query is trying to resolve the www.contoso.com FQDN — EQ,*.contoso.com,*.woodgrove.com — resolves to true if the query is for any record ending in contoso.comORwoodgrove.com
Query Type	Type of record being queried (A, SRV, TXT)	— EQ,TXT,SRV — resolves to true if the query is requesting a TXT OR SRV record — EQ,MX — resolves to true if the query is requesting an MX record
Time of Day	Time of day the query is received	— EQ,10:00-12:00,22:00-23:00 — resolves to true if the query is received between 10 AM and noon, OR between 10PM and 11PM

Using the table above as a starting point, the table below could be used to define a criterion that is used to match queries for any type of records but SRV records in the contoso.com domain coming from a client in the 10.0.0.0/24 subnet via TCP between 8 and 10 PM through interface 10.0.0.3:

Name	Value
Client Subnet	EQ,10.0.0.0/24
Transport Protocol	EQ,TCP
Server Interface IP address	EQ,10.0.0.3
FQDN	EQ,*.contoso.com
Query Type	NE,SRV
Time of Day	EQ,20:00-22:00

You can create multiple query resolution policies of the same level, as long as they have a different value for the processing order. When multiple policies are available, the DNS server processes incoming queries in the following manner:

Recursion Policies

Recursion policies are a special type of server level policies. Recursion policies control how the DNS server performs recursion for a query. Recursion policies apply only when query processing reaches the recursion path. You can choose a value of DENY or IGNORE for recursion for a set of queries. Alternatively, you can choose a set of forwarders for a set of queries.

You can use recursion policies to implement a Split-brain DNS configuration. In this configuration, the DNS server performs recursion for a set of clients for a query, while the DNS server does not perform recursion for other clients for that query.

Recursion policies contains the same elements a regular DNS query resolution policy contains, along with the elements in the table below:

Name	Description
Apply on recursion	Specifies that this policy should only be used for recursion.
Recursion Scope	Name of the recursion scope.

Recursion policies can only be created at the server level.

Zone Transfer Policies

Zone transfer policies control whether a zone transfer is allowed or not by your DNS server. You can create policies for zone transfer at either the server level or the zone level. Server level policies apply on every zone transfer query that occurs on the DNS server. Zone level policies apply only on the queries on a zone hosted on the DNS server. The most common use for zone level policies is to implement blocked or safe lists.

Zone transfer policies can only use DENY or IGNORE as actions.

You can use the server level zone transfer policy below to deny a zone transfer for the contoso.com domain from a given subnet:

You can create multiple zone transfer policies of the same level, as long as they have a different value for the processing order. When multiple policies are available, the DNS server processes incoming queries in the following manner:

Managing DNS Policies

You can create and manage DNS Policies by using PowerShell. The examples below go through different sample scenarios that you can configure through DNS Policies:

Traffic Management

You can direct traffic based on an FQDN to different servers depending on the location of the DNS client. The example below shows how to create traffic management policies to direct the customers from a certain subnet to a North American datacenter and from another subnet to a European datacenter.

The first two lines of the script create client subnet objects for North America and Europe. The two lines after that create a zone scope within the contoso.com domain, one for each region. The two lines after that create a record in each zone that associates ww.contoso.com to different IP address, one for Europe, another one for North America. Finally, the last lines of the script create two DNS Query Resolution Policies, one to be applied to the North America subnet, another to the Europe subnet.

Block queries for a domain

You can use a DNS Query Resolution Policy to block queries to a domain. The example below blocks all queries to treyresearch.net:

Block queries from a subnet

You can also block queries coming from a specific subnet. The script below creates a subnet for 172.0.33.0/24 and then creates a policy to ignore all queries coming from that subnet:

Allow recursion for internal clients

You can control recursion by using a DNS Query Resolution Policy. The sample below can be used to enable recursion for internal clients, while disabling it for external clients in a split brain scenario.

The first line in the script changes the default recursion scope, simply named as «.» (dot) to disable recursion. The second line creates a recursion scope named InternalClients with recursion enabled. And the third line creates a policy to apply the newly create recursion scope to any queries coming in through a server interface that has 10.0.0.34 as an IP address.

Create a server level zone transfer policy

You can control zone transfer in a more granular form by using DNS Zone Transfer policies. The sample script below can be used to allow zone transfers for any server on a given subnet:

The first line in the script creates a subnet object named AllowedSubnet with the IP block 172.21.33.0/24. The second line creates a zone transfer policy to allow zone transfers to any DNS server on the subnet previously created.

Create a zone level zone transfer policy

You can also create zone level zone transfer policies. The example below ignores any request for a zone transfer for contoso.com coming in from a server interface that has an IP address of 10.0.0.33:

DNS Policy Scenarios

For information on how to use DNS policy for specific scenarios, see the following topics in this guide.

Using DNS Policy on Read-Only Domain Controllers

DNS Policy is compatible with Read-Only Domain Controllers. Do note that a restart of the DNS Server service is required for new DNS Policies to be loaded on Read-Only Domain Controllers. This is not necessary on writable domain controllers.