Vue d’ensemble des stratégies DNS
Vous pouvez utiliser cette rubrique pour en savoir plus sur la stratégie DNS, qui est une nouveauté dans Windows Server 2016. Vous pouvez utiliser la stratégie DNS pour la gestion du trafic basée sur la géolocalisation, les réponses DNS intelligentes en fonction de l’heure de la journée, afin de gérer un serveur DNS unique configuré pour le déploiement du cerveau, l’application de filtres sur les requêtes DNS, etc. Les éléments suivants fournissent plus de détails sur ces fonctionnalités.
Équilibrage de charge d’application. Lorsque vous avez déployé plusieurs instances d’une application à différents emplacements, vous pouvez utiliser la stratégie DNS pour équilibrer la charge du trafic entre les différentes instances d’application, en allouant dynamiquement la charge de trafic pour l’application.
Gestion du trafic basée sur la géolocalisation. Vous pouvez utiliser la stratégie DNS pour autoriser les serveurs DNS principaux et secondaires à répondre aux requêtes du client DNS en fonction de l’emplacement géographique du client et de la ressource à laquelle le client tente de se connecter, en fournissant au client l’adresse IP de la ressource la plus proche.
Fractionnement du cerveau du DNS. Avec le DNS à cerveau fractionné, les enregistrements DNS sont divisés en différentes étendues de zone sur le même serveur DNS, et les clients DNS reçoivent une réponse selon qu’ils sont des clients internes ou externes. Vous pouvez configurer le DNS fractionné pour les zones intégrées Active Directory ou pour les zones sur des serveurs DNS autonomes.
Effectuez un filtrage. Vous pouvez configurer la stratégie DNS pour créer des filtres de requête basés sur des critères que vous fournissez. Les filtres de requête dans la stratégie DNS vous permettent de configurer le serveur DNS pour répondre de manière personnalisée en fonction de la requête DNS et du client DNS qui envoie la requête DNS.
Exploration. Vous pouvez utiliser la stratégie DNS pour rediriger des clients DNS malveillants vers une adresse IP inexistante au lieu de les diriger vers l’ordinateur qu’ils essaient d’atteindre.
Redirection basée sur l’heure de la journée. Vous pouvez utiliser la stratégie DNS pour distribuer le trafic d’application entre différentes instances distribuées géographiquement d’une application à l’aide de stratégies DNS basées sur l’heure de la journée.
Nouveaux concepts
Pour créer des stratégies pour prendre en charge les scénarios répertoriés ci-dessus, il est nécessaire de pouvoir identifier des groupes d’enregistrements dans une zone, des groupes de clients sur un réseau, entre autres éléments. Ces éléments sont représentés par les nouveaux objets DNS suivants :
Sous-réseau client : un objet de sous-réseau client représente un sous-réseau IPv4 ou IPv6 à partir duquel les requêtes sont envoyées à un serveur DNS. Vous pouvez créer des sous-réseaux pour définir ultérieurement des stratégies à appliquer en fonction du sous-réseau duquel les requêtes proviennent. Par exemple, dans un scénario DNS fractionné, la demande de résolution d’un nom tel que www.microsoft.com peut être traitée avec une adresse IP interne aux clients à partir de sous-réseaux internes et une adresse IP différente pour les clients dans des sous-réseaux externes.
Étendue de récursivité : les étendues de récursivité sont des instances uniques d’un groupe de paramètres qui contrôlent la récursivité sur un serveur DNS. Une étendue de récursivité contient une liste de redirecteurs et indique si la récursivité est activée. Un serveur DNS peut comporter un grand nombre d’étendues de récursivité. Les stratégies de récursivité du serveur DNS vous permettent de choisir une étendue de récursivité pour un ensemble de requêtes. Si le serveur DNS ne fait pas autorité pour certaines requêtes, les stratégies de récursivité du serveur DNS vous permettent de contrôler la façon de résoudre ces requêtes. Vous pouvez spécifier les redirecteurs à utiliser et s’il faut utiliser la récursivité.
Étendues de zone : une zone DNS peut comporter plusieurs étendues de zone, chacune d’elles contenant son propre ensemble d’enregistrements DNS. Le même enregistrement peut être présent dans plusieurs étendues, avec différentes adresses IP. En outre, les transferts de zone sont effectués au niveau de l’étendue de la zone. Cela signifie que les enregistrements d’une étendue de zone dans une zone principale seront transférés vers la même étendue de zone dans une zone secondaire.
Types de stratégies
Les stratégies DNS sont divisées par niveau et par type. Vous pouvez utiliser des stratégies de résolution de requêtes pour définir le mode de traitement des requêtes, et des stratégies de transfert de zone pour définir la façon dont les transferts de zone se produisent. Vous pouvez appliquer chaque type de stratégie au niveau du serveur ou au niveau de la zone.
Stratégies de résolution de requêtes
Vous pouvez utiliser des stratégies de résolution de requêtes DNS pour spécifier la façon dont les requêtes de résolution entrantes sont gérées par un serveur DNS. Chaque stratégie de résolution de requête DNS contient les éléments suivants :
| Champ | Description | Valeurs possibles |
|---|---|---|
| Nom | Nom de stratégie | – Jusqu’à 256 caractères – Peut contenir n’importe quel caractère valide pour un nom de fichier |
| State | État de la stratégie | – Activer (par défaut) - Désactivé |
| Niveau | Niveau de stratégie | – Serveur – Zone |
| Ordre de traitement | Une fois qu’une requête est classée par niveau et s’applique, le serveur trouve la première stratégie pour laquelle la requête correspond aux critères et l’applique à la requête | – Valeur numérique – Valeur unique par stratégie contenant le même niveau et s’applique à la valeur |
| Action | Action à effectuer par le serveur DNS | – Autoriser (par défaut pour le niveau de la zone) – Refuser (par défaut au niveau du serveur) – Ignorer |
| Critères | Condition de stratégie (AND/OR) et liste des critères à respecter pour l’application de la stratégie | – Opérateur de condition (AND/OR) – Liste des critères (voir le tableau de critères ci-dessous) |
| Étendue | Liste des étendues de zone et des valeurs pondérées par étendue. Les valeurs pondérées sont utilisées pour la distribution de l’équilibrage de charge. Par exemple, si cette liste inclut datacenter1 avec un poids de 3 et datacenter2 avec un poids de 5, le serveur répond avec un enregistrement du datacentre1 trois fois sur huit requêtes | – Liste des étendues de zone (par nom) et poids |
Remarque
Les stratégies au niveau du serveur ne peuvent avoir que les valeurs Refuser ou Ignorer en tant qu’action.
Le champ critères de stratégie DNS est composé de deux éléments :
| Nom | Description | Exemples de valeurs |
|---|---|---|
| Sous-réseau client | Nom d’un sous-réseau client prédéfini. Permet de vérifier le sous-réseau à partir duquel la requête a été envoyée. | - EQ,Espagne,France : résout la valeur true si le sous-réseau est identifié comme étant l’Espagne ou la France - NE,Canada,Mexique : résout la valeur true si le sous-réseau client est un sous-réseau autre que le Canada et le Mexique |
| Protocole de transfert | Protocole de transport utilisé dans la requête. Les entrées possibles sont UDP et TCP | - EQ,TCP - EQ,UDP |
| Protocole Internet | Protocole réseau utilisé dans la requête. Les entrées possibles sont IPv4 et IPv6 | - EQ,IPv4 - EQ,IPv6 |
| Adresse IP de l’interface serveur | Adresse IP de l’interface réseau du serveur DNS entrant | - EQ,10.0.0.1 - EQ,192.168.1.1 |
| FQDN | Nom de domaine complet d’enregistrement dans la requête, avec la possibilité d’utiliser une carte générique | - EQ,www.contoso.com : résout la valeur true uniquement si la requête tente de résoudre le nom de domaine complet www.contoso.com - EQ,*.contoso.com,*.woodgrove.com : résout la valeur true si la requête concerne un enregistrement se terminant par contoso.comOUwoodgrove.com |
| Type de requête | Type d’enregistrement interrogé (A, SRV, TXT) | - EQ,TXT,SRV : résout la valeur true si la requête demande un enregistrement TXT OU SRV - EQ,MX : résout la valeur true si la requête demande un enregistrement MX |
| Heure de la journée | Heure de la réception de la requête | - EQ,10:00-12:00,22:00-23:00 : résout la valeur true si la requête est reçue entre 10h et midi, OU entre 22h et 23h |
En utilisant le tableau ci-dessus comme point de départ, le tableau ci-dessous peut être utilisé pour définir un critère permettant de faire correspondre des requêtes pour n’importe quel type d’enregistrements, sauf les enregistrements SRV dans le domaine contoso.com provenant d’un client dans le sous-réseau 10.0.0.0/24 via TCP entre 20h et 22h jusqu’à l’interface 10.0.0.3 :
| Nom | Valeur |
|---|---|
| Sous-réseau client | EQ,10.0.0.0/24 |
| Protocole de transfert | EQ,TCP |
| Adresse IP de l’interface serveur | EQ,10.0.0.3 |
| FQDN | EQ,*.contoso.com |
| Type de requête | NE,SRV |
| Heure du jour | EQ,20:00-22:00 |
Vous pouvez créer plusieurs stratégies de résolution de requêtes du même niveau, tant qu’elles ont une valeur différente pour l’ordre de traitement. Lorsque plusieurs stratégies sont disponibles, le serveur DNS traite les requêtes entrantes de la manière suivante :
Stratégies de récursivité
Les stratégies de récursivité sont un type spécial de stratégies au niveau du serveur. Les stratégies de récursivité contrôlent la façon dont le serveur DNS effectue la récursivité pour une requête. Les stratégies de récurrence s’appliquent uniquement lorsque le traitement de la requête atteint le chemin de récursivité. Vous pouvez choisir la valeur REFUSER ou IGNORER pour la récursivité pour un ensemble de requêtes. En alternative, vous pouvez choisir un ensemble de redirecteurs pour un ensemble de requêtes.
Vous pouvez utiliser des stratégies de récursivité pour implémenter une configuration DNS fractionnée. Dans cette configuration, le serveur DNS effectue une récursivité pour un ensemble de clients pour une requête, tandis que le serveur DNS n’effectue pas de récursivité pour d’autres clients pour cette requête.
Les stratégies de récursivité contiennent les mêmes éléments que la stratégie de résolution de requêtes DNS standard, ainsi que les éléments du tableau ci-dessous :
| Nom | Description |
|---|---|
| Appliquer sur la récursivité | Spécifie que cette stratégie doit uniquement être utilisée pour la récursivité. |
| Étendue de récursivité | Nom de l’étendue de récursivité. |
Notes
Les stratégies de récursivité ne peuvent être créées qu’au niveau du serveur.
Stratégies de transfert de zone
Les stratégies de transfert de zone contrôlent si un transfert de zone est autorisé ou non par votre serveur DNS. Vous pouvez créer des stratégies pour le transfert de zone au niveau de serveur ou de la zone. Les stratégies au niveau du serveur s’appliquent à chaque requête de transfert de zone qui se produit sur le serveur DNS. Les stratégies au niveau de la zone s’appliquent uniquement aux requêtes sur une zone hébergée sur le serveur DNS. Les stratégies au niveau de la zone sont le plus souvent utilisées pour implémenter des listes bloquées ou sécurisées.
Remarque
Les stratégies de transfert de zone peuvent uniquement utiliser REFUSER ou IGNORER en tant qu’actions.
Vous pouvez utiliser la stratégie de transfert de zone au niveau du serveur ci-dessous pour refuser un transfert de zone pour le domaine contoso.com à partir d’un sous-réseau donné :
Add-DnsServerZoneTransferPolicy -Name DenyTransferOfContosoToFabrikam -Zone contoso.com -Action DENY -ClientSubnet "EQ,192.168.1.0/24"
Vous pouvez créer plusieurs stratégies de transfert de zone du même niveau, tant qu’elles ont une valeur différente pour l’ordre de traitement. Lorsque plusieurs stratégies sont disponibles, le serveur DNS traite les requêtes entrantes de la manière suivante :
Gestion des stratégies DNS
Vous pouvez créer et gérer des stratégies DNS à l’aide de PowerShell. Les exemples ci-dessous parcourent différents exemples de scénarios que vous pouvez configurer via des stratégies DNS :
Gestion du trafic
Vous pouvez diriger le trafic en fonction d’un nom de domaine complet vers différents serveurs en fonction de l’emplacement du client DNS. L’exemple ci-dessous montre comment créer des stratégies de gestion du trafic pour diriger les clients d’un certain sous-réseau vers un centre de données nord-américain et d’un autre sous-réseau vers un centre de données européen.
Add-DnsServerClientSubnet -Name "NorthAmericaSubnet" -IPv4Subnet "172.21.33.0/24"
Add-DnsServerClientSubnet -Name "EuropeSubnet" -IPv4Subnet "172.17.44.0/24"
Add-DnsServerZoneScope -ZoneName "Contoso.com" -Name "NorthAmericaZoneScope"
Add-DnsServerZoneScope -ZoneName "Contoso.com" -Name "EuropeZoneScope"
Add-DnsServerResourceRecord -ZoneName "Contoso.com" -A -Name "www" -IPv4Address "172.17.97.97" -ZoneScope "EuropeZoneScope"
Add-DnsServerResourceRecord -ZoneName "Contoso.com" -A -Name "www" -IPv4Address "172.21.21.21" -ZoneScope "NorthAmericaZoneScope"
Add-DnsServerQueryResolutionPolicy -Name "NorthAmericaPolicy" -Action ALLOW -ClientSubnet "eq,NorthAmericaSubnet" -ZoneScope "NorthAmericaZoneScope,1" -ZoneName "Contoso.com"
Add-DnsServerQueryResolutionPolicy -Name "EuropePolicy" -Action ALLOW -ClientSubnet "eq,EuropeSubnet" -ZoneScope "EuropeZoneScope,1" -ZoneName contoso.com
Les deux premières lignes du script créent des objets de sous-réseau client pour l’Amérique du Nord et l’Europe. Les deux lignes qui suivent créent une étendue de zone dans le domaine contoso.com, une pour chaque région. Les deux lignes qui suivent créent un enregistrement dans chaque zone qui associe www.contoso.com à une adresse IP différente, une pour l’Europe, une autre pour l’Amérique du Nord. Enfin, les dernières lignes du script créent deux stratégies de résolution de requêtes DNS, l’une à appliquer au sous-réseau Amérique du Nord, l’autre au sous-réseau Europe.
Bloquer les requêtes pour un domaine
Vous pouvez utiliser une stratégie de résolution de requêtes DNS pour bloquer les requêtes dans un domaine. L’exemple ci-dessous bloque toutes les requêtes à treyresearch.net :
Add-DnsServerQueryResolutionPolicy -Name "BlackholePolicy" -Action IGNORE -FQDN "EQ,*.treyresearch.com"
Bloquer les requêtes à partir d’un sous-réseau
Vous pouvez également bloquer les requêtes provenant d’un sous-réseau spécifique. Le script ci-dessous crée un sous-réseau pour 172.0.33.0/24, puis crée une stratégie pour ignorer toutes les requêtes provenant de ce sous-réseau :
Add-DnsServerClientSubnet -Name "MaliciousSubnet06" -IPv4Subnet 172.0.33.0/24
Add-DnsServerQueryResolutionPolicy -Name "BlackholePolicyMalicious06" -Action IGNORE -ClientSubnet "EQ,MaliciousSubnet06"
Autoriser la récursivité pour les clients internes
Vous pouvez contrôler la récursivité à l’aide d’une stratégie de résolution de requêtes DNS. L’exemple ci-dessous peut être utilisé pour activer la récursivité pour les clients internes, tout en la désactivant pour les clients externes dans un scénario de fractionnement du cerveau.
Set-DnsServerRecursionScope -Name . -EnableRecursion $False
Add-DnsServerRecursionScope -Name "InternalClients" -EnableRecursion $True
Add-DnsServerQueryResolutionPolicy -Name "SplitBrainPolicy" -Action ALLOW -ApplyOnRecursion -RecursionScope "InternalClients" -ServerInterfaceIP "EQ,10.0.0.34"
La première ligne du script modifie l’étendue de récursivité par défaut, simplement nommée « » (point) pour désactiver la récursivité. La deuxième ligne crée une étendue de récursivité nommée InternalClients avec la récursivité activée. Et la troisième ligne crée une stratégie pour appliquer l’étendue de récursivité nouvellement créée à toutes les requêtes entrantes via une interface de serveur dont l’adresse IP est 10.0.0.34.
Créer une stratégie de transfert de zone au niveau du serveur
Vous pouvez contrôler le transfert de zone sous une forme plus granulaire à l’aide de stratégies de transfert de zone DNS. L’exemple de script ci-dessous peut être utilisé pour autoriser les transferts de zone pour n’importe quel serveur sur un sous-réseau donné :
Add-DnsServerClientSubnet -Name "AllowedSubnet" -IPv4Subnet 172.21.33.0/24
Add-DnsServerZoneTransferPolicy -Name "NorthAmericaPolicy" -Action IGNORE -ClientSubnet "ne,AllowedSubnet"
La première ligne du script crée un objet de sous-réseau nommé AllowedSubnet avec le bloc IP 172.21.33.0/24. La deuxième ligne crée une stratégie de transfert de zone pour autoriser les transferts de zone vers n’importe quel serveur DNS sur le sous-réseau créé précédemment.
Créer une stratégie de transfert de zone au niveau de la zone
Vous pouvez également créer des stratégies de transfert de zone au niveau de la zone. L’exemple ci-dessous ignore toute demande de transfert de zone pour contoso.com provenant d’une interface serveur dont l’adresse IP est 10.0.0.33 :
Add-DnsServerZoneTransferPolicy -Name "InternalTransfers" -Action IGNORE -ServerInterfaceIP "eq,10.0.0.33" -PassThru -ZoneName "contoso.com"
Scénarios de stratégie DNS
Pour plus d’informations sur l’utilisation de la stratégie DNS pour des scénarios spécifiques, consultez les rubriques suivantes dans ce guide.
- Utiliser une stratégie DNS pour la gestion du trafic basée sur la géolocalisation avec des serveurs principaux
- Utiliser une stratégie DNS pour la gestion du trafic basée sur la géolocalisation avec des déploiements principaux/secondaires
- Utiliser une stratégie DNS pour les réponses DNS intelligentes basées sur l’heure du jour
- Réponses DNS basées sur l’heure de la journée avec un serveur d’applications cloud Azure
- Utiliser une stratégie DNS pour un déploiement DNS de fractionnement du cerveau
- Utiliser une stratégie DNS pour un déploiement DNS de fractionnement du cerveau dans Active Directory
- Utiliser une stratégie DNS pour l’application de filtres sur les requêtes DNS
- Utiliser une stratégie DNS pour l’équilibrage de charge des applications
- Utiliser une stratégie DNS pour l’équilibrage de charge des applications avec connaissance de la géolocalisation
Utiliser la stratégie DNS sur les contrôleurs de domaine en lecture seule
La stratégie DNS est compatible avec les contrôleurs de domaine en lecture seule. Notez qu’un redémarrage du service serveur DNS est nécessaire pour que les nouvelles stratégies DNS soient chargées sur les contrôleurs de domaine en lecture seule. Cela n’est pas nécessaire sur les contrôleurs de domaine accessibles en écriture.