Cela a attiré ma curiosité - et aussi +1 pour une question perspicace - alors j'ai construit un laboratoire rapide pour tester ceci:
Win2012-DC
: Windows Server 2012 R2, promu contrôleur de domaine pour une nouvelle test.local
forêt / domaine.
Win2016-DC
: Windows Server 2016, promu en tant que 2ème contrôleur de domaine pour le test.local
domaine ci-dessus .
Tout est entièrement corrigé et à jour à ce jour (2016-10-29). Le niveau fonctionnel pour la forêt et le domaine est 2012 R2. Les deux serveurs ont également été configurés comme serveurs DNS pour ce domaine de test.
En résumé, les résultats semblent être ceux que vous aviez prévus plus tard:
Les contrôleurs de domaine plus anciens ignorent les nouveaux attributs et répondent d'une manière "par défaut" (aucune politique appliquée), tandis que les nouveaux contrôleurs de domaine répondraient conformément à la stratégie.
J'ai parcouru la plupart des scénarios documentés sous https://technet.microsoft.com/en-us/windows-server-docs/networking/dns/deploy/dns-policies-overview . Par souci de concision, voici les détails de 2 scénarios spécifiques:
Bloquer les requêtes pour un domaine
Cela s'exécute sans problème sur le DC 2016 - mais le DC 2012 ne reconnaît évidemment même pas la commande:
Add-DnsServerQueryResolutionPolicy -Name "BlackholePolicy" -Action IGNORE -FQDN "EQ,*.treyresearch.com"
Lors de l'émission d'une requête DNS pour www.treyresearch.com
le contrôleur de domaine 2016, aucune réponse n'est donnée et la demande expire. Lorsque la même requête est émise contre le contrôleur de domaine 2012, il n'a aucune connaissance de la stratégie et fournit une réponse attendue composée de l'enregistrement A en amont.
Équilibrage de la charge des applications avec connaissance de la géolocalisation
Les commandes PowerShell telles que incluses dans l'article pour référence:
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
Les résultats ici sont presque "pires" que ceux ci-dessus: avec www.contosogiftservices.com
un enregistrement effectif par la politique uniquement, le DC 2012 n'en sait rien et renvoie un NXDOMAIN. (Aucun www
enregistrement n'est visible dans la console de gestion DNS traditionnelle sur le serveur 2012 ou 2016.) Le serveur 2016 répond comme configuré par les stratégies ci-dessus.
Résumé
Je ne vois rien ici qui empêche l'utilisation des fonctionnalités de 2016 dans un domaine avec un niveau fonctionnel moindre. L'option la plus simple et la moins déroutante serait probablement de simplement cesser d'utiliser tous les contrôleurs de domaine 2012 restants comme serveurs DNS, si possible. Au risque d'une complexité supplémentaire, vous pouvez cibler les serveurs 2016 prenant en charge les politiques pour des besoins spécifiques, tels que les politiques de récursivité pour prendre en charge un scénario de déploiement de cerveau partagé (limité).