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.com``education.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.

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

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 :

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

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.com``it.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.

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.

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.

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

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.

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.

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 répartis géographiquement et il existe un serveur de noms DNS faisant autorité sur chaque site qui s'exécute en tant que service sur l'appliance NetScaler. 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.

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.

Ce qui différencie le GSLB sur l'appliance NetScaler de l'utilisation du service DNS standard pour la distribution du trafic est que les sites NetScaler 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 :

Plusieurs algorithmes d'équilibrage de charge peuvent être utilisés, mais le GSLB est un DNS dans lequel le cerveau sous-jacent indique au serveur de noms (hébergé sur l'appliance NetScaler) quelle adresse doit être envoyée en fonction des métriques 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é.

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.

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.