Comment utiliser Amazon Route 53?

Comprenez que la route 53 peut à première vue être utilisée pour faire quelque chose comme l'équilibrage de charge.

• Par exemple, si vous souhaitez équilibrer le trafic entrant sur trois serveurs, vous pouvez définir un enregistrement Route 53 A avec les adresses IP de tous les serveurs. Vous pouvez également configurer plusieurs enregistrements Route 53 A avec des poids différents, à l'aide d'une politique de routage pondérée (décrite plus loin sur cette page).
• Inversement, vous pouvez utiliser un équilibreur de charge pour recevoir le trafic entrant, puis utiliser cet équilibreur de charge pour transférer le trafic vers les différents serveurs.

Comprenez que puisque l'itinéraire 53 n'inclut aucun point central du flux de trafic, il y a des choses qu'il peut faire que les équilibreurs de charge ne peuvent pas faire.

• Étant donné que le trafic ne passe réellement par aucun point central, Route 53 peut être utilisée pour redistribuer le trafic entre les régions sans ajouter de temps aller-retour à la latence. Avec un équilibreur de charge, le temps d'aller-retour entre l'équilibreur de charge et le serveur qui traite finalement la demande est ajouté à la latence de l'utilisateur final. Par exemple, si nous voulons nous assurer que les gens en Europe sont servis par des serveurs en Europe tandis que les gens en Asie de l'Est sont servis par des serveurs en Asie de l'Est (pour une latence minimale), le routage du trafic via un équilibreur de charge va à l'encontre de l'objectif en raison du tour supplémentaire. -temps de voyage. Cependant, nous pouvons utiliser les enregistrements Route 53 à cette fin sans ajouter de latence, car les enregistrements Route 53 sont résolus localement sans effectuer de déplacement vers un serveur central. De plus, en raison de la mise en cache (jusqu'au TTL) des recherches,même cette résolution locale ne doit être effectuée qu'une fois par minute.
• Route 53 est également plus robuste aux temps d'arrêt, car il dispose d'un grand nombre d'emplacements périphériques qui répondent aux demandes et a été conçu sur la base du principe du travail constant pour éviter les pannes en cascade.
• Le routage basé sur Route 53 présente l'avantage par rapport aux Elastic Load Balancers (ELB) d'Amazon en ce sens qu'il peut évoluer très rapidement vers de grandes charges, alors que les ELB ne peuvent pas gérer assez rapidement des variations de charge très rapides et importantes. Notez que ELB est assez bon pour la plupart des cas d'utilisation, mais, par exemple, la société de journalisation Loggly a constaté que Route 53 servait mieux son cas d'utilisation. Notez que Loggly est inhabituel par rapport à la plupart des services Web ou API qui ont une charge plus régulière ou prévisible. Sa classe de référence est la "gestion des urgences" qui combine l'imprévisibilité avec des changements de charge très rapides à certains moments.

Comprenez que puisque l'itinéraire 53 n'inclut aucun point central du flux de trafic, il ne peut pas faire certaines des choses que les équilibreurs de charge peuvent faire.

• La route 53 ne peut pas être utilisée pour obtenir une vue d'ensemble du trafic total.
• Route 53 n'est pas efficace pour répartir le trafic de manière égale entre les serveurs. En effet, bien que cela permette une stratégie de recherche d'adresses IP à tour de rôle, ce n'est que pour les recherches IP et _pas_ pour les demandes réelles. Par conséquent, si la distribution des sources de demande n'est pas totalement uniforme, alors la distribution du trafic peut également être correspondante non uniforme. Ceci est particulièrement important si vous offrez un service API pour un petit nombre de clients avec une charge élevée par client.
• Route 53 ne peut pas distribuer le trafic équitablement comme le peuvent les équilibreurs de charge. Par exemple, Elastic Load Balancer d'Amazon utilise l'algorithme des moins de connexions: il transmet une requête au serveur avec le moins de requêtes en attente. Cela permet de réduire la charge de trafic sur les serveurs plus lents ou moins réactifs. Cela n'est pas possible dans Route 53 car le trafic ne la traverse même pas et il n'a aucune connaissance des temps de réponse des serveurs individuels.
• Les serveurs ne peuvent pas être ajoutés ou supprimés de Route 53 aussi rapidement que possible avec un équilibreur de charge. Route 53 ne peut pas non plus être intégré directement dans l'autoscaling qu'offre AWS, bien qu'il soit possible d'écrire des scripts qui créent à la fois de nouveaux serveurs et y ajoutent des enregistrements à l'aide de l'API Route 53 en fonction de la charge de trafic actuellement subie, comme le fait la société de journalisation Loggly. Fini.

