Documentation Produit
ADC
14.1 - Current Release 13.1 13.0 12.1
Voir PDF

Comment le système de noms de domaine prend en charge GSLB

October 4, 2021
Contributeur: 
C

Le système de noms de domaine (DNS) est considéré comme une base de données distribuée, qui utilise l’architecture Client/Serveur. Les serveurs de noms sont les serveurs de l’architecture, et les résolveurs sont les clients qui sont des routines de bibliothèque installées sur un système d’exploitation qui créent et envoient des requêtes sur le réseau.

La hiérarchie logique du DNS est illustrée dans le diagramme suivant :

Hiérarchie DNS logique

Remarque :

Les serveurs racine de deuxième niveau sont responsables de la gestion des mappages Name Server to Address pour les délégations de serveurs de noms dans les domaines .com, .net, .org, .gov, etc. Chaque domaine des domaines de deuxième niveau est responsable de la gestion des mappages Serveur de noms à adresse pour les domaines organisationnels de niveau inférieur. Au niveau de l’organisation, les adresses d’hôte individuelles sont résolues pour les hôtes www, FTP et autres hôtes fournissant des services.

Délégation

L’objectif principal de la topologie DNS actuelle est d’alléger la charge de gestion de tous les enregistrements d’adresses sur une seule autorité. Cela permet de déléguer un espace de noms d’organisation à cette organisation particulière. L’organisation peut ensuite déléguer davantage son espace à des sous-domaines au sein de l’organisation. Par exemple, sous citrix.com, vous pouvez créer des sous-domaines appelés sales.citrix.comeducation.citrix.com, et support.citrix.com. Les services correspondants peuvent conserver leur propre ensemble de serveurs de noms qui font autorité pour leur sous-domaine, puis conserver leur propre ensemble de noms d’hôte pour les mappages d’adresses. Aucun service n’est responsable de la gestion de tous les enregistrements d’adresses Citrix. Chaque département peut modifier les adresses et modifier les topologies, sans imposer davantage de travail au domaine ou à l’organisation de niveau supérieur.

Avantages de la topologie hiérarchique

Voici quelques-uns des avantages de la topologie hiérarchique :

  • Capacité à monter en charge
  • Ajout d’une fonctionnalité de mise en cache dans les serveurs de noms à chaque niveau, où une requête DNS est gérée par un hôte qui ne fait pas autorité pour un domaine particulier, mais qui peut contribuer à la réponse à la requête et réduire la congestion et le temps de réponse.
  • La mise en cache crée également une redondance et une résilience face aux défaillances du serveur. Si un serveur de noms échoue, il est toujours possible que des enregistrements soient diffusés à partir d’autres serveurs disposant de copies mises en cache récentes des mêmes enregistrements.

Résolveurs

Les résolveurs sont le composant client du système DNS. Les programmes exécutés sur un hôte qui ont besoin d’informations provenant de l’espace de noms de domaine utilisent le résolveur. Le résolveur gère :

  • Interrogation d’un serveur de noms.
  • Interprétation des réponses (qui peuvent être des enregistrements de ressources ou une erreur).
  • Renvoyer l’information aux programmes qui en ont fait la demande.

Le résolveur est un ensemble de routines de bibliothèque compilées dans des programmes tels que telnet, FTP et ping. Il ne s’agit pas de processus distincts. Les résolveurs peuvent créer une requête, l’envoyer et attendre une réponse. Et, envoyez-le à nouveau (éventuellement à un serveur de noms secondaire) s’il n’y a pas de réponse dans un certain temps. Ces types de résolveurs sont appelés résolveurs de talon. Certains résolveurs ont la fonctionnalité ajoutée pour mettre en cache les enregistrements et respectent le temps de vie (TTL). Sous Windows, cette fonctionnalité est disponible via le service Client DNS ; elle peut être consultée via la console « services.msc ».

Serveurs de noms

