Это привлекло мое любопытство - а также +1 для проницательного вопроса - поэтому я создал небольшую лабораторию, чтобы проверить это:
Win2012-DC
: Windows Server 2012 R2, повышен до контроллера домена для нового test.local
леса / домена.
Win2016-DC
: Windows Server 2016, продвинутый как 2-ой контроллер домена для вышеупомянутого test.local
домена.
Все полностью исправлено и обновлено на сегодняшний день (2016-10-29). Функциональным уровнем для леса и домена является 2012 R2. Оба сервера также были настроены в качестве DNS-серверов для этого тестового домена.
Таким образом, результаты выглядят так, как вы позже предвидели:
Старые контроллеры домена игнорируют новые атрибуты и отвечают некоторым способом «по умолчанию» (политика не применяется), в то время как новые контроллеры домена отвечают в соответствии с политикой.
Я пробежал по большинству сценариев, описанных в разделе https://technet.microsoft.com/en-us/windows-server-docs/networking/dns/deploy/dns-policies-overview . Для краткости ниже приведены подробности двух конкретных сценариев:
Блокировать запросы для домена
Это выполняется без проблем на DC 2016 - но DC 2012, очевидно, даже не распознает команду:
Add-DnsServerQueryResolutionPolicy -Name "BlackholePolicy" -Action IGNORE -FQDN "EQ,*.treyresearch.com"
При выдаче DNS-запроса для www.treyresearch.com
домена DC 2016 ответ не дается и время ожидания запроса. Когда тот же запрос выполняется для DC 2012, он не знает о политике и предоставляет ожидаемый ответ, состоящий из восходящей записи A.
Балансировка нагрузки приложений с учетом географического положения
Команды PowerShell, включенные в статью для справки:
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
Результаты здесь почти «хуже», чем приведенные выше: при www.contosogiftservices.com
эффективной регистрации только политикой, DC 2012 ничего не знает об этом и возвращает NXDOMAIN. (В www
традиционной консоли управления DNS на сервере 2012 или 2016 года не видно ни одной записи.) Сервер 2016 отвечает в соответствии с приведенными выше политиками.
Резюме
Я не вижу здесь ничего, что мешало бы использовать функции 2016 года в домене с меньшим функциональным уровнем. Самый простой и наименее запутанный вариант, вероятно, будет состоять в том, чтобы просто прекратить использование любых оставшихся контроллеров домена 2012 в качестве DNS-серверов, если это возможно. Риск возникновения некоторой дополнительной сложности может привести к тому, что серверы 2016 года, поддерживающие политику, будут ориентированы на конкретные потребности, такие как политики рекурсии, для поддержки (ограниченного) сценария развертывания с разделением мозгов.