Avec toutes ces mises en garde, il est important de noter que l'itinéraire 53 et l'équilibrage de charge sont des compléments, pas des concurrents.

• L'équilibrage de charge est le mieux adapté pour répartir équitablement le trafic et maintenir une haute disponibilité dans une région.
• Route 53 est le mieux adapté pour garantir la disponibilité dans les régions, minimiser la latence et gérer la redondance et le basculement entre les régions.

Comprenez que l'itinéraire 53 et les réseaux de diffusion de contenu (CDN) partagent la fonctionnalité qu'ils sont massivement distribués, avec des emplacements périphériques dans le monde entier.

• En fait, le service Route 53 et Amazon CloudFront (le service de type CDN d'Amazon) partagent des emplacements périphériques.

Comprenez que l'itinéraire 53 sert des adresses IP, tandis qu'un CDN sert du contenu.

• L'objectif d'un CDN est de répondre directement à une requête pour une ressource (généralement statique) en servant cette ressource, sans toucher le serveur ou le système de fichiers d'origine qui stocke la ressource. Le CDN actualise la ressource à partir de la source (serveur ou système de fichiers) périodiquement ou lorsque la ressource est explicitement purgée.
• L'objectif de Route 53 et d'autres services DNS gérés est de répondre uniquement aux requêtes de recherche DNS et non de servir le contenu réel.
• Vous pouvez utiliser un CDN pour offrir à tous les utilisateurs de faibles temps aller-retour dans le monde entier (limités par le temps aller-retour jusqu'à l'emplacement périphérique le plus proche), mais Route 53 ne le fait pas.

Comprenez qu'il existe une manière intéressante d'utiliser les cdns comme points centraux du flux de trafic, à savoir, pour accélérer la négociation à trois utilisée pour établir la connexion initiale. Route 53 n'offre pas cela.

Comprenez le concept de zone hébergée publique. Une zone hébergée publique est un conteneur pour tous les jeux d'enregistrements associés à un domaine Web et à ses sous-domaines.

• Chaque zone hébergée publique possède un enregistrement NS (Name Server) qui spécifie les quatre serveurs de noms Amazon à utiliser pour résoudre le domaine et ses sous-domaines. Cet ensemble de quatre serveurs de noms est appelé un ensemble de délégation. Pour migrer les enregistrements DNS vers Amazon Route 53, vous devez mettre à jour la liste de quatre serveurs de noms avec le bureau d'enregistrement (où vous avez enregistré le domaine) vers cet ensemble de quatre serveurs de noms. La mise à jour globale de cette liste peut prendre de 24 à 48 heures.
• Chaque zone hébergée publique possède également un enregistrement SOA (Start of Authority) qui fournit des informations faisant autorité sur le domaine, y compris le serveur de noms principal, l'e-mail de l'administrateur du domaine, le numéro de série du domaine et les minuteries liées à l'actualisation de la zone.
• L'ensemble de délégation est généralement différent pour différentes zones hébergées publiques. Cependant, il est possible d'utiliser l'API Route 53 pour que le même jeu de délégation soit utilisé pour différentes zones hébergées publiques. Cela facilite la migration de l'hébergement pour un grand nombre de sites Web, car de nombreux bureaux d'enregistrement permettent aux utilisateurs de spécifier un ensemble de serveurs de noms par défaut à utiliser sur tous leurs domaines.

Comprenez le concept des jeux d'enregistrements. Les éléments individuels de chaque zone hébergée sont appelés jeux d'enregistrements. Ceux-ci correspondent aux enregistrements DNS, mais avec quelques paramètres supplémentaires.

• Chaque jeu d'enregistrements a un ensemble d'adresses que le sous-domaine peut résoudre. Ces adresses peuvent être des adresses IP (qui peuvent ou non être des instances EC2) ou des noms DNS (comme pour un ELB EC2, un compartiment S3 configuré en tant que site statique ou une distribution CloudFront). Notez que lorsque nous utilisons des noms DNS, le nom DNS peut à son tour se résoudre en une ou plusieurs adresses IP. Par exemple, un ELB EC2 se résoudra généralement en plusieurs adresses IP, le nombre d'adresses IP dépendant du nombre de zones de disponibilité dans lesquelles il est opérationnel, ainsi que de la charge de trafic qu'il gère.
• Chaque jeu d'enregistrements est associé au domaine ou à un sous-domaine du domaine associé à la zone hébergée et joue un rôle dans la résolution de ce domaine. En général, il est possible (et crucial) d'avoir plusieurs jeux d'enregistrements (dont chacun peut à son tour avoir plusieurs enregistrements) pour un seul sous-domaine.
• Chaque jeu d'enregistrements a un type d'enregistrement. Les types d'enregistrements sont un sous-ensemble des types d'enregistrements DNS. Les types d'enregistrement les plus importants pour les cas d'utilisation courants sont les enregistrements d'adresse (enregistrements A) et les enregistrements de nom canonique (enregistrements CNAME). Le CNAME a du sens lorsque vous réécrivez simplement un sous-domaine vers un autre. Le disque A est beaucoup plus polyvalent.
• Lorsque vous utilisez un enregistrement qui pointe directement vers l'adresse IP d'une instance EC2, assurez-vous que l'adresse IP est une adresse IP élastique afin qu'elle survit à la fin de l'instance et puisse être rattachée à une nouvelle instance.
• Lors de l'utilisation d'un enregistrement A ou CNAME pour un Elastic Load Balancer, une distribution CloudFront, un compartiment S3 configuré en tant que site statique ou un enregistrement Route 53, il est possible de le définir en tant qu'alias. Un enregistrement d'alias remappe simplement le sous-domaine au nom DNS auquel il est aliasé, et par conséquent, les modifications apportées à ce dernier sont automatiquement sélectionnées par le premier. Cela permet aux enregistrements A de bénéficier de certains des avantages des enregistrements CNAME tout en permettant la création de plusieurs enregistrements par sous-domaine. Il permet également une intégration plus approfondie avec les ressources sous-jacentes, y compris une évaluation directe de l'état de santé de la cible sans mettre en place de vérifications d'état distinctes. L'idée de l'enregistrement d'alias a été introduite par DNSimple (non affilié à Amazon Route 53). La mise en œuvre d'Amazon diffère quelque peu de celle de DNSimple. Amazon propose un guide sur l'utilisation des jeux d'enregistrements de ressources alias et non-alias.
• Dans le cas de plusieurs jeux d'enregistrements pour un sous-domaine donné, l'image complète de la résolution des recherches DNS pour ce sous-domaine dépend de tous les jeux d'enregistrements et de leur interaction.

Comprendre les notions d'intégrité de l'itinéraire 53. Certains types d'ensembles d'enregistrements prennent en charge les vérifications de l'état et l'évaluation de l'état de la cible.

• Pour tout type d'enregistrement (alias ou non, et quel que soit le type d'enregistrement) avec une stratégie autre que "Simple" (les types d'enregistrement sont abordés dans la partie suivante), vous pouvez associer une vérification de l'état. Cela peut envoyer un ping à un point de terminaison spécifique (avec un port que vous pouvez spécifier) à l'aide du protocole HTTP (les autres protocoles ne sont pas pris en charge) et rechercher une chaîne de recherche spécifique dans la réponse. L'intervalle de demande peut être défini sur 10 secondes ou 30 secondes. Le délai d'expiration de la réponse, la longueur du segment initial de réponse qui sera comparé à la chaîne de recherche et la fraction des vérifications de l'état qui doivent passer pour que le point de terminaison soit considéré comme sain sont tous contrôlés par Amazon et non configurables par l'utilisateur.
• L'option «Évaluer la santé de la cible» est disponible pour les enregistrements d'alias (enregistrements CNAME ou A) quelle que soit la stratégie. Étant donné que cette option n'est proposée que pour des ressources Amazon spécifiques, elle peut bénéficier d'une intégration profonde avec les ressources sous-jacentes. Par exemple, dans le cas particulier des enregistrements Alias (enregistrements CNAME ou A) qui pointent vers les ELB Amazon EC2, l'évaluation de l'intégrité de la cible réussit si et seulement si l'ELB a au moins une instance qui est enregistrée et en service. Il s'agit d'une intégration profonde spéciale dans les coulisses entre les deux services AWS (Route 53 et ELB).

Comprenez la politique de routage «simple». La politique de routage la plus simple est une politique de routage «simple». C'est pour les cas où il n'y a qu'un seul jeu d'enregistrements associé au sous-domaine. Une politique de routage simple peut inclure plusieurs adresses IP ou DNS, et résoudra à chacune d'elles une fraction égale du temps. Plus précisément, il suit une stratégie de tournoi à la ronde. Les politiques de routage simples se marient bien avec les enregistrements CNAME. Comme toujours, utilisez un enregistrement Alias si vous pointez vers une adresse DNS EC2 telle qu'un Elastic Load Balancer, et évaluez l'intégrité de la cible.

Comprenez la politique de routage «pondérée». Une autre politique de routage couramment utilisée est une politique de routage «pondérée». Ici, chaque jeu d'enregistrements associé à un sous-domaine reçoit un poids. Dans le jeu d'enregistrements, toutes les adresses IP individuelles sont résolues à l'aide d'une stratégie de tourniquet. Dans les jeux d'enregistrements, la probabilité qu'un jeu d'enregistrements donné soit utilisé est le rapport entre le poids du jeu d'enregistrements et la somme des poids de tous les jeux d'enregistrements pour le sous-domaine. Par exemple, s'il existe des ensembles d'enregistrements de poids 3, 2, 2 et 1 respectivement pour un sous-domaine, ils sont sélectionnés avec des probabilités de 0,38, 0,25, 0,25 et 0,13 respectivement.

• Les politiques de routage pondéré n'ont de sens que dans le cas de plusieurs jeux d'enregistrements, tous utilisant la politique de routage pondéré.
• En règle générale, pour une politique de routage pondéré, nous ne spécifions qu'une seule adresse IP ou enregistrement DNS A par jeu d'enregistrements, et créons donc autant de jeux d'enregistrements que le nombre d'adresses IP ou d'enregistrements DNS A.
• Notez que le poids numérique associé à un jeu d'enregistrements dans une politique d'acheminement pondéré ne donne pas une image complète de la probabilité que ce jeu d'enregistrements soit utilisé: nous devons également connaître le dénominateur (la somme des poids sur tous les jeux d'enregistrements). En particulier, si nous ajoutons un nouvel ensemble d'enregistrements, la probabilité de résolution de chacun des autres ensembles d'enregistrements diminue dans la même proportion. De même, si le poids de l'un des jeux d'enregistrements est modifié, cela affecte la probabilité pour tous les autres jeux d'enregistrements.