Les serveurs de noms stockent généralement des informations complètes sur une partie particulière d’un espace de noms de domaine (appelée zone). On dit alors que le serveur de noms est autorisé pour cette zone. Ils peuvent également faire autorité pour plusieurs zones.

La différence entre un domaine et une zone est subtile. Un domaine est l’ensemble complet des entités, y compris ses sous-domaines, tandis qu’une zone est uniquement l’information d’un domaine qui n’est pas déléguée à un autre serveur de noms. Un exemple de zone est citrix.com, alors qu’il s’ sales.citrix.com agit d’une zone distincte si cette zone est déléguée à un autre serveur de noms au sein du sous-domaine. Dans ce cas, la zone Citrix principale peut inclure citrix.comit.citrix.com, et support.citrix.com. Étant donné que le sales.citrix.com est délégué, il ne fait pas partie de la zone sur laquelle le serveur de citrix.com noms fait autorité. Le diagramme suivant montre les deux zones.

Zones DNS

Pour déléguer correctement un sous-domaine, vous devez attribuer des pouvoirs pour ce sous-domaine à différents serveurs de noms. Dans l’exemple précédent, le ns1.citrix.com ne contient pas d’informations sur le sales.citrix.com sous-domaine. Il contient plutôt des pointeurs vers les serveurs de noms qui font autorité pour le ns1.sales.citrix.com sous-domaine.

Serveurs de noms racine et résolution des requêtes

Les serveurs de noms racine connaissent les adresses IP de tous les serveurs de noms faisant autorité pour les domaines de deuxième niveau. Si un serveur de noms ne dispose pas d’informations sur un domaine donné dans ses propres fichiers de données, il n’a qu’à contacter un serveur racine pour commencer à parcourir la branche appropriée de l’arborescence DNS afin d’accéder au domaine donné. Il s’agit d’une série de demandes adressées à plusieurs serveurs de noms afin de faciliter la traversée de l’arborescence afin de trouver le prochain serveur de noms faisant autorité, qui doit être contacté pour une résolution ultérieure.

Le diagramme suivant montre une requête DNS typique, en supposant qu’il n’y ait pas d’enregistrement mis en cache pour le nom demandé pendant la traversée. L’exemple suivant utilise une maquette du domaine Citrix.

Zones DNS

Requêtes récursives et non récursives

L’exemple précédent illustre les deux types de requêtes pouvant survenir.

  • Requête récursive : La requête entre le résolveur et le serveur de noms configuré localement est récursive. Cela signifie que le serveur de noms reçoit la requête et ne répond pas au résolveur tant que la requête n’a pas reçu une réponse complète ou qu’une erreur n’a pas été renvoyée. Si le serveur de noms reçoit une référence vers la requête, le serveur de noms suit la référence jusqu’à ce que le serveur de noms reçoive enfin la réponse (adresse IP) renvoyée.

  • Requête non récursive : La requête que le serveur de noms configuré localement effectue sur le serveur de noms de domaine faisant autorité ultérieur est non récursive (ou itérative). Chaque demande est immédiatement répondue par un renvoi vers un serveur faisant autorité de niveau inférieur ou la réponse à la requête, si le serveur de noms interrogé contient la réponse dans ses fichiers de données ou dans son cache.

Mise en cache

Bien que le processus de résolution soit impliqué et peut nécessiter de petites requêtes à plusieurs hôtes, il est rapide. L’un des facteurs qui augmente la vitesse de résolution DNS est la mise en cache. Chaque fois qu’un serveur Name reçoit une requête récursive, il peut devoir communiquer avec d’autres serveurs pour accéder au serveur faisant autorité approprié pour la demande spécifique. Il stocke toutes les informations qu’il reçoit pour référence ultérieure. Lorsque le client suivant émet une demande similaire, par exemple un hôte différent mais dans le même domaine, il connaît déjà le serveur de noms qui fait autorité pour ce domaine et peut envoyer une demande directement là au lieu de commencer par le serveur de noms racine.

