Comment fonctionne la résolution de noms DNS, en principe?

En ce moment, je prends un cours en ligne pour l'administrateur système Linux et on m'a posé une question que je ne comprends généralement pas. Je sais comment rechercher un serveur de noms, si j'ai raison, au moins, il utilise la commande dig pour trouver l'adresse dans la commande de section supplémentaire, mais je me suis un peu perdu quand on m'a posé la question suivante.

En supposant que votre serveur de noms configuré ne dispose pas de résultats mis en cache, combien de serveurs de noms votre serveur de noms doit-il interroger pour résoudre maps.google.com? Quelle (s) commande (s) utiliseriez-vous pour trouver tous ces serveurs de noms? Énumérez-en un de chaque niveau et expliquez pourquoi ce niveau est nécessaire.

Je ne veux pas de réponse, je voudrais juste savoir ce qu'on me demande de faire exactement.

En supposant que votre serveur de noms configuré ne dispose pas de résultats mis en cache, combien de serveurs de noms votre serveur de noms doit-il interroger pour résoudre maps.google.com? Quelle (s) commande (s) utiliseriez-vous pour trouver tous ces serveurs de noms? Énumérez-en un de chaque niveau et expliquez pourquoi ce niveau est nécessaire.

Eh bien, choisissons celui-ci à part.

"En supposant que votre serveur de noms configuré n'a pas de résultats mis en cache à sa disposition" - tout d'abord, s'il n'a aucune donnée en cache, il ne peut rien résoudre. Afin d'amorcer le cache du résolveur, vous devez disposer des enregistrements NS et d'adresse (A, AAAA) pour la zone .(racine AKA). Ce sont les serveurs de noms racine, qui se trouvent dans la root-servers.net.zone. Il n'y a rien de magique dans cette zone ou ces serveurs DNS. Cependant, ces données sont souvent fournies «hors bande» au résolveur DNS, précisément pour amorcer le cache du résolveur. Les serveurs de noms faisant uniquement autorité n'ont pas besoin de ces données, mais les serveurs de noms de résolution en ont besoin.

Aussi, "résoudre" quoi? Un RRtype à ce nom? Un ARR? Ou autre chose? Quelle classe ( CH/ Chaosnet, IN/ Internet, ...)? Le processus exact sera différent, mais l'idée générale reste la même.

Si nous pouvons supposer que nous savons comment trouver les serveurs de noms racine, mais rien de plus, et que par «résoudre», nous entendons obtenir le contenu de tous les IN ARR associés au nom, cela devient beaucoup plus pratique.

Pour résoudre un nom DNS, vous divisez essentiellement le nom en étiquettes, puis vous progressez de droite à gauche. N'oubliez pas le .à la fin; vous résoudriez vraiment maps.google.com.plutôt que maps.google.com. Cela nous laisse avec le besoin de résoudre (nous le savons, mais une implémentation de résolveur DNS ne le fera probablement pas):

• .
• com.
• google.com.
• maps.google.com.

Commencez par trouver où demander le contenu de .. C'est facile; nous avons déjà cette information: les noms de serveur racine et les adresses IP . Nous avons donc un serveur de noms racine. Disons que nous décidons d'utiliser 198.41.0.4 ( a.root-servers.net, également 2001: 503: ba3e :: 2: 30) pour continuer la résolution de nom. Dans la pratique, l'une des premières choses effectuées par le résolveur sera probablement d'utiliser les données du serveur racine fournies pour demander à l'un des serveurs de la zone racine une liste précise des serveurs de noms pour la zone racine, garantissant ainsi que si l'un des les noms et adresses IP sont valides et accessibles, ils auront un ensemble complet et complet de données pour la zone racine lorsque la résolution commencera.

Arrêtez une requête DNS pour maps.google.com. IN A198.41.0.4. Il vous dira en réponse "non, je ne vais pas le faire, mais voici quelqu'un qui pourrait savoir"; c'est une référence. Il contient des NSenregistrements pour la zone la plus proche connue du serveur en question, ainsi que tous les enregistrements de colle dont le serveur dispose. Si aucune donnée de collage n'est disponible, vous devez d'abord résoudre cet hôte nommé dans l'enregistrement NS que vous avez choisi, donc créez une résolution de nom distincte pour obtenir l'adresse IP; si des données de collage sont disponibles, vous aurez l'adresse IP d'un serveur de noms qui est au moins "plus proche" de la réponse. Dans ce cas, ce sera l'ensemble des serveurs de la com.zone, et les données de collage sont également fournies.

