Votre navigateur ne le fait pas. Votre navigateur utilisera les appels système standard pour résoudre les noms d'hôte (généralement, je crois, getaddrinfo() ), et ceux-ci examineront à leur tour généralement le contenu de /etc/resolv.conf pour trouver les serveurs de noms de résolution configurés et les interroger. À leur tour, ils transmettront la requête du système d'exploitation de votre bureau aux serveurs en amont (en mettant en cache toute réponse) ou effectueront eux-mêmes une résolution récursive. Notez que la plupart des étapes de la chaîne ci-dessus sont configurables, donc ce que votre navigateur fait en fait sera déterminé localement ; mais le scénario ci-dessus est typique.
Ce sont les serveurs de noms à résolution récursive de cette chaîne (qu'il s'agisse de vos serveurs de noms faisant autorité configurés localement ou de certains serveurs de FAI) qui doivent savoir comment trouver les serveurs racine, et ils le font via un fichier de zone préconfiguré pour . (qui est généralement mis à jour périodiquement en interrogeant un serveur de noms racine disponible).
Modifier :Ce n'est pas le cas. Cela dépendra de l'implémentation, mais dans mon cas (BIND), il en choisit juste un et l'interroge. Tant qu'il obtient une réponse à temps, il revient à partir de là. Qu'est-ce qui vous fait penser qu'une opération de télémétrie est en cours ?
Dans la résolution de noms DNS, comment les navigateurs déterminent-ils les serveurs DNS disponibles les plus proches parmi de nombreux serveurs DNS ?
Comme les autres réponses l'indiquent, votre navigateur ou un autre programme client ne fait pas cette sélection. Un programme client demande la résolution du service de noms en faisant des appels à une bibliothèque appelée le résolveur.
Le résolveur détermine les serveurs qu'il doit contacter pour poser une requête. Cela dépend de l'implémentation du résolveur mais généralement il consulte, dans l'ordre, une liste de résolveurs récursifs avec lesquels il a été configuré (soit par configuration statique, soit en les recevant via un mécanisme tel que DHCP.)
En résumé, votre programme (au niveau de l'utilisateur) demande au résolveur de résoudre le nom et le résolveur demande les serveurs de noms qui lui ont été fournis via un mécanisme de configuration.
Je sais qu'il existe 13 serveurs racine, mais comment le serveur DNS de mon FAI sait-il quel serveur DNS racine contacter ?
Cela dépend également de l'implémentation. Je vais décrire comment cela fonctionne avec BIND, puisque
- BIND est un serveur de noms très populaire et il y a de fortes chances que votre FAI l'utilise, et
- Même si votre FAI n'utilise pas BIND, certaines alternatives utilisent un mécanisme similaire pour la sélection du serveur de noms à partir d'un jeu d'enregistrements de ressources NS.
Pour commencer, parlons d'abord de la façon dont un serveur de noms récurrent sait même quels serveurs de noms choisir pour parler à un domaine spécifique. Pour chaque domaine accessible à partir du niveau racine ("".") du serveur de noms, les administrateurs gérant ce domaine publient, dans le domaine parent contenant, un ensemble d'enregistrements de ressources de type NS (c'est-à-dire un serveur de noms) à déléguer publiquement aux serveurs de noms nommé dans l'enregistrement de ressource définit la responsabilité de la résolution des requêtes liées à ce domaine.
L'une des beautés de ce système est qu'il permet une délégation hiérarchique distribuée pour le système de noms de domaine et le seul domaine pour lequel un serveur récursif exige a priori knowledge est le niveau racine, que le serveur est configuré pour connaître. Auparavant, il était plus courant de spécifier le RRset NS pour la racine via un fichier "hints" que BIND chargeait au démarrage, mais depuis un certain temps, les adresses IP utilisées par les serveurs root ont été prédéfinies dans BIND. [Digression :vous pouvez toujours remplacer les éléments intégrés en spécifiant une zone d'indication de racine, et en fait l'adresse de d.root-servers.net a récemment changé et le nouvel emplacement ne sera pas reflété dans la liste intégrée jusqu'à ce que nouveau des versions de BIND sont construites et distribuées qui incluent les nouvelles informations. À l'heure actuelle, les versions contenant la nouvelle adresse IP des serveurs racine D sont en version bêta.]
Quoi qu'il en soit, la clé à retenir ici est que chaque domaine est associé à un RRset d'enregistrement NS contenant les serveurs de noms annoncés publiquement pour ce domaine. Vous devriez essayer d'en regarder quelques-uns vous-même. Regardons la racine :
$ dig . ns +edns=0 @f.root-servers.net.
Je vais juste couper la section de réponse, qui contiendra le NS RRset renvoyé dans un ordre imprévisible (je passe un peu de temps ici -- l'ordre est généralement déterminé par la configuration du serveur de noms auquel je parle . Différentes racines peuvent répondre avec des commandes différentes, mais les articles commandés doivent être les mêmes.)
;; ANSWER SECTION:
. 518400 IN NS h.root-servers.net.
. 518400 IN NS j.root-servers.net.
. 518400 IN NS c.root-servers.net.
. 518400 IN NS l.root-servers.net.
. 518400 IN NS e.root-servers.net.
. 518400 IN NS a.root-servers.net.
. 518400 IN NS f.root-servers.net.
. 518400 IN NS k.root-servers.net.
. 518400 IN NS i.root-servers.net.
. 518400 IN NS d.root-servers.net.
. 518400 IN NS m.root-servers.net.
. 518400 IN NS b.root-servers.net.
. 518400 IN NS g.root-servers.net.
Ce sont tous les serveurs de noms pour le domaine racine ("".") et nous pouvons poser à n'importe lequel d'entre eux des questions sur le domaine racine. Si nous leur posons une question sur quelque chose qui n'est pas dans le domaine racine, nous recevrons soit une erreur, soit, plus probablement, une référence à un autre ensemble de serveurs de noms (par exemple, "example.com ? Je ne réponds pas aux questions sur example.com. . Essayez de demander aux serveurs de noms de domaine .com -- ils sont là-bas...")
Comment, alors, BIND sait-il quel serveur de noms du NS RRset lui donnera la réponse la plus rapide ?
La réponse est :au départ, ce n'est pas le cas. Mais sous son comportement par défaut, il apprend au fil du temps et s'installe habituellement demander au serveur avec le temps aller-retour le plus court.
Temps aller-retour et sélection des serveurs de noms candidats BIND s'appuie sur les temps d'aller-retour (RTT) vers les serveurs de noms dans un RRset pour choisir quel serveur de noms doit recevoir ses requêtes. La première fois qu'un RRset NS pour un domaine est ajouté au cache, tous les enregistrements de l'ensemble se voient attribuer un petit temps d'aller-retour aléatoire, de l'ordre de quelques millisecondes. Après cet amorçage initial, lorsqu'une requête doit être dirigé vers les serveurs de noms délégués pour un domaine donné, BIND vérifie son cache et (espérons-le) trouve le RRset. Il choisit le serveur avec le temps RTT le plus bas de l'ensemble et fait sa requête. Et lorsque la requête est terminée, BIND met à jour les RTT pour le NS RRset comme suit :
- le RTT du serveur qui vient d'être interrogé est défini sur son temps d'aller-retour réel.
- Tous les autres serveurs du RRset ont leurs RTT réduits d'une petite fraction (~3-4 %, je pense..)
Voyons comment cela fonctionne en parcourant un exemple. La première fois que mon résolveur récursif rencontre le domaine example.com, il charge le NS RRset for example.com dans son cache. Disons que les administrateurs de example.com ont annoncé trois serveurs de noms pour example.com donc le RRset NS ressemble à :
example.com NS servera.example.com
example.com NS serverb.example.com
example.com NS serverc.example.com
Supposons également, pour les besoins de cet exemple, qu'il faut à votre résolveur le temps suivant pour recevoir une réponse de chacun des serveurs de cet ensemble :
servera -- 30 ms
serverb -- 45 ms
serverc -- 50 ms
Maintenant, la première fois que le RRset NS example.com est chargé, les poids RTT sont amorcés avec de petites valeurs aléatoires. Ainsi, avant que nous ayons demandé quoi que ce soit à un serveur de noms example.com, la table RTT pourrait ressembler à ceci :
servera -- 8 ms
serverb -- 9 ms
serverc -- 7 ms
La première fois que nous interrogeons example.com, nous allons alors aller sur serverc et poser notre question. Serverc prend 50 ms pour répondre, donc une fois notre requête terminée, nous mettons à jour notre table RTT pour qu'elle affiche maintenant :
servera -- 7 ms // reduced by a small fraction
serverb -- 8 ms // reduced by a small fraction
serverc -- 50 ms // updated to reflect the actual round trip time.
La prochaine fois, nous allons évidemment choisir servera, car il a maintenant le temps aller-retour le plus bas. Après seulement quelques requêtes sur le domaine example.com, nous devrions avoir une idée assez correcte du serveur de noms qui nous donne la réponse la plus rapide et nous préférerons ensuite ce serveur le plus du temps.
Pourquoi le plus du temps et pas tous du temps? Et que se passe-t-il avec le morceau que j'ai mentionné plus tôt à propos de "Tous les autres serveurs du RRset ont leurs RTT réduits d'une petite fraction" ? Eh bien, il s'avère que même si nous voulons préférer le serveur le plus rapide, nous ne voulons pas radier les autres serveurs de façon permanente. Peut-être que le serveur c est le serveur le plus rapide presque tout le temps, mais au moment où nous avons défini son RTT pour la première fois, il était anormalement occupé. Peut-être qu'un serveur était temporairement hors service, ce qui a entraîné un RTT incroyablement élevé (après l'expiration de notre tentative d'interrogation), mais nous voulons recommencer à le demander après son retour en service. En ajustant les autres valeurs de serveur à la baisse à chaque fois, tôt ou tard, elles vont descendre plus bas que le RTT moyen du serveur que nous préférons. Lorsque cela se produit, nous lançons une requête dans leur direction et si le temps est meilleur, tant mieux. Sinon, nous réinitialisons son RTT et il revient au bas de notre liste de priorités jusqu'à ce qu'il revienne au premier plan. La grande majorité de nos requêtes iront au serveur ou aux serveurs les plus rapides de l'ensemble, mais les valeurs aberrantes sont essayées périodiquement pour s'assurer que si les conditions ont changé, la table est mise à jour pour refléter cela et le meilleur serveur est toujours sélectionné en moyenne.
Les 13 serveurs de noms racine ne sont pas réellement 13 serveurs. Chacun est un cluster distribué de serveurs sur divers sites à travers le monde, et ils sont accessibles via un routage IP standard, comme n'importe quel autre serveur.
Quant à qui root nameserver que le serveur DNS du FAI choisit de contacter, cela dépend probablement des détails de son résolveur DNS. Peut-être que c'est complètement aléatoire, peut-être que c'est pondéré, mais je ne pourrais pas vous le dire.
Edit :si vous vouliez dire, comment le FAI trouve-t-il n'importe lequel des 13 serveurs de noms, il existe une liste publique d'entre eux et leurs adresses IP correspondantes que possède pratiquement chaque ordinateur. À partir de là, il suffit d'en choisir un et de laisser les routeurs Internet faire le reste.