Tip of the Day: More Uses for Windows Server 2016 DNS Policies – Selective Query Filtering


Today’s Tip…

The last Network Tip of the Day series introduced new Windows Server 2016 DNS Policy capabilities and included the following topics:

  • Have You Seen What You Can Do with Windows Server 2016 DNS Policies?
  • How DNS Policies Work
  • Configuring DNS Policies

Because there is so much more to know, why not continue our exploration of this new, very exciting capability?

The final tip of the last series introduced policy elements, and provided a configuration walkthrough for a basic Location Aware Response use-case scenario, whereby the originating network of the query was used to trigger policies to provide a custom response. The outcome of that scenario was to direct clients to a resource closest to their own physical location. The closer the resource, the lower the RTT, the better the overall user experience!

Selective Query Filters

Today, let’s look at another handy and much sought after use for DNS policies, the Selective Query Filter. Whereas the Location scenario was designed to return a response for a namespace for which the server was authoritative (e.g. it hosts zone data for the domain in question), selective filtering combines any of the available criteria (see tip of 1/21 for a refresher) to provide filtering actions for all manner of non-authoritative queries. Some example includes:

  • Block queries for known malicious domains
  • Create DNS policy whitelists
  • Block queries for specific record types
  • Allow queries only for certain record types
  • Block queries originating from a specific network(s)
  • Allow queries only from certain networks

Let’s look at some brief examples:

Block Queries for a Malicious Domain

Filtering-policies can block name queries for domains that have been identified as malicious or otherwise do not comply with the usage guidelines of the organization.  The following filter uses the -FQDN criteria to block any queries with the domain suffix “contosomalicious.com”.

Add-DnsServerQueryResolutionPolicy -Name "FQDNBlockPolicy" -Action IGNORE -FQDN "eq,*.contosomalicious.com“

The IGNORE action signifies that all queries will be silently dropped.

Also, note the use of the wildcard “*” in the policy expression, making the policy effective for all contosomalicous.com records and child domains.

Configure a DNS FQDN Allowed List

Filtering-policies can be used to create whitelists, limiting query responses to a specified domain(s).  The following filter only allows queries for resources in the “contoso.com” namespace. Again, the wildcard is used signify both top-level domain and child domain records.

Add-DnsServerQueryResolutionPolicy -Name "AllowedDomains" -Action IGNORE -FQDN "ne,*.contoso.com"

Note the use of the IGNORE action with the NE (not equal) operator to essentially reverse the logic of the previous example.

I should also note that, if you wanted to use a filter of this sort on a zone for which the server was authoritative, you would not want to implement the expression exactly as written above due to subtleties introduced by the policy evaluation process (which we will touch upon in an upcoming tip).

Block Specific Types of Queries

Filter-policies can be used to block specific types of queries, such as the ‘ANY’ query, which can be used by an evil-doer for nefarious purposes. The following filter blocks an ‘ANY’ query type.

Add-DnsServerQueryResolutionPolicy -Name "BlockedQType" -Action IGNORE -QType "eq,ANY“

You can substitute/add any of the other query types to this expression as needed.  For example, “eq,A,AAAA,SRV,MX”

Allow Only Certain Query Types

By reversing the logic of the last example, a filter-policy can be created to whitelist a set of record types.  The following filter combines the -QType criteria with the -ServerInterfaceIP criteria to only allows resolution of A, AAAA, MX, NS, & SOA records for queries received on server interface 172.17.2.1.

Add-DnsServerQueryResolutionPolicy -Name "WhiteListQType" -Action IGNORE -QType "ne,A,AAAA,MX,NS,SOA" –ServerInterfaceIP “eq,172.17.2.1”

Allow Queries Only From Specific Subnets

Filter-policies can be used to create an allowed-list policies designed to ignore all queries but those originating from a specific subnet(s). The following filter only allows queries originating from the subnet identified by “AllowedNetworks”.

Add-DnsServerClientSubnet -Name "AllowedNetworks" -IPv4Subnet 172.0.34.0/24

Add-DnsServerQueryResolutionPolicy -Name "AllowedListPolicy” -Action IGNORE -ClientSubnet  "ne, AllowedNetworks"

Note that this policy requires that a Client Subnet object be created to identify the list of networks. For an enjoyable little exercise, consider how you might modify the logic in this expression to create a policy that “blocks” queries for a specified list of networks.

One Final Practical Example

Let me leave you with a final practical example. Consider a scenario where clients on a specific subnet have been found to be infected by malware and are flooding DNS servers with queries of questionable intent. In such an event, a DNS policy can be quickly created to block queries from the infected network, thus relieving the load on the DNS server.

First, identify the network address on which the unfortunate clients reside and create the required subnet object.

Add-DnsServerClientSubnet -Name "InfectedClients" -IPv4Subnet 172.0.33.0/24

Add-DnsServerQueryResolutionPolicy -Name "BlackholeInfectedClients" -Action IGNORE -ClientSubnet "EQ,InfectedClients"

Now let’s suppose that, as helpdesk engineers work tirelessly to clean the impacted systems, your crack DNS administrative team determines that the queries are all for the same namespace, contosomalicous.com. A very quick modification to the policy using the Set- version of the command allows you to append the criteria, adding the FQDN parameter to ease the restriction so that legitimate queries from the quarantined network are not blocked.

Set-DnsServerQueryResolutionPolicy -Name "BlackholeInfectedClients" –FQDN “EQ,*.contosomalicious.com”

Comments (0)

Skip to main content