10

Windows Server 2016 supports DNS Policies, which provide support for split-brain DNS among other scenarios:

You can configure DNS policies to specify how a DNS server responds to DNS queries. DNS responses can be based on client IP address (location), time of the day, and several other parameters. DNS policies enable location-aware DNS, traffic management, load balancing, split-brain DNS, and other scenarios.

I've read the DNS Policies Overview page but I can't seem to find documentation anywhere about how this works on an AD integrated zone when not all DCs are Server 2016 yet.

I can't imagine it would work all that well since the downlevel servers don't know how to interpret policies and act accordingly, but since the information is replicated in AD, I can foresee a situation where older DCs ignore the new attributes and respond in some "default" way (no policy applied), while the new DCs would respond according to policy.

I think that would be ok in certain situations where you can (or already do) have clients pointing at a subset of DCs, as this can provide a way to use the newer features without upgrading all DCs at once.

But, I can't find any information about whether what I described is how it actually works, or whether you can't use the new features at all in a mixed environment, or something in between.

Warning

I've recently discovered that the -WhatIf, -Verbose, and -ErrorAction parameters are broken on the DNS Policy cmdlets; vote here to have that fixed. And be careful!

briantist
  • 2,535
  • 18
  • 34

1 Answers1

4

This caught my curiosity - and also +1 for an insightful question - so I built up a quick lab to test this:

  • Win2012-DC: Windows Server 2012 R2, promoted to domain controller for a new test.local forest / domain.
  • Win2016-DC: Windows Server 2016, promoted as a 2nd domain controller for the above test.local domain.

Everything is fully-patched and up-to-date as of today (2016-10-29). The functional level for both the forest and domain is 2012 R2. Both servers were also configured as the DNS servers for this test domain.

In summary, the results appear to be as you later foresaw:

Older DCs ignore the new attributes and respond in some "default" way (no policy applied), while the new DCs would respond according to policy.

I ran through most of the scenarios documented under https://technet.microsoft.com/en-us/windows-server-docs/networking/dns/deploy/dns-policies-overview . For brevity, following are the details of 2 specific scenarios:

Block Queries for a Domain

This executes without issue on the 2016 DC - but the 2012 DC obviously doesn't even recognize the command:

Add-DnsServerQueryResolutionPolicy -Name "BlackholePolicy" -Action IGNORE -FQDN "EQ,*.treyresearch.com"

When issuing a DNS query for www.treyresearch.com against the 2016 DC, no response is given and the request times-out. When the same query is issued against the 2012 DC, it has no knowledge of the policy and provides an expected response consisting of the upstream A record.

Application Load Balancing With Geo-Location Awareness

The PowerShell commands as included on the article for reference:

Add-DnsServerZoneScope -ZoneName "contosogiftservices.com" -Name "DublinZoneScope"
Add-DnsServerZoneScope -ZoneName "contosogiftservices.com" -Name "AmsterdamZoneScope"
Add-DnsServerResourceRecord -ZoneName "contosogiftservices.com" -A -Name "www" -IPv4Address "151.1.0.1" -ZoneScope "DublinZoneScope”
Add-DnsServerResourceRecord -ZoneName "contosogiftservices.com" -A -Name "www" -IPv4Address "141.1.0.1" -ZoneScope "AmsterdamZoneScope"
Add-DnsServerQueryResolutionPolicy -Name "AmericaLBPolicy" -Action ALLOW -ClientSubnet "eq,AmericaSubnet" -ZoneScope "SeattleZoneScope,2;ChicagoZoneScope,1; TexasZoneScope,1" -ZoneName "contosogiftservices.com" –ProcessingOrder 1
Add-DnsServerQueryResolutionPolicy -Name "EuropeLBPolicy" -Action ALLOW -ClientSubnet "eq,EuropeSubnet" -ZoneScope "DublinZoneScope,1;AmsterdamZoneScope,1" -ZoneName "contosogiftservices.com" -ProcessingOrder 2
Add-DnsServerQueryResolutionPolicy -Name "WorldWidePolicy" -Action ALLOW -FQDN "eq,*.contoso.com" -ZoneScope "SeattleZoneScope,1;ChicagoZoneScope,1; TexasZoneScope,1;DublinZoneScope,1;AmsterdamZoneScope,1" -ZoneName "contosogiftservices.com" -ProcessingOrder 3

The results here are almost "worse" than the above: With www.contosogiftservices.com effectively registered by policy only, the 2012 DC knows nothing about it and returns a NXDOMAIN. (No www record is visible in the traditional DNS management console on either the 2012 or 2016 server.) The 2016 server responds as configured by the above policies.

Summary

I don't see anything here that prevents use of the 2016 features in a domain with a lesser functional level. The simplest and least confusing option would probably be to just stop using any remaining 2012 DCs as DNS servers, if possible. At risk of some additional complexity, you could target the policy-supporting 2016 servers for specific needs, such as recursion policies to support a (limited) split-brain deployment scenario.

ziesemer
  • 1,061
  • 1
  • 7
  • 15
  • 2
    This is **fantastic**, above and beyond, thank you! – briantist Oct 29 '16 at 20:50
  • This is important to limit DNS amplification attacks on external facing name servers. I'm sure there are admins nervous about what would happen when adding a 2016 DNS server into a lower functional domain level. As usual, Microsoft has very little information on this. – Brain2000 Dec 19 '17 at 21:43