In the previous post, Controlling Home Lab DNS Resolution with Windows Server 2016, we looked briefly at the benefits of running Windows Server 2016 DNS server in a home lab environment and why you would want to do that. Looking a bit further, with the new DNS Policy that is available in Windows Server 2016 DNS Server, we can do some really interesting things to control name resolution in an environment. One of the interesting things to me at first glance was the ability to control which network objects can run queries against your DNS server as well as which zones they have access to. Let’s take a look a how to topic – Windows Server 2016 DNS Policy Deny Subnet Access to Zone and how we can easily accomplish this with the new DNS policy objects.
Windows Server 2016 DNS Policy Deny Subnet Access to Zone
In the previous post it was mentioned about the various use cases that you can apply DNS level policies. Among those including policies to ensure high availability, traffic management, but the one that caught my eye was filtering. So we can filter DNS queries based on certain criteria.
A use case that came to mind for me was filtering traffic from a high risk subnet, such as a DMZ subnet range. Most of the examples in Technet show filtering for reasons such as malware infection, etc and blocking these subnets entirely. However, I wanted to do something more interesting – block only traffic from a risky subnet to a certain zone.
If I have a DMZ subnet that I want to allow to utilize an internal DNS server for certain records, but not see an entire internal zone that houses other resources that we do not want the DMZ range to have access to. Or I may only want to use the DNS server for recursive queries and block any internal queries, can we do that with DNS policy? Yes.
Creating the Policy
Creating DNS Policy in Windows Server 2016 can only be done with Powershell. There is no way in the DNS management console to do this as far as I have found. There are a couple of new powershell commandlets for Windows Server 2016 DNS Policy that we are interested in.
The first thing we have to do with Powershell is define our ClientSubnet that we want to identify for filtering. We can do that with the add-dnsserverclientsubnet commandlet. The following commandlet is intuitive – basically we define the name and the IP range for the clientsubnet parameter.
add-dnsserverclientsubnet -Name "DMZ" -IPv4Subnet 192.168.99.0/24 -Passthru
After adding the clientsubnet, we can now define the policy we want to invoke. I have an internal DNS scope called cloud.local housing internal records. I want to filter any queries coming from the DMZ range defined above from being able to pull name resolution for the cloud.local scope. To do that, we create the policy using the add-dnsserverqueryresolutionpolicy commandlet. We name the policy, define the zonename that we want to deny access to,
add-DnsServerQueryResolutionPolicy -Name "BlockDMZfromInternalScope" -ZoneName "cloud.local" -Action DENY -ClientSubnet "eq,DMZ" -PassThru
Now the policy is in place, let’s look at the behavior from a “DMZ” client. If I run an nslookup now we see the following:
We see above, we now get a Query refused when trying to perform nslookup on our internal domain. Also, notice in pinging a known host in the cloud.local domain, we don’t get an IP address, we only get a could not find host reply.
DENY vs IGNORE
I was curious about the behavior of a DENY policy vs an IGNORE policy. We easily see the difference in the nslookup reply. The IGNORE action drops the request. So on the client side, you see a timeout.
If you want to remove the policy you put in place, you first have to remove the policy and then the subnet if you wish to remove it also. You can’t delete the subnet before the policy as you will receive an error.
For a zone policy that we used above, you use the remove-DnsServerQueryResolutionPolicy commandlet.
remove-dnsserverqueryresolutionpolicy -Name "BlockDMZfromInternalScope" -ZoneName "cloud.local"
Then, to remove the clientsubnet you use the remove-DnsServerClientSubnet commandlet like so:
remove-dnsserverclientsubnet -Name "DMZ"
With the new DNS policy functionality we can effectively use Windows Server 2016 DNS Policy Deny Subnet Access to Zone for this use case and many others that can be thought up. This includes altering DNS responses based on time of day, client subnet, zone, high availability, and others. The policy features with Windows Server 2016 DNS really add a new dimension in controlling DNS in the enterprise.