Utiliser une stratégie DNS pour la gestion du trafic basée sur la géolocalisation avec des déploiements principaux/secondaires

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Vous pouvez utiliser cette rubrique pour apprendre à créer une stratégie DNS pour la gestion du trafic basée sur la géolocalisation lorsque votre déploiement DNS inclut à la fois des serveurs DNS primaires et secondaires.

Le scénario précédent, Utiliser une stratégie DNS pour la gestion du trafic basée sur la géolocalisation avec des serveurs primaires, fournissait des instructions pour la configuration de la stratégie DNS pour la gestion du trafic basée sur la géolocalisation sur un serveur DNS primaire. Dans l’infrastructure Internet, toutefois, les serveurs DNS sont largement déployés dans un modèle primaire-secondaire, où la copie accessible en écriture d’une zone est stockée sur des serveurs primaires sélectionnés et sécurisés, et les copies en lecture seule de la zone sont conservées sur plusieurs serveurs secondaires.

Les serveurs secondaires utilisent les protocoles de transfert de zone faisant autorité (AXFR) et de transfert de zone incrémentiel (IXFR) pour demander et recevoir des mises à jour de zone qui incluent de nouvelles modifications apportées aux zones sur les serveurs DNS primaires.

Notes

Pour plus d’informations sur AXFR, consultez l’Internet Engineering Task Force (IETF) Requête pour commentaires 5936. Pour plus d’informations sur IXFR, consultez l’Internet Engineering Task Force (IETF) Requête pour commentaires 1995.

Exemple de gestion du trafic basée sur la géolocalisation primaire et secondaire

Voici un exemple de la façon dont vous pouvez utiliser la stratégie DNS dans un déploiement primaire-secondaire pour obtenir la redirection du trafic sur la base de l’emplacement physique du client qui exécute une requête DNS.

Cet exemple utilise deux sociétés fictives : Contoso Cloud Services, qui fournit des solutions d’hébergement web et d’hébergement de domaine, et Woodgrove Food Services, qui fournit des services de livraison de nourriture dans plusieurs villes à travers le monde, et qui dispose d’un site Web nommé woodgrove.com.

Pour s’assurer que les clients woodgrove.com bénéficient d’une expérience réactive à partir de leur site web, Woodgrove souhaite que les clients européens soient dirigés vers le centre de données européen et les clients américains vers le centre de données américain. Les clients situés ailleurs dans le monde peuvent être dirigés vers l’un des centres de données.

Contoso Services cloud dispose de deux centres de données, l’un aux États-Unis et l’autre en Europe, sur lesquels Contoso héberge son portail de commandes alimentaires pour woodgrove.com.

Le déploiement DNS de Contoso comprend deux serveurs secondaires : SecondaryServer1, avec l’adresse IP 10.0.0.2 ; et SecondaryServer2, avec l’adresse IP 10.0.0.3. Ces serveurs secondaires agissent en tant que serveurs de noms dans les deux régions différentes, SecondaryServer1 situé en Europe et SecondaryServer2 situé aux États-Unis.

Il existe une copie de zone primaire inscriptible sur PrimaryServer (adresse IP 10.0.0.1), où les modifications de zone sont effectuées. Avec des transferts de zone réguliers vers les serveurs secondaires, les serveurs secondaires sont toujours à jour avec les nouvelles modifications apportées à la zone sur le serveur primaire.

L’illustration suivante représente ce scénario.

Fonctionnement du système primaire et secondaire du DNS

Lorsque vous déployez la gestion du trafic basée sur la géolocalisation dans un déploiement DNS primaire-secondaire, il est important de comprendre comment se produisent les transferts normaux de zone primaire-secondaire avant d’en savoir plus sur les transferts au niveau de l’étendue de zone. Les sections suivantes fournissent des informations sur les transferts au niveau de la zone et de l’étendue de la zone.

• Transferts de zone dans un déploiement DNS primaire-secondaire
• Transferts au niveau de l’étendue de la zone dans un déploiement DNS primaire-secondaire

Transferts de zone dans un déploiement DNS primaire-secondaire

Vous pouvez créer un déploiement DNS primaire-secondaire et synchroniser les zones en suivant les étapes suivantes.

1. Lorsque vous installez DNS, la zone primaire est créée sur le serveur DNS primaire.
2. Sur le serveur secondaire, créez les zones et spécifiez les serveurs primaires.
3. Sur les serveurs primaires, vous pouvez ajouter les serveurs secondaires en tant que serveurs secondaires approuvés sur la zone primaire.
4. Les zones secondaires effectuent une requête de transfert de zone complète (AXFR) et reçoivent la copie de la zone.
5. Si nécessaire, les serveurs primaires envoient des notifications aux serveurs secondaires concernant les mises à jour de la zone.
6. Les serveurs secondaires effectuent une requête de transfert de zone incrémentielle (IXFR). Pour cette raison, les serveurs secondaires restent synchronisés avec le serveur primaire.