La mise en cache peut également se produire pour les réponses négatives, telles que les requêtes pour les hôtes qui n’existent pas. Dans ce cas, le serveur ne doit pas interroger le serveur de noms faisant autorité pour le domaine demandé pour déterminer que l’hôte n’existe pas. Pour gagner du temps, le serveur de noms vérifie simplement le cache et réagit avec l’enregistrement négatif.

Les serveurs de noms ne mettent pas en cache les enregistrements indéfiniment, sinon vous ne pouvez jamais mettre à jour les adresses IP. Pour éviter les problèmes de synchronisation, les réponses DNS contiennent une durée de vie (TTL). Ce champ décrit l’intervalle de temps pendant lequel le cache peut stocker un enregistrement avant qu’il ne doive l’abandonner et vérifier auprès du serveur de noms faisant autorité pour les enregistrements mis à jour. Si les enregistrements n’ont pas été modifiés, l’utilisation de TTL permet également des réponses dynamiques rapides des appareils exécutant GSLB.

Types d’enregistrements de ressources

Divers RFC fournissent une liste complète des types d’enregistrements de ressources DNS et de leur description. Le tableau suivant répertorie les types d’enregistrements de ressources courants.

Type d’enregistrement de ressource Description RFC      
Une Une adresse d’hôte RFC 1035      
NS Un serveur de noms faisant autorité RFC 1035      
MARYLAND Une destination de messagerie (obsolète - utiliser MX) RFC 1035      
MF Un redirecteur de courrier (obsolète - utiliser MX) RFC 1035      
CNAME Nom canonique d’un alias RFC 1035 SOA Marque le début d’une zone d’autorité
WKS Une description de service bien connue RFC 1035      
PTR Un pointeur de nom de domaine RFC 1035      
HINFO Informations sur l’hôte RFC 1035      
MINFO Informations sur la boîte aux lettres ou la liste de diffusion RFC 1035      
MX Courrier Exchange RFC 1035      
TXT Chaînes de texte RFC 1035      
AAAA Adresse IP6 RFC 3596      
SRV Sélection du serveur RFC 2782]      

Comment GSLB prend en charge le DNS

GSLB utilise des algorithmes et des protocoles qui décident quelle adresse IP doit être envoyée pour une requête DNS. Les sites GSLB sont distribués géographiquement et il existe un serveur de noms faisant autorité DNS sur chaque site exécuté en tant que service sur l’appliance Citrix ADC. Tous les serveurs de noms des différents sites concernés font autorité pour le même domaine. Chacun des domaines GSLB est un sous-domaine pour lequel une délégation est configurée. Par conséquent, les serveurs de noms GSLB font autorité et peuvent utiliser l’un des différents algorithmes d’équilibrage de charge pour décider de l’adresse IP à renvoyer.

Une délégation est créée en ajoutant un enregistrement de serveur de noms pour le domaine GSLB dans les fichiers de base de données du domaine parent et un enregistrement d’adresse ultérieur pour les serveurs de noms utilisés pour la délégation. Par exemple, si vous souhaitez utiliser GSLB pour www.citrix.com, le fichier SOA Bind suivant peut être utilisé pour déléguer des demandes www.citrix.com à des serveurs de noms : Netscaler1 et Netscaler2.

###########################################################################
@ IN SOA citrix.com. hostmaster.citrix.com. (
1 ; serial
3h ; refresh
1h ; retry
1w ; expire
1h ) ; negative caching TTL
IN NS ns1
IN NS ns2
IN MX 10 mail

ns1   IN A 10.10.10.10
ns2   IN A 10.10.10.20
mail  IN A 10.20.20.50

### Old Configuration if www was not delegated to a GSLB name server
www IN A 10.20.20.50

### Updated Configuration
Netscaler1 IN A xxx.xxx.xxx.xxx
Netscaler2 IN A yyy.yyy.yyy.yyy
www IN NS Netscaler1.citrix.com.
www IN NS Netscaler2.citrix.com.
###
IN MX 20 mail2
mail2 IN A 10.50.50.20
###########################################################################

<!--NeedCopy-->

