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.