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.
dig +trace, mais je ne suis pas sûr de ce que l'on entend par niveaux. Cela pourrait être une question pour Server Fault.