Transferts au niveau de l’étendue de la zone dans un déploiement DNS primaire-secondaire

Le scénario de gestion du trafic nécessite des étapes supplémentaires pour diviser les zones en différents périmètres. Pour cette raison, des étapes supplémentaires sont nécessaires pour transférer les données à l’intérieur des étendues de zone vers les serveurs secondaires et pour transférer des stratégies et des sous-réseaux clients DNS vers les serveurs secondaires.

Après avoir configuré votre infrastructure DNS avec des serveurs primaires et secondaires, les transferts au niveau de l’étendue de la zone sont effectués automatiquement par DNS, à l’aide des processus suivants.

Pour garantir le transfert au niveau de l’étendue de la zone, les serveurs DNS utilisent les mécanismes d’extension pour DNS (EDNS0) OPT RR. Toutes les requêtes de transfert de zone (AXFR ou IXFR) des zones avec étendues proviennent d’un EDNS0 OPT RR, dont l’ID d’option est défini sur « 65433 » par défaut. Pour plus d’informations sur EDNSO, consultez la Requête de commentaires 6891 de l’IETF.

La valeur d’OPT RR est le nom d’étendue de zone pour lequel la requête est envoyée. Lorsqu’un serveur DNS primaire reçoit ce paquet d’un serveur secondaire approuvé, il interprète la requête comme étant destinée à cette étendue de zone.

Si le serveur primaire dispose de cette zone, il répond avec les données de transfert (XFR) de cette étendue. La réponse contient un RR OPT avec le même ID d’option « 65433 » et la même valeur définie pour la même étendue de zone. Les serveurs secondaires reçoivent cette réponse, récupèrent les informations d’étendue de la réponse et mettent à jour cette étendue particulière de la zone.

Après ce processus, le serveur primaire gère une liste de fichiers secondaires approuvés qui ont envoyé une requête d’étendue de zone de ce type pour les notifications.

Pour toute mise à jour supplémentaire dans une étendue de zone, une notification IXFR est envoyée aux serveurs secondaires, avec le même OPT RR. L’étendue de zone recevant cette notification effectue la requête IXFR contenant cette OPT RR et le même processus que celui décrit ci-dessus s’ensuit.

Comment configurer une stratégie DNS pour la gestion du trafic basée sur la géolocalisation primaire et secondaire

Avant de commencer, vérifiez que vous avez effectué toutes les étapes de la rubrique Utiliser la stratégie DNS pour la gestion du trafic basée sur la géolocalisation avec les serveurs primaires, et que votre serveur DNS primaire est configuré avec des zones, des étendues de zone, des sous-réseaux client DNS et une stratégie DNS.

Notes

Les instructions de cette rubrique pour copier les sous-réseaux client DNS, les étendues de zone et les stratégies DNS des serveurs principaux DNS vers des serveurs secondaires DNS concernent la configuration et la validation DNS initiales. À l’avenir, vous souhaiterez peut-être modifier les paramètres des sous-réseaux du client DNS, des étendues de zone et des stratégies sur le serveur primaire. Dans ce cas, vous pouvez créer des scripts d’automatisation pour maintenir la synchronisation des serveurs secondaires avec le serveur primaire.

Pour configurer la stratégie DNS pour les réponses de requête basées sur la géolocalisation primaire-secondaire, vous devez effectuer les étapes suivantes.

• Créer les zones secondaires
• Configurer les paramètres de transfert de zone sur la zone primaire
• Copier les sous-réseaux clients DNS
• Créer les étendues de zone sur le serveur secondaire
• Configurer la stratégie DNS

Les sections suivantes fournissent des instructions de configuration détaillées.

Important

Les sections suivantes incluent des exemples de commandes Windows PowerShell qui contiennent des exemples de valeurs pour de nombreux paramètres. Veillez à remplacer les exemples de valeurs dans ces commandes par des valeurs appropriées à votre déploiement avant d’exécuter ces commandes.

L’adhésion à DnsAdmins, ou un équivalent, est nécessaire pour effectuer les procédures suivantes.

Créez les zones secondaires

Vous pouvez créer la copie secondaire de la zone à répliquer sur SecondaryServer1 et SecondaryServer2 (en supposant que les applets de commande sont exécutées à distance à partir d’un seul client de gestion).

Par exemple, vous pouvez créer la copie secondaire de www.woodgrove.com sur SecondaryServer1 et SecondarySesrver2.

Vous pouvez utiliser les commandes Windows PowerShell suivantes pour créer les zones secondaires.

Add-DnsServerSecondaryZone -Name "woodgrove.com" -ZoneFile "woodgrove.com.dns" -MasterServers 10.0.0.1 -ComputerName SecondaryServer1
Add-DnsServerSecondaryZone -Name "woodgrove.com" -ZoneFile "woodgrove.com.dns" -MasterServers 10.0.0.1 -ComputerName SecondaryServer2

Pour plus d’informations, consultez Add-DnsServerSecondaryZone.

Configurez les paramètres de transfert de zone sur la zone primaire