Comprenez la politique de routage «latence». Le routage basé sur la latence (LBR) est l'une des politiques de routage les plus sophistiquées. Chaque enregistrement de latence spécifie une région Amazon Web Services.

• Le routeur basé sur la latence, lorsqu'il est invité à résoudre le sous-domaine, examine son tableau périodiquement actualisé de la latence entre les zones suivantes: son emplacement périphérique le plus proche de l'adresse IP effectuant la recherche et la région Amazon Web Services spécifiée dans le jeu d'enregistrements.
• Notez qu'il n'est pas logique que les enregistrements du jeu d'enregistrements se trouvent dans la région AWS spécifiée pour le routage basé sur la latence. En fait, vos enregistrements ne se trouvent peut-être pas du tout sur l'infrastructure AWS! S'ils se trouvent sur l'infrastructure AWS, il est logique d'utiliser la région AWS dans laquelle ils se trouvent. Sinon, il est logique d'utiliser la région AWS la plus proche, pour offrir le meilleur proxy pour la latence de ces enregistrements.
• Comme pour les enregistrements pondérés, les ensembles d'enregistrements basés sur la latence n'ont de sens que lorsqu'il y en a plusieurs. Dans ce cas, la latence pour chaque jeu d'enregistrements est calculée comme expliqué ci-dessus (par une table de recherche de latence entre l'emplacement périphérique le plus proche du demandeur et la région AWS spécifiée dans le jeu d'enregistrements). Ensuite, le jeu d'enregistrements avec la latence signalée la plus faible est renvoyé.
• Notez, en particulier, que cette estimation de la latence peut être très différente de la latence réelle des requêtes, pour deux raisons: elle utilise la latence des emplacements périphériques vers la région AWS plutôt que du client réel vers le serveur réel, et deuxièmement, il ignore le temps de traitement sur les serveurs lui-même, qui peut varier d'une région à l'autre.
• En particulier, contrairement à l'équilibreur de charge lessconns utilisé par les ELB d'Amazon, qui redistribue de manière adaptative le trafic en fonction des différences de latence, Route 53 ne prend en compte aucune information sur la latence réelle des requêtes. Nous pourrions idéalement imaginer que si une région est plus lente qu'une autre, l'autre région captera une plus grande part du trafic provenant de lieux géographiques quelque part au milieu des deux. Le routage basé sur la latence ne le fait pas.
• L'algorithme de routage basé sur la latence est connu pour échouer, en ce sens qu'il achemine parfois le trafic vers un emplacement incorrect. Par conséquent, si la latence est vraiment importante pour vous et que vous avez un petit nombre de clients qui utilisent fortement votre API, il est préférable de leur donner des sous-domaines qui se résolvent directement à des régions particulières plutôt que d'utiliser LBR en espérant qu'ils seront acheminés correctement.