La compréhension de BIND n’est pas obligatoire pour configurer DNS. Toutes les implémentations de serveur DNS conformes disposent d’une méthode permettant de créer la délégation équivalente. Les serveurs DNS Microsoft peuvent être configurés pour délégation en utilisant les instructions de la section Créer une délégation de zone ? RedirectedFrom=MSDN).

Ce qui différencie GSLB sur l’appliance Citrix ADC de l’utilisation du service DNS standard pour la distribution du trafic, c’est que les sites Citrix ADC GSLB échangent des données à l’aide d’un protocole propriétaire appelé Metric Exchange Protocol (MEP). Avec MEP, les sites GSLB sont en mesure de conserver des informations sur tous les autres sites. Lorsqu’une demande DNS est reçue, le MEP prend en compte les mesures GSLB pour déterminer les informations suivantes :

  • Site avec le moins de connexions actuelles
  • Site le plus proche du serveur LDNS, qui a envoyé la demande en fonction des temps aller-retour (RTT).

Plusieurs algorithmes d’équilibrage de charge peuvent être utilisés, mais GSLB est un DNS dont le cerveau est en dessous indiquant au serveur de noms (hébergé sur l’appliance Citrix ADC) quelle adresse doit être envoyée en fonction des mesures des sites participants.

Les autres avantages que GSLB offre sont la capacité de maintenir la persistance (ou l’affinité du site). Les réponses aux requêtes DNS entrantes peuvent être comparées à l’adresse IP source pour déterminer si cette adresse a été dirigée vers un site particulier dans un passé récent. Si c’est le cas, la même adresse est envoyée dans la réponse DNS pour s’assurer que la session client est maintenue.

Une autre forme de persistance est obtenue au niveau du site à l’aide de redirections HTTP ou de proxy HTTP. Ces formes de persistance se produisent après la réponse DNS. Par conséquent, si vous recevez une demande HTTP sur un site contenant un cookie pour diriger la demande vers un autre site participant, vous pouvez répondre par une redirection ou envoyer un proxy à la demande vers le site approprié.

Protocole d’échange de mesures

Le protocole MEP (Metric Exchange Protocol) est utilisé pour partager les données utilisées dans les calculs GSLB entre sites. À l’aide de connexions MEP, vous échangez trois types de données. Ces connexions n’ont pas besoin d’être sécurisées via le port TCP 3011 ou peuvent être sécurisées à l’aide du port SSL sur le port TCP 3009.

Les trois types de données suivants sont échangés et possèdent leurs propres intervalles et méthodes d’échange.

  • Échange de mesures de site : Il s’agit d’un modèle d’échange d’interrogation. Par exemple, si site1 dispose d’une configuration pour les services site2, un site1 demande à site2 l’état des services GSLB chaque seconde. Site2 répond avec l’état et d’autres détails de chargement.

  • Échange de mesures réseau : Il s’agit de l’échange d’informations LDNS RTT, utilisé dans l’algorithme d’équilibrage de charge de proximité dynamique. Il s’agit d’un modèle d’échange push. Toutes les cinq secondes, chaque site transmet ses données vers d’autres sites participants.

  • Échange de persistance : Il s’agit de l’échange de persistance SOURCEIP. Il s’agit également d’un modèle d’échange push. Toutes les cinq secondes, chaque site transmet ses données vers d’autres sites participants.

Par défaut, les services de site sont surveillés par MEP sur la base des informations d’interrogation uniquement. Si vous liez des moniteurs en fonction de l’intervalle de surveillance, l’état est mis à jour et vous pouvez contrôler la fréquence des mises à jour en définissant l’intervalle de surveillance en conséquence.

Comment le système de noms de domaine prend en charge GSLB
October 4, 2021
Contributeur: 
C
October 4, 2021
Contributeur: 
C

Dans cet article

Commentaires sur le site | Your privacy choices footer linkVos préférences de confidentialité | Confidentialité et conditions légales | Préférences de cookies | Paramètres de consentement | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.