DNS policies is a new feature in the DNS server role of Windows Server 2016 Technical Preview – not to be confused with group policies of the AD fame. You can create DNS policies on the DNS server to control how a DNS Server handles queries based on different parameters. In the previous blog, we discussed how to achieve traffic management using DNS policies. Split brain DNS deployment has been a long standing conundrum for DNS administrators. A DNS deployment is said to be split-brain (or split-horizon) when there are two versions of a single zone, one for the internal users and one for the external users – typically users on the public internet. For Windows DNS server based deployments, such scenarios called for maintaining two different DNS servers, each catering to a different set of the users. If only a few records inside the zone were split brained or both instances of the zone (internal and external) were delegated to same parent domain this became a management conundrum.
Another variant of the split brain deployment is the selective recursion control for DNS name resolution. Sometimes the enterprise DNS servers are expected to perform recursive resolution over internet for the internal users; while they have to act as a pure name servers (authoritative) for external users and block recursion for them. Here we shall see how these two scenarios can be accomplished using DNS policies.
Two versions of the same zone
Suppose the career website of contoso.com is hosted at www.career.contoso.com . The site has two versions, one for the internal users where internal job postings are available and is available on a local IP 10.0.0.39. The public version of the same site is available on public IP 220.127.116.11. In absence of DNS policies, the administrator had to host these two zones on separate Windows DNS servers and manage them separately. Using DNS policies these zones can now be hosted on the same DNS server.
If the nameserver hosting contoso.com zone is listening on two network interfaces; one with a public IP of 18.104.22.168 for external queries and another with a private IP 10.0.0.56 for internal queries then the administrator can follow these steps to achieve this split brain deployment
* All IPs and names are purely representational
Create the Scopes of the Zone
Partition the zone contoso.com to create an internal zone scope. A zone scope is a unique instance of the zone. A DNS zone can have multiple zone scopes, with each zone scope containing its own set of DNS records. The same record can be present in multiple scopes, with different IP addresses.
The internal zone scope will be used to keep the internal version of www.career.contoso.com
Add-DnsServerZoneScope -ZoneName "contoso.com" -Name "internal"
By default a zone scope exists on the DNS zones. This zone scope has the same name as the zone and legacy DNS operations work on this scope. This default zone scope will host the external version of www.career.contoso.com
Add Records to the Zone Scopes
The next step is to add the records representing the web server host into the two zone scopes- internal and default (for external clients). In internal, the record www.career.contoso.com is added with IP address 10.0.0.39, which is a private IP; and in default zone scope the same record (www.career.contoso.com) is added with IP address 22.214.171.124.
Add-DnsServerResourceRecord -ZoneName "contoso.com" -A -Name "www.career" -IPv4Address "126.96.36.199"
Add-DnsServerResourceRecord -ZoneName "contoso.com" -A -Name "www.career" -IPv4Address "10.0.0.39” -ZoneScope "internal"
Note that no –ZoneScope parameter has been provided when record is being added in default zone scope. This is same as adding records to a vanilla zone.
Create the Policies
Once the server interfaces for external network and internal network have been identified; and the partitions (zone scopes) have been created, the next step is to create policies that connect these two, in a way that when the query is received on private interface, the answer is returned form the internal scope of the zone. No policies are required for mapping default zone scope.
Add-DnsServerQueryResolutionPolicy -Name "SplitBrainZonePolicy" -Action ALLOW -ServerInterface "eq,10.0.0.56" -ZoneScope "internal,1" -ZoneName contoso.com
* 10.0.0.56 is the IP on the private network interface.
How it all works
Now the DNS server has been configured with the required policies. When a name resolution query is incident on the DNS server so configured, each name resolution request is evaluated against the policies on the DNS server. If the server interface on which the query has been received matches any of the policy, the associated zone scope is used to respond to the query. So, in our example, the DNS queries for www.career.contoso.com that are received on from private IP (10.0.0.56) are responded with an internal IP address; and the DNS queries that are received on the public network interface are responded with the public IP address in the default zone scope (this is same as normal query resolution).
Selective Recursion Control
In the previous example, the same DNS server is serving both the external and internal clients and respond back with different answers. 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 create reflection 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 "SplitBrainRecursionPolicy" -Action ALLOW -ApplyOnRecursion -RecursionScope "InternalClients" -ServerInterfaceIP "EQ,10.0.0.39"
In both the examples ServerInterface has been taken as a criteria. Sometimes the split-brain 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)
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 (as defined in first case above) are not evaluated. The recursion level policies are evaluated and those queries which are received on private interface match the SplitBrainRecursionPolicy 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 split-brain DNS using DNS policies in Windows DNS vNext, we request you to try the feature and let us know your feedback!