Les stratégies DNS de Windows 2016 / DNS partagé sont-elles possibles sur les zones intégrées AD avec des contrôleurs de domaine plus anciens?

Windows Server 2016 prend en charge les stratégies DNS , qui prennent en charge le DNS split-brain entre autres scénarios:

Vous pouvez configurer des stratégies DNS pour spécifier la façon dont un serveur DNS répond aux requêtes DNS. Les réponses DNS peuvent être basées sur l'adresse IP du client (emplacement), l'heure de la journée et plusieurs autres paramètres. Les stratégies DNS activent le DNS géolocalisé, la gestion du trafic, l'équilibrage de charge, le DNS à cerveau partagé et d'autres scénarios.

J'ai lu la page de présentation des stratégies DNS mais je n'arrive pas à trouver de documentation où que ce soit sur le fonctionnement d'une zone intégrée AD alors que tous les contrôleurs de domaine ne sont pas encore Server 2016.

Je ne peux pas imaginer que cela fonctionnerait si bien que les serveurs de niveau inférieur ne savent pas comment interpréter les politiques et agir en conséquence, mais comme les informations sont répliquées dans AD, je peux prévoir une situation où les anciens DC 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 politique.

Je pense que ce serait correct dans certaines situations où vous pouvez (ou avez déjà) des clients pointant vers un sous-ensemble de contrôleurs de domaine, car cela peut fournir un moyen d'utiliser les nouvelles fonctionnalités sans mettre à niveau tous les contrôleurs de contrôle à la fois.

Mais, je ne trouve aucune information pour savoir si ce que j'ai décrit est comment cela fonctionne réellement, ou si vous ne pouvez pas du tout utiliser les nouvelles fonctionnalités dans un environnement mixte, ou quelque chose entre les deux.

avertissement

J'ai récemment découvert que les -WhatIf, -Verbose, et les -ErrorActionparamètres sont répartis sur les cmdlets Politique DNS; votez ici pour que cela soit corrigé . Et fais attention!

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.localforêt / domaine.
• Win2016-DC: Windows Server 2016, promu en tant que 2ème contrôleur de domaine pour le test.localdomaine 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

• https://technet.microsoft.com/en-us/windows-server-docs/networking/dns/deploy/dns-policies-overview?#block-queries-for-a-domain

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.comle 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

• https://technet.microsoft.com/en-us/windows-server-docs/networking/dns/deploy/app-lb-geo
  • (Attention, toutes les étendues de zone autres que Dublin et Amsterdam ont été créées dans les sous-pages précédentes de https://technet.microsoft.com/en-us/windows-server-docs/networking/dns/deploy/dns-policy -scenario-guide - donc si vous commencez avec cette page, les étendues de zone manquantes devront être créées ou la dernière Add-DnsServerQueryResolutionPolicycommande modifiée pour les ignorer.)

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.comun enregistrement effectif par la politique uniquement, le DC 2012 n'en sait rien et renvoie un NXDOMAIN. (Aucun wwwenregistrement 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é).