Qu’est-ce que dig +trace ?;

Dig +trace suit entièrement la chaîne de délégation pour le domaine en question. Il peut aller des serveurs de noms racine aux serveurs de domaine de premier niveau (TLD) et aux serveurs de noms faisant autorité. Dig +trace aide les équipes à résoudre les problèmes de résolution DNS.

Les problèmes les plus évidents sont l’impossibilité de se connecter à un domaine ou à un sous-domaine donné, comme le montre l’écran de notification d’échec. Un autre type de problème de résolution DNS est la latence, qui peut allonger les temps de requête au-delà de la patience humaine normale.

Le temps moyen de recherche DNS est mesuré en millisecondes (MSEC) et se situe généralement entre 20 MSEC et 120 MSEC. Les efforts d’optimisation visent à réduire davantage ces temps de requête.

Lors d’une commande dig, votre serveur DNS, agissant en tant que résolveur de votre fournisseur d’accès à Internet (FAI), émet une requête récursive et vérifie ses caches locaux à la recherche d’un enregistrement DNS récent et non expiré. Mais c’est ce qui se passe dans une situation idéale, lorsque tout se déroule comme prévu. 

Les administrateurs se tournent vers dig +trace lorsqu’ils doivent passer sous le capot. En général, vous devez contourner le processus de requête habituel parce que quelque chose ne va pas. Une partie de la chaîne de routage ne fonctionne pas correctement. Les administrateurs doivent donc être capables de disséquer et d’étudier certains éléments de cette chaîne et ses différents liens pour découvrir ce qui ne fonctionne pas correctement.

Lorsque les équipes utilisent dig +trace, elles ne tiennent pas compte de ce qui a déjà été mis en cache. Elles peuvent donc exécuter une nouvelle requête itérative sans être redirigées vers des voies anciennes et obsolètes.

La commande dig +trace est utile pour le dépannage car elle permet de voir où la résolution DNS échoue. Le problème peut se situer au niveau de la racine, du TLD ou du niveau faisant autorité. Il peut également vérifier si les enregistrements du serveur de noms de votre domaine sont corrects et vérifier la propagation DNS après modifications.

Le processus dig +trace se résume en fait à quatre étapes.

Si l’utilisateur a précédemment saisi ce nom de domaine et que l’ordinateur a mis en cache son adresse IP, l'invite de commande (CMD) récupère instantanément l’adresse IP requise. Le système accède au contenu demandé et le télécharge, puis le processus de requête s’arrête là. 

Cependant, si le nom de domaine est nouveau et inconnu de cet appareil, les autres étapes sont exécutées.

La commande dig recherche les serveurs de noms racines pour les enregistrements de serveur de noms (NS) associés au domaine de premier niveau (TLD) du domaine cible à explorer.

La commande dig examine les serveurs de noms TLD pour découvrir les serveurs de noms faisant autorité pour un domaine particulier.

La commande dig interroge ensuite les serveurs de noms faisant autorité pour accéder aux enregistrements DNS demandés. Par exemple, l’« enregistrement A » est un enregistrement de ressource qui associe un nom de domaine adapté aux humains à une adresse IPv4 ou IPv6. Pendant ce temps, les enregistrements Start of Authority (SOA) contiennent les données administratives nécessaires à une zone DNS.

La réponse DNS donnée comprend la « section réponse », c’est-à-dire des enregistrements de ressources qui peuvent répondre avec succès à la requête d’origine (également appelée « section question »).

En outre, la réponse peut également comporter une section d’autorité qui répertorie les serveurs de noms faisant autorité et éventuellement une « section supplémentaire » contenant des informations supplémentaires. Les administrateurs peuvent sélectionner exactement les types d’enregistrements qu’ils souhaitent, qu’il s’agisse de serveurs de messagerie (enregistrements MX) ou de serveurs de noms (enregistrements NS).

À chaque étape de l’enquête, les administrateurs reçoivent des messages de sortie les informant de l’état d’avancement de chaque phase et indiquant si la progression se poursuit comme prévu.

Par exemple, l’administrateur reçoit un message « NOERROR » pour l’informer qu’il n’y a pas eu d’incident à ce stade du test. (Remarque : ce message n’indique pas un succès ou un échec opérationnel global et ne doit pas être mal interprété. Bien qu’utile, il est limité dans les informations qu’il transmet.)

Il est intéressant d’observer que l’infrastructure DNS contribue à prendre en charge la hiérarchie DNS et utilise un système ingénieux de renvois pour faciliter le processus de recherche. De cette façon, si un serveur ne peut pas mener à bien la requête, il guide essentiellement la requête vers un autre serveur qui facilite sa progression et étend son parcours. 

Le système de noms de domaine utilisé par Internet est composé de différents serveurs racines opérant à différents niveaux. Les 13 serveurs de noms racine logiques qui travaillent au niveau le plus élevé sont d’une importance capitale. Ils portent le nom des 13 premières lettres de l’alphabet.

Chacun de ces 13 serveurs racines logiques ne fait pas référence à un ordinateur ou à un système d’exploitation unique, mais représente une autorité désignée qui régit un treizième de tout le trafic de requêtes DNS Internet. Ainsi, lorsque nous parlons de « Serveur A », nous faisons référence à la désignation Serveur A, qui peut couvrir un nombre illimité de serveurs DNS individuels.

