Split-Brain DNS Deployment Using Windows DNS Server Policies

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 65.55.39.10. 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 208.84.0.53 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"

 Explore Add-DnsServerZoneScope

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 65.55.39.10.

 

Add-DnsServerResourceRecord -ZoneName "contoso.com" -A -Name "www.career" -IPv4Address "65.55.39.10" 

Add-DnsServerResourceRecord -ZoneName "contoso.com" -A -Name "www.career" -IPv4Address "10.0.0.39 -ZoneScope "internal"

 Explore Add-DnsServerResourceRecord

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.

 Explore Add-DnsServerQueryResolutionPolicy

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 

 Explore Add-DnsServerRecursionScope  

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"

 Explore Add-DnsServerQueryResolutionPolicy

 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!

Also See

Geo-Location Based Traffic Management Using DNS Policies