Comprenez la politique de routage «géolocalisation». Ceci est similaire au routage basé sur la latence, mais permet une spécification explicite des emplacements géographiques qui doivent être mappés à quels ensembles d'enregistrements.

Comprendre les politiques de routage de basculement. AWS Route 53 offre à la fois un basculement actif et passif basé sur des vérifications de l'état et une évaluation directe de l'état de la cible, qui fonctionnent tous sur le principe du travail constant pour éviter les échecs en cascade.

• Si vous associez des vérifications de l'état à vos jeux d'enregistrements Route 53, un jeu d'enregistrements particulier est mis hors service après l'échec de trois vérifications de l'état successives (le nombre d'échecs peut être configurable). De même, si vous évaluez l'état de santé de la cible de l'ELB, un jeu d'enregistrements est retiré de la commission une fois que la cible s'avère malsaine. Les jeux d'enregistrements reviennent en ligne une fois que la vérification de l'état ou l'état de santé cible est revenu à la normale. Le temps maximum pour que l'effet soit global est de 150 secondes: 3 contrôles échoués de 30 secondes, plus TTL de 60 secondes (notez que le TTL est configurable et si vous le définissez sur plus long, il faudra plus de temps pour que le changement se propage).
• Pour les politiques de routage pondérées, cela signifie que les pondérations sur les jeux d'enregistrements toujours sains augmentent proportionnellement.
• Pour les politiques de routage basées sur la latence, cela signifie que si un jeu d'enregistrements tombe complètement en panne, tout le trafic qui y aurait été acheminé est à la place acheminé vers la région de latence la plus basse suivante pour cette partie particulière du trafic. Par conséquent, la charge pour les autres régions n'augmentera pas dans la même proportion, mais augmentera plutôt en fonction de leur proximité avec le trafic qui était desservi par la région actuellement en panne. Cela peut conduire à une défaillance en cascade. Par exemple, disons que vous avez trois régions: us-west-1, us-east-1 et eu-west-1, avec un jeu d'enregistrements pour chacune, et que vous avez configuré la capacité pour gérer les charges de trafic typiques. pour chaque région. Maintenant, supposons que us-east-1 tombe en panne. Dans ce cas, presque tout le trafic pour us-east-1 ira vers us-west-1, la région la plus proche pour la plupart du trafic qui irait vers us-east-1. Cela pourrait être une augmentation significative du trafic pour us-west-1, et l'augmentation de la charge pourrait entraîner l'effondrement de la région. Désormais, tout le trafic mondial atteint eu-west-1, ce qui pourrait entraîner l'effondrement de cette région. Le résultat est que le basculement passif peut en fait provoquer un effondrement global sans une conception soignée. Le problème est plus aigu qu'avec les politiques de routage pondéré en raison de la façon dont une grande partie du trafic redirigé va vers une région.
• Il est également possible d'avoir des jeux d'enregistrements explicitement désignés comme basculement. Ces jeux d'enregistrements ne sont utilisés que si tous les autres jeux d'enregistrements sont hors service. Nous pouvons les utiliser pour servir des sauvegardes statiques.