Il convient également de noter que les 13 serveurs de noms racine sont délégués à de nombreuses entités, à savoir des entreprises à but lucratif ainsi que des organisations universitaires et militaires. Et s’il est vrai qu’à l’origine, la plupart des serveurs physiques étaient principalement localisés aux États-Unis, cette équation a été rééquilibrée au fil du temps. Aujourd’hui, les serveurs physiques sont situés dans le monde entier.

Voici les groupes qui sont responsables de la gestion des 13 différents serveurs racines (root-servers.net) :

• Serveur A (a.root-servers.net) : Opérateur : VeriSign, Inc., qui propose une infrastructure internet et des services de registre de noms de domaine dans le monde entier.

• Serveur B (b.root-servers.net) : Opérateur : The University of Southern California (ISI). L’Institut des sciences de l’information de l’USC étudie les technologies de pointe en matière d’informatique et de communication.

• Serveur C (c.root-servers.net) : Opérateur : Cogent Communications, un FAI international qui gère un réseau de fibre optique important et propose des services de colocation.

• Serveur D (d.root-servers.net) : Opérateur : L’Université du Maryland et géré par son groupe Advanced Cyberinfrastructure and Internet Global Services (ACIGS).

• Serveur E (e.root-servers.net) : Opérateur : NASA, plus précisément la ligne de service Network and Telecommunication Services (NaTS) de l’agence spatiale américaine. 

• Serveur F (f.root-servers.net) : Opérateur : Internet Systems Consortium, Inc., une organisation à but non lucratif qui soutient Internet en proposant divers logiciels et protocoles. 

• Serveur G (g.root-servers.net) : Opérateur : Centre d’information réseau (NIC) du Département de la Défense des États-Unis, également responsable de la gestion du plan d’adresses IPv6 du DoD.

• Serveur H (h.root-servers.net) : Opérateur : Laboratoire de recherche de l’armée américaine (ARL), anciennement connu sous le nom de Laboratoire de recherche balistique (BRL). 

• Serveur I (i.root-servers.net) : Opérateur : Netnod, une entreprise suédoise d’infrastructure internet à but non lucratif principalement connue pour ses services d’interconnexion dans les régions nordiques. 

• Serveur J (j.root-servers.net) : Opérateur : VeriSign, Inc. (voir Serveur A). 

• Serveur K (k.root-servers.net) : Opérateur : Reseaux IP Europeens Network Coordination Centre (RIPE NCC), un registre internet régional (RIR) à but non lucratif consacré à l’Europe, au Moyen-Orient et à l’Asie. 

• Serveur L (l.root-servers.net) : Opérateur : Internet Corporation for Assigned Names and Numbers (ICANN), une organisation à but non lucratif qui a débuté grâce à un contrat du gouvernement américain, mais qui existe désormais en tant qu’entité distincte centrée sur le monde entier.

• Serveur M (m.root-servers.net) : Opérateur : Le projet WIDE, qui signifie Widely Integrated Distributed Environment, ce projet Internet a débuté grâce à une collaboration entre trois universités japonaises.

Le trafic de requêtes est réparti uniformément sur les 13 serveurs, aucun serveur n’en gérant plus qu’un autre. Des facteurs régionaux peuvent influencer les serveurs auxquels les utilisateurs accèdent le plus, mais dans l’ensemble, le trafic est similaire et concerne principalement des demandes d’adresses de fournisseurs d’accès à Internet.

La gestion du trafic des requêtes DNS nécessite 13 entités car des milliers de milliards de requêtes DNS sont générées chaque année. Certaines estimations prévoient que le total dépassera 100 000 milliards, mais ces chiffres ne sont que des suppositions éclairées. C’est un nombre tellement important qu’il est impossible de le calculer.

Un certain nombre de questions indirectement liées doivent également être abordées :

• L’utilisation des Extension Mechanisms for DNS (EDNS) permet d’obtenir encore plus de fonctionnalités du DNS. EDNS est un ensemble d’améliorations apportées aux protocoles DNS. Lorsque les administrateurs rencontrent des messages DNS plus volumineux, EDNS s’adapte pour transporter ces paquets de données surdimensionnés. En plus de prendre en charge des messages plus volumineux, EDNS offre également des options comme EDNS Client Subnet (ECS), qui augmente les niveaux de performance pour les applications souvent affectées par des problèmes de latence. 

• La pseudosection OPT est un type unique d’enregistrement DNS créé par EDNS. Il contient des informations utiles sur les transactions, mais pas de données DNS standard. La pseudosection OPT est incluse dans la section « données supplémentaires » des messages DNS. Il fournit des détails tels que les versions EDNS, les indicateurs et la taille maximale des paquets pour le protocole UDP (User Datagram Protocol), un format de requête couramment utilisé. 

• Les systèmes d’exploitation Linux et certains systèmes de type Unix s’appuient sur le fichier de configuration etc/resolv.conf pour avertir le système d’activer ses routines de résolution afin de trouver des adresses IP pour les noms d’hôte correspondants. Le contenu de ce fichier comprend les adresses IP des serveurs DNS, les listes de domaines à rechercher, les noms de domaine locaux et des options qui vous permettent de déterminer les actions du résolveur. Ces actions peuvent inclure des options globales, qui sont des paramètres que les administrateurs peuvent appliquer unilatéralement. 

• Les systèmes de type Unix, qui n’utilisent pas vraiment le DNS, contiennent souvent une page de manuel (ou « man page »). Cette page sert de documentation et décrit les données définies concernant un fichier de commande, un appel système ou un fichier de configuration particulier. Les pages de manuel fournissent un contexte général sur les fichiers et les outils du système, en se concentrant sur des informations telles que le nom de la commande ou du programme, le synopsis, la description et les options.