Vous devez configurer les paramètres de zone primaire afin que :

1. Les transferts de zone du serveur primaire vers les serveurs secondaires spécifiés sont autorisés.
2. Les notifications de mise à jour de zone sont envoyées par le serveur primaire aux serveurs secondaires.

Vous pouvez utiliser les commandes Windows PowerShell suivantes pour configurer les paramètres de transfert de zone sur la zone primaire.

Notes

Dans l’exemple de commande suivant, le paramètre -Notify spécifie que le serveur primaire enverra des notifications sur les mises à jour à la liste sélectionnée des serveurs secondaires.

Set-DnsServerPrimaryZone -Name "woodgrove.com" -Notify Notify -SecondaryServers "10.0.0.2,10.0.0.3" -SecureSecondaries TransferToSecureServers -ComputerName PrimaryServer

Pour plus d’informations, consultez Set-DnsServerPrimaryZone.

Copiez les sous-réseaux clients DNS

Vous devez copier les sous-réseaux clients DNS du serveur primaire vers les serveurs secondaires.

Vous pouvez utiliser les commandes Windows PowerShell suivantes pour copier les sous-réseaux sur les serveurs secondaires.

Get-DnsServerClientSubnet -ComputerName PrimaryServer | Add-DnsServerClientSubnet -ComputerName SecondaryServer1
Get-DnsServerClientSubnet -ComputerName PrimaryServer | Add-DnsServerClientSubnet -ComputerName SecondaryServer2

Pour plus d’informations, consultez Add-DnsServerClientSubnet.

Créez les étendues de zone sur le serveur secondaire

Vous devez créer les étendues de zone sur les serveurs secondaires. Dans DNS, les étendues de zone commencent également à demander des XFR auprès du serveur principal. En cas de modification des étendues de zone sur le serveur primaire, une notification contenant les informations d’étendue de zone est envoyée aux serveurs secondaires. Les serveurs secondaires peuvent ensuite mettre à jour leurs étendues de zone avec une modification incrémentielle.

Vous pouvez utiliser les commandes Windows PowerShell suivantes pour créer les étendues de zone sur les serveurs secondaires.

Get-DnsServerZoneScope -ZoneName "woodgrove.com" -ComputerName PrimaryServer|Add-DnsServerZoneScope -ZoneName "woodgrove.com" -ComputerName SecondaryServer1 -ErrorAction Ignore
Get-DnsServerZoneScope -ZoneName "woodgrove.com" -ComputerName PrimaryServer|Add-DnsServerZoneScope -ZoneName "woodgrove.com" -ComputerName SecondaryServer2 -ErrorAction Ignore

Notes

Dans ces exemples de commandes, le paramètre -ErrorAction Ignore est inclus, car une étendue de zone par défaut existe sur chaque zone. L’étendue de zone par défaut ne peut pas être créée ou supprimée. Le traitement en pipeline entraînera une tentative de création de cette étendue, qui échouera. Vous pouvez également créer des étendues de zone autres que les étendues par défaut sur deux zones secondaires.

Pour plus d’informations, consultez Add-DnsServerZoneScope.

Configurez la stratégie DNS

Après avoir créé les sous-réseaux, les partitions (étendues de zone) et ajouté des enregistrements, vous devez créer des stratégies qui connectent les sous-réseaux et les partitions, de sorte que lorsqu’une requête provient d’une source dans l’un des sous-réseaux clients DNS, la réponse à la requête est retournée à partir de l’étendue correcte de la zone. Aucune stratégie n’est requise pour le mappage de l’étendue de zone par défaut.

Vous pouvez utiliser les commandes Windows PowerShell suivantes pour créer une stratégie DNS qui lie les sous-réseaux du client DNS et les étendues de zone.

$policy = Get-DnsServerQueryResolutionPolicy -ZoneName "woodgrove.com" -ComputerName PrimaryServer
$policy | Add-DnsServerQueryResolutionPolicy -ZoneName "woodgrove.com" -ComputerName SecondaryServer1
$policy | Add-DnsServerQueryResolutionPolicy -ZoneName "woodgrove.com" -ComputerName SecondaryServer2

Pour plus d’informations, consultez Add-DnsServerQueryResolutionPolicy.

À présent, les serveurs DNS secondaires sont configurés avec les stratégies DNS requises pour rediriger le trafic en fonction de la géolocalisation.

Lorsque le serveur DNS reçoit des requêtes de résolution de noms, le serveur DNS évalue les champs de la requête DNS par rapport aux stratégies DNS configurées. Si l’adresse IP source dans la demande de résolution de noms correspond à l’une des stratégies, l’étendue de zone associée est utilisée pour répondre à la requête et l’utilisateur est dirigé vers la ressource qui est géographiquement la plus proche d’elle.

Vous pouvez créer des milliers de stratégies DNS en fonction de vos exigences de gestion du trafic, et toutes les nouvelles stratégies sont appliquées dynamiquement, sans redémarrer le serveur DNS, sur les requêtes entrantes.