Conception en gardant à l'esprit la difficulté de changer. Il peut être difficile de changer de type d'enregistrement, d'alias et de stratégies de routage dans la console Route 53.

• Par exemple, il existe des contraintes sur les ensembles d'enregistrements pour un sous-domaine particulier: nous ne pouvons pas mélanger des enregistrements pondérés et basés sur la latence, et nous ne pouvons pas avoir plus d'un enregistrement simple.
• Une façon de sortir de ce défi est de commencer par une arborescence d'enregistrements, permettant la création d'une nouvelle branche de l'arbre. Amazon propose des guides sur la configuration DNS complexe.
• L'utilisation de l'API Route 53 donne plus de flexibilité pour apporter des modifications que pour utiliser la console, car des modifications plus complexes peuvent être apportées plus rapidement, ce qui minimise les temps d'arrêt lors de modifications délicates entre les configurations.

Comprenez que l'itinéraire 53 est un élément clé d'une configuration multirégionale.

• Investissez au moins quelques heures pour vous assurer que vos politiques Route 53 sont définies de manière raisonnable.
• Étudiez l'utilisation des politiques de trafic et du flux de trafic qui vous permettent de stocker des configurations complexes. À long terme, cliquer dans la console pour modifier les politiques n'est pas une bonne idée pour un ingrédient clé de votre disponibilité.
• Enquêtez sur l'intégration des mises à jour de l'API Route 53 dans vos scripts de déploiement (tels que les scripts Ansible ou Chef).

