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

  • Article
  • 9 minutes de lecture

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 des serveurs DNS principaux et secondaires.

Le scénario précédent, Utiliser une stratégie DNS pour la gestion du trafic basée sur Geo-Location avec les serveurs principaux, fournissait des instructions pour configurer la stratégie DNS pour la gestion du trafic basée sur la géolocalisation sur un serveur DNS principal. Dans l’infrastructure Internet, toutefois, les serveurs DNS sont largement déployés dans un modèle principal-secondaire, où la copie accessible en écriture d’une zone est stockée sur des serveurs principaux sélectionnés et sécurisés, et des 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 le transfert incrémentiel de zone (IXFR) pour demander et recevoir des mises à jour de zone qui incluent de nouvelles modifications apportées aux zones sur les serveurs DNS principaux.

Notes

Pour plus d’informations sur AXFR, consultez la demande de commentaires de l’Internet Engineering Task Force (IETF) 5936. Pour plus d’informations sur IXFR, consultez l’Internet Engineering Task Force (IETF) Request for Comments 1995.

Exemple de gestion du trafic basé sur Primary-Secondary Geo-Location

Voici un exemple de la façon dont vous pouvez utiliser la stratégie DNS dans un déploiement principal-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 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 jouent le rôle de serveurs de noms dans les deux régions différentes, SecondaryServer1 étant situé en Europe et SecondaryServer2 situé aux États-Unis.

Il existe une copie de zone accessible en écriture principale sur PrimaryServer (adresse IP 10.0.0.1), où les modifications de zone sont apportées. Avec les 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 principal.

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

Exemple de gestion du trafic basé sur les Geo-Location primaires et secondaires

Fonctionnement du système de Primary-Secondary DNS

Lorsque vous déployez la gestion du trafic basée sur la géolocalité dans un déploiement DNS principal-secondaire, il est important de comprendre comment les transferts de zone primaire-secondaire normale se produisent 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 zone.

Transferts de zone dans un déploiement dns principal-secondaire

Vous pouvez créer un déploiement DNS principal-secondaire et synchroniser des zones en procédant comme suit.

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

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

Le scénario de gestion du trafic nécessite des étapes supplémentaires pour partitionner les zones dans différentes étendues de zone. 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 les stratégies et les sous-réseaux clients DNS vers les serveurs secondaires.

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

Pour garantir le transfert au niveau de l’étendue de zone, les serveurs DNS utilisent les mécanismes d’extension pour DNS (EDNS0) OPT RR. Toutes les demandes 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 IETF Request for Comments 6891.

La valeur de l’OPTION RR est le nom de l’étendue de zone pour laquelle la demande est envoyée. Lorsqu’un serveur DNS principal reçoit ce paquet d’un serveur secondaire approuvé, il interprète la requête comme provenant de cette étendue de zone.

Si le serveur principal a cette étendue de 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 valeur définie sur 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 principal gère une liste de serveurs secondaires approuvés qui ont envoyé une demande d’étendue de zone 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.

Comment configurer une stratégie DNS pour la gestion du trafic basée sur Primary-Secondary Geo-Location

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 Geo-Location avec des serveurs principaux, et que votre serveur DNS principal 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 clients DNS, les étendues de zone et les stratégies DNS des serveurs principaux DNS vers des serveurs secondaires DNS concernent votre configuration et validation DNS initiales. À l’avenir, vous souhaiterez peut-être modifier les paramètres des sous-réseaux clients DNS, des étendues de zone et des stratégies sur le serveur principal. Dans ce cas, vous pouvez créer des scripts d’automatisation pour maintenir la synchronisation des serveurs secondaires avec le serveur principal.

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.

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éer les zones secondaires

Vous pouvez créer la copie secondaire de la zone que vous souhaitez 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.

Configurer les paramètres de transfert de zone sur la zone principale

Vous devez configurer les paramètres de zone principale de sorte que :

  1. Les transferts de zone du serveur principal vers les serveurs secondaires spécifiés sont autorisés.
  2. Les notifications de mise à jour de zone sont envoyées par le serveur principal 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 principal envoie des notifications sur les mises à jour à la liste de sélection des 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.

Copier les sous-réseaux clients DNS

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

Vous pouvez utiliser les commandes Windows PowerShell suivantes pour copier les sous-réseaux vers 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éer 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 fichiers XFR au serveur principal. En cas de modification des étendues de zone sur le serveur principal, 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 des modifications incrémentielles.

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 pipelining entraîne une tentative de création de cette étendue et échoue. 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.

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