Policy-based DNS in Windows Server 2016

High Resolution

Policies for Recursion

As we have already seen, the DNS policies only affect the server on which they are defined. However, in an internal Windows network, it is often the case that a DNS server can only respond to a small number of queries that are addressed to it. Instead, it forwards them to other servers, which are defined as forwarders for the respective zone or globally.

To control this behavior for a DNS server based on Windows Server 2016, you use policies. You can configure a DNS server so that it does not respond to requests for addresses from the facebook.com zone on production networks like this:

> Add-DnsServerQueryResolutionPolicy "Deny FB to production" -Action DENY -ApplyOnRecursion -Fqdn "EQ,*.facebook.com" -ClientSubnet "EQ,DE-Prod,CA-Prod,JP-Prod"

If you want to establish a sort of honeypot process and forward requests that meet specific criteria to an alternative DNS server, you can use recursion scopes, which are handled like zone scopes and include three parameters: the name of the zone for which the recursion applies, a list of forwarding IPs, and the parameter -EnableRecursion, which determines whether recursion is allowed in this recursion scope.

The recursion scopes are also stored in the registry (HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters\ServerScopes) in a different branch from the zone scopes and the policies.

Zone Transfer Policies

Although it generally occurs less frequently than answering or forwarding name resolution requests, a Windows DNS sometimes has to transfer a request for a zone transfer. This type of interaction with other systems can also be controlled by policies and follows the exact same logic as name resolution policies.

You can define a zone transfer policy at the server or zone level and make it dependent on a wide variety of criteria, with one difference: You cannot use zone scopes to provide different versions of zones in the event of the zone transfer. The default scope is always transferred, provided the zone transfer is generally permitted by the policies.

Limited Manageability

At this point, the DNS policies can be managed exclusively by PowerShell, but if you are planning an extensive policy design in addition to client subnets, zone scopes, and recursion scopes, it can become confusing quickly.

A logical place for a DNS policies GUI would be in the IPAM features management console, which is based on Server Manager. One can only hope that Microsoft supplies a corresponding GUI. Unfortunately, a cmdlet for testing created policies is also missing – the community is likely to finish the development work faster than Microsoft in this case.

If you define and manage DNS policies with PowerShell, you must consider the following:

  • No new cmdlets have been created in the area of policy-based DNS. To create new objects, be it zone scopes, recursion scopes, client subnets, or policies, you need Add-Cmdlets.
  • The -ComputerName parameter only accepts one value for all cmdlets. If you want to create or change objects on multiple DNS servers (which is probably par for the course), you either need to use a loop (as in the earlier example) or resort to CIMSessions, with which you can transfer an entire array.
  • You can copy policy-based DNS objects from one server to another:
> Get-DNSServerClientSubnet -ComputerName SERVER1 | Add-DNSServerClientSubnet -ComputerName SERVER2

Note that all objects already have to exist on the destination server before you can refer to them. For example, if a policy has a subnet condition, all the client subnets included in the condition have to be created before creating the policy.

  • When DNS zones are stored in the AD, the zone scopes are transferred by AD replication, which can take some time, especially between different AD sites. Until the zone scopes have been replicated on a domain controller, you cannot create any policies that relate to them on the DC.

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.
  • Hybrid public/private cloud
    Extending your data center temporarily into the cloud during a customer rush might not be easy, but it can be done, thanks to Ansible's Playbooks and some AWS scripts.
comments powered by Disqus