Concevez pour éviter d'être touché par des échecs de routage basés sur la latence. Comme mentionné précédemment, si la latence est particulièrement importante pour un client, ou si pour une autre raison vous souhaitez qu'un client particulier n'atteigne votre point de terminaison API que dans une région particulière, il est préférable de lui attribuer un sous-domaine pour lequel vous n'avez configuré que des enregistrements. pour cette région, plutôt que de compter sur un routage basé sur la latence ou la géolocalisation. Ceux-ci n'échouent généralement pas, mais quand ils le font, vous êtes impuissant.

Envisagez des approches de repli créatives alimentées par la route 53.

• Un aspect souvent sous-estimé du routage basé sur la latence est que vous pouvez l'utiliser pour acheminer le trafic vers une région qui n'est pas la région la plus proche.
• Une façon dont vous pouvez l'utiliser est la suivante. Supposons que vous ayez deux chances d'interroger le serveur principal. La plupart du temps, le serveur répond correctement à la première occasion. Cependant, en cas d'échec, cela peut être dû à des problèmes spécifiques à la région (tels que les serveurs de la région surchargés ou des problèmes de connectivité avec la région). Par conséquent, vous souhaitez que la première requête se trouve dans la région géographiquement la plus proche, mais la deuxième requête à une autre région qui n'est pas géographiquement la plus proche mais (espérons-le) la seconde la plus proche.
• Vous pouvez le faire en ayant deux sous-domaines, un pour votre premier choix et un pour votre deuxième choix. Les enregistrements Route 53 pour le premier sous-domaine utilisent simplement le routage basé sur la latence tel que défini par défaut (c'est-à-dire que vous créez un jeu d'enregistrements pour ce sous-domaine et chaque région active, en acheminant le trafic le plus proche de cette région vers les serveurs de cette région). Les enregistrements Route 53 pour le deuxième sous-domaine utilisent un routage basé sur la latence, mais envoient le trafic le plus proche d'une région vers une autre région. Cela garantit que vos deux chances sont utilisées contre des régions différentes.
• Notez que cela ne remplace pas les vérifications de l'état et les évaluations de l'état de santé des cibles, mais il traite les cas où une région est quelque peu surchargée mais reste en grande partie saine. Cela évite également le problème de l'échec en cascade, où une région avec un taux d'échec élevé peut finir par recevoir du trafic supplémentaire en raison de secondes tentatives.

Familiarisez-vous avec les commandes shell pour un meilleur débogage.

• whois peut rechercher des informations d'enregistrement faisant autorité pour les domaines.
• nslookup peut être utilisé pour obtenir des informations sur les serveurs de noms.
• dig (la commande la plus utile pour le débogage de Route 53) peut trouver les adresses IP associées à un sous-domaine donné, et vous pouvez vérifier que les résultats renvoyés sont conformes à votre politique de routage. Il imprime également le TTL restant. Lorsque vous émettez la première commande, cela devrait être votre TTL complet. Les appels suivants dans le TTL doivent afficher le TTL restant. Par exemple, si votre TTL est de 60 secondes, l'exécution de dig après 15 secondes devrait afficher une TTL de 45 secondes. Si le nom DNS A a des enregistrements d'alias basés sur la latence pointant vers le nom DNS B et le nom DNS C, vous pouvez creuser les trois noms, puis voir si les adresses IP résolues par A correspondent aux adresses IP auxquelles B et C résolvent. Vous pouvez également spécifier une option + trace pour creuser pour imprimer la trace.
• traceroute est également utile pour obtenir des informations plus claires sur la façon dont la résolution s'est produite.
• ping peut être utilisé pour interroger l'adresse DNS et obtenir des estimations du temps d'aller-retour.
• curl ou wget peuvent être utilisés pour faire une requête HTTP et obtenir une réponse.
• Vous pouvez exécuter ces commandes shell à partir de votre propre machine ou en vous connectant à des serveurs distants situés à divers endroits.