Répétez le processus en posant com.la même question à l' un des serveurs de noms. Ils ne le savent pas non plus, mais vous orienteront vers les serveurs de noms faisant autorité de Google. À ce stade, dans le cas général, les données de colle seront fournies ou non; rien n'empêche un comdomaine d'avoir des serveurs de noms uniquement nl, par exemple, auquel cas il est peu probable que les données de collage soient disponibles à partir des serveurs gTLD. Les données de colle fournies peuvent également être incomplètes, ou si vous n'avez vraiment pas de chance, elles peuvent même être incorrectes! Vous devez toujours être prêt à engendrer cette résolution de nom distincte que j'ai mentionnée ci-dessus.

Fondamentalement, vous continuez jusqu'à ce que vous obteniez une réponse avec l' aaindicateur (réponse faisant autorité) défini. Cette réponse vous dira ce que vous demandez, ou que le RR que vous avez demandé n'existe pas (non plus NXDOMAIN, ou NOERRORavec des enregistrements de données à réponse zéro). Continuez à chercher des réponses comme SERVFAIL(et reculez d'une étape et essayez un autre serveur si vous en obtenez un; si tous les serveurs nommés reviennent SERVFAIL, échouez au processus de résolution de nom et revenez SERVFAILvous-même au client).

L'alternative à la demande du RRname complet de chaque serveur (ce qui pourrait être considéré comme une mauvaise pratique) consiste à utiliser la liste des étiquettes divisée que nous avons déterminée précédemment, à demander aux serveurs de noms donnés par le serveur plus loin vers la racine des IN NSet IN A/ IN AAAARR pour cette étiquette, et utilisez-les pour faire avancer le processus de résolution de nom. Ce n'est que légèrement différent dans la pratique, et le même processus s'applique toujours.

Vous pouvez simuler l'ensemble de ce processus en utilisant l' +traceoption de l' digutilitaire, qui fait partie de BIND, ou set debugdans nslookup.

Il convient également de se rappeler que certains types de RR (notamment NS, MXet quelques autres; également, ont A6été raisonnablement bien utilisés pendant un certain temps mais ont été déconseillés) peuvent et font référence à d'autres RR. Dans ce cas, vous devrez peut-être générer un autre processus de résolution de noms pour donner une réponse complète et utile à votre client.

Il y a une dnstracercommande (vous devrez peut-être l'installer, au moins sur Debian, c'est aussi le nom du paquet) qui tracera la résolution des noms. Vous pouvez également (comme le souligne Koveras dans un commentaire) utiliser dig.

Voici avec dnstracer. -s .signifie commencer par la racine; -4moyens d'utiliser IPv4 (la v6 est cassée ici ...); -osignifie afficher les adresses IP résolues à la fin (j'ai omis cette partie de la sortie, il y en a beaucoup).

anthony@Zia:~$ dnstracer -s . -4 -o maps.google.com
Tracing to maps.google.com[a] via A.ROOT-SERVERS.NET, maximum of 3 retries
A.ROOT-SERVERS.NET [.] (198.41.0.4) 
 |\___ m.gtld-servers.net [com] (192.55.83.30) 
 |     |\___ ns4.google.com [google.com] (216.239.38.10) Got authoritative answer 
 |     |\___ ns3.google.com [google.com] (216.239.36.10) Got authoritative answer 
 |     |\___ ns1.google.com [google.com] (216.239.32.10) Got authoritative answer 
 |      \___ ns2.google.com [google.com] (216.239.34.10) Got authoritative answer 
⋮

Cette sortie continue, car dnstracer trace tous les chemins (vous pouvez donc voir si, par exemple, certains des serveurs de noms ont une zone obsolète).

Ainsi, vous pouvez voir qu'il faut une requête au serveur de noms racine, puis une aux serveurs gtld (le serveur de la zone .com), la dernière à un serveur de noms Google.

Avec dig, la sortie est beaucoup plus verbeuse (donc je vais faire beaucoup de découpage):

dig -4 maps.google.com. +norecurse +trace
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> maps.google.com. +norecurse +trace
;; global options: +cmd
.                       425379  IN      NS      b.root-servers.net.
⋮
com.                    172800  IN      NS      f.gtld-servers.net.
⋮
google.com.             172800  IN      NS      ns2.google.com.
⋮
maps.google.com.        300     IN      A       74.125.228.70
⋮

digmontre en outre qu'il a effectué une requête pour obtenir la liste actuelle des serveurs de noms racine. C'est quelque chose qu'un serveur DNS fait généralement très rarement. Donc, je ne sais pas si vous le comptez dans votre cas de cache froid.

Vous pouvez bien sûr aussi regarder les requêtes réelles sur le fil avec, par exemple, wireshark.