Certain deployments may require the same DNS server to perform recursive name resolution for the internal clients apart from acting as authoritative nameserver for contoso.com. For this, the recursion has to be enabled on the DNS server. But as the DNS server is also listening to the external queries, the recursion is also enabled for external clients and the DNS server becomes what is known as an open resolver. This makes the server vulnerable to resource exhaustion and can be abused by malicious clients to orchestrate amplification attacks. There is no reason why contoso.com’s DNS server should perform recursive name resolution for external clients. Essentially there is a need of recursion control such that the recursion is allowed for internal clients while blocked for external clients.
This can be achieved in following steps
Create Recursion Scopes
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.
The legacy recursion setting and list of forwarders are now referred as the default recursion scope. You cannot add or remove the default recursion scope, identified by the name “.” (Dot).
In this example, the default recursion setting is being disabled, while a new recursion scope for internal clients is being created where recursion is being enabled.
Set-DnsServerRecursionScope -Name . -EnableRecursion $False
Add-DnsServerRecursionScope -Name "InternalClients" -EnableRecursion $True
Create Recursion Policies
DNS server recursion policies can be created to choose a recursion scope for a set of queries matching certain criteria. If the DNS server is not authoritative for those queries, these policies allow admin to control how to resolve those queries. Here the internal recursion scope which has recursion enabled is being associated with private network interface
Add-DnsServerQueryResolutionPolicy -Name "RecursionControlPolicy" -Action ALLOW -ApplyOnRecursion -RecursionScope "InternalClients" -ServerInterfaceIP "EQ,10.0.0.39"
In both the examples ServerInterface has been taken as a criteria. Sometimes the recursion-control may be required to be deployed on the basis of source client subnet. That can also be achieved using the client subnet criteria. (See how to use client subnet for traffic management). In fact administrators can use any combination of policy criteria to create their own recursion control rules. For example, administrators can prohibit recursion for "ANY" QTYPE or certain malicious FQDNs.
How it all works
If a query for which the DNS server is non-authoritative is received, i.e. say for www.microsoft.com, then the name resolution request is evaluated against the policies on the DNS server. As these queries do not fall under any zone, the zone level policies are not evaluated. The recursion level policies are evaluated and those queries which are received on private interface match the RecursionControlPolicy which points to a recursion scope where recursion has been enabled. The DNS server then performs recursion to get the answer for www.microsoft.com from internet and caches it locally. On the other hand if the query is received on the external interface, no policies match and default recursion setting (in this case disabled) is applied, preventing the server from acting as open resolver for external clients while it is acting as a caching resolver for internal clients.
Call to Action
Now that you have learnt about deploying recursion control using DNS policies in Windows DNS 2016, we request you to try the feature and let us know your feedback!
Tweet to me @ Kumar Ashutosh