Split-Brain DNS in Active Directory Environment Using DNS Policies
In Windows Server 2016 Technical Preview 3, the DNS policies support has been extended to Active Directory backed zones. Active Directory integration inherently provides multi-master high availability capabilities to the DNS server. In earlier blogs, we had seen how to configure DNS server policies for different scenarios on file backed DNS zones. But as many of our customers use Active Directory environment, it was needed that the traffic management capabilities of DNS policies were extended to the Active Directory integrated zones. In a previous blog, we discussed how DNS policies and zone scopes could be used to setup a split brain DNS system on a single Windows DNS server. 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.
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 hosted 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 for contoso.com is Active Directory integrated, and 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
Add the contoso.com AD integrated zone
Add the Active directory integrated contoso.com zone to the DNS server.
Add-DnsServerPrimaryZone -Name "contoso.com" -ReplicationScope "Domain" -PassThru
Create the Scopes of the Zone
Partition the zone contoso.com to create an external 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. As this zone scope is being added in an AD integrated zone, the zone scope and the records inside it will replicate via active directory to other replica servers in the domain.
The internal zone scope will be used to keep the internal version of www.career.contoso.com
Add-DnsServerZoneScope -ZoneName "contoso.com" -Name "external"
Explore Add-DnsServerZoneScope
By default a zone scope exists in every DNS zone. 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 internal 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- external and default (for internal clients). In default, the record www.career.contoso.com is added with IP address 10.0.0.39, which is a private IP; and in external zone scope the same record (www.career.contoso.com) is added with IP address 65.55.39.10. The records (both in the default scope and external zone scope) will automatically get replicated across the domain with their respective zone scopes.
Add-DnsServerResourceRecord -ZoneName "contoso.com" -A -Name "www.career" -IPv4Address "65.55.39.10" -ZoneScope "external"
Add-DnsServerResourceRecord -ZoneName "contoso.com" -A -Name "www.career" -IPv4Address "10.0.0.39”
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 normal 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 the public interface, the answer is returned from the external scope of the zone. No policies are required for mapping default zone scope.
Add-DnsServerQueryResolutionPolicy -Name "SplitBrainZonePolicy" -Action ALLOW -ServerInterface "eq,208.84.0.53" -ZoneScope "external,1" -ZoneName contoso.com
* 208.84.0.53 is the IP on the public 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 policies, 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 public IP (208.84.0.53) are responded with an external IP address; and the DNS queries that are received on the private network interface are responded with the private IP address in the default zone scope (this is same as normal query resolution).
The support for Dynamic DNS (DDNS) updates and scavenging happens only on the default zone scope. As the internal clients are being serviced by the default zone scope, the DNS admins can continue the existing mechanisms (dynamic DNS or static) to update the records in contoso.com. Note that for non-default zone scopes (i.e. 'external' scope in the above example) DDNS or scavenging support is not available.
High Availability of policies
Note that policies are not Active Directory integrated and hence, not replicated to the other DNS servers hosting the same AD integrated zone. They are stored and persisted on the local DNS server. But these policies can be easily exported from one server to another via simple Powershell commands:
$policies = Get-DnsServerQueryResolutionPolicy -ZoneName "contoso.com" -ComputerName Server01
$policies | Add-DnsServerQueryResolutionPolicy -ZoneName "contoso.com" -ComputerName Server02
In this example 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)
Call to Action
Now that you have learnt about deploying split brain DNS server in an active directory environment in Windows DNS Server 2016, we request you to try the feature and let us know your feedback. Use the comment box below or mail us at windns-users@lists.cloudapp.net
Also See
Name Resolution Performance of a Recursive Windows DNS Server 2012 R2
Name Resolution Performance of Authoritative Windows DNS Server 2012 R2
What's New in DNS Server in Windows Server Technical Preview
Authored by: Kumar Ashutosh
Comments
- Anonymous
September 01, 2015
This is awesome! - Anonymous
September 07, 2015
208 Microsoft Team blogs searched, 57 blogs have new articles. 263 new articles found searching from