It is common for organizations to host websites and other resources that may be accessible from external and internal clients on the LAN. Traditionally, organizations may have maintained two different DNS servers for this reason. Microsoft's split-brain DNS deployment using DNS policy helps consolidate these resources using Active Directory-integrated zones.
Latest posts by Brandon Lee (see all)

Microsoft defines DNS deployments as being split-brain when two different versions of a single zone exist on DNS servers. But how can you have traffic from one source pull records from one zone and another source from another zone? Starting with Windows Server 2016, Microsoft has added the ability to create DNS policies for split-brain deployments.

Creating a new Active Directory integrated zone

Creating a new Active Directory integrated zone

DNS servers can now evaluate DNS requests based on the configured policies. For example, if a request comes across a specific interface, it can be matched with a policy that associates the query with a certain zone.

If you have a DNS server with two interfaces, one with a public address and the other with a private address, your policies could be defined as follows:

  • Private address > Intranet DNS policy > serves out the Intranet version of the website
  • Public address > Internet DNS policy > serves out the Internet version of the website

Creating a new zone scope

The split-brain DNS solution uses what is called a zone scope. It can contain its own set of resource records, which are presented to the corresponding set of DNS clients based on IP subnets.

Like the DNS zone itself, the DNS zone scope is Active Directory-integrated, meaning they will be replicated to other Active Directory servers. To create a new DNS zone scope, use the following command:

Add-DnsServerZoneScope -ZoneName "<your Zone name>" -Name "<your Zone name>"
Creating a new Active Directory zone scope

Creating a new Active Directory zone scope

Since the default zone scope will be served to clients by default, we don't have to create two zone scopes but just one for external Internet users. We use the default zone scope for internal DNS queries.

Adding DNS records to DNS zone scopes

Now that we have an additional zone scope for external users, we need to assign records to both the external and internal zone scopes. You can do this using the following command:

Add-DnsServerResourceRecord -ZoneName "<zone name>" -A -Name "<record name>" `
-IPv4Address "<IP address>" -ZoneScope "<zone scope name>"
Adding records to each zone scope

Adding records to each zone scope

As you can see above, we are adding two versions of the same DNS record. The first record is added with the ZoneScope parameter, indicating to which Zone Scope the record belongs. The second record is added to the default zone scope since the ZoneScope parameter isn't used.

Tying a policy to the zone scope

Now, we need to create and apply a DNS policy to the server interface that we want to associate with a respective zone scope. Using the ServerInterface parameter, we tie the IP address assigned to the interface associated with the zone scope and the DNS zone it will serve. Note the example below:

Add-DnsServerQueryResolutionPolicy -Name "SplitBrainZonePolicy" -Action ALLOW `
-ServerInterface "eq,10.1.149.90" -ZoneScope "External,1" -ZoneName testzone.com
Adding a DNS policy to route traffic to the appropriate DNS zone scope

Adding a DNS policy to route traffic to the appropriate DNS zone scope

Any DNS queries that traverse the server interface defined in the policy will be routed to the appropriate DNS zone scope and receive the associated records. All other queries that come across the other server interface will receive the records found in the other zone scope.

The leading "eq" in the ServerInterface parameter value stands for the equals operator. Alternatively, you can use "ne" for not equal. It is possible to combine both to refine the targeted interfaces:

operator, value01, value02, . . . ; operator, value03, value04, . . .

You can pass several zone scopes to the namesake parameter. The numerical value following the name specifies its respective weight.

Shortcomings of split-brain DNS

While the DNS zone and DNS zone scopes are Active Directory-integrated, the policies are not. This means that they are not replicated to other DNS servers. Instead, you will need to manually export DNS policies from one server to another and store these on each local DNS server.

Because the split-brain DNS policy requires Active Directory-integrated zones, external queries would have to be serviced by your Active Directory infrastructure. However, many organizations may view the external queries of their Active Directory DNS servers as a security risk.

Wrapping up

The split-brain DNS deployment using DNS policy is an interesting capability found in Windows Server 2016 and higher. It allows organizations to consolidate their external and internal DNS infrastructure.

However, it is disappointing that the DNS policies are not Active Directory-integrated, like the DNS zones and zone scopes. Additionally, external queries of Active Directory DNS servers may not align with strict security policies for the DNS infrastructure.

avataravataravatar
0 Comments

Leave a reply

Your email address will not be published.

*

© 4sysops 2006 - 2023

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account