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
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 "220.127.116.11" -ZoneScope "DublinZoneScope”
Add-DnsServerResourceRecord -ZoneName "contosogiftservices.com" -A -Name "www" -IPv4Address "18.104.22.168" -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.
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.