Module 1 · 1.4
Le voyage d'une requête DNS
Module 1: Qu'est-ce que le DNS ? · Temps de lecture : 8 minutes
Objectif d'apprentissage : après cette leçon, vous saurez expliquer étape par étape comment un résolveur trouve une réponse, et où les réponses sont mémorisées en chemin.
Notions clés : résolveur (récursif), serveur racine, serveur TLD, serveur de noms faisant autorité (authoritative), renvoi (délégation), cache
Deux types de serveurs DNS
Dans la leçon 1.1, vous avez vu que le DNS est réparti : personne ne sait tout. Comment votre navigateur obtient-il alors l'adresse de www.example.com ? Pour cela, deux types de serveurs collaborent :
- Les serveurs de noms faisant autorité (en anglais authoritative) connaissent la réponse pour leur propre portion. Les serveurs de noms de
example.comconnaissent les enregistrements deexample.com. Ils ne font aucune recherche pour les autres. - Les résolveurs (aussi appelés résolveurs récursifs) cherchent la réponse pour vous. Ils interrogent d'autres serveurs jusqu'à l'obtenir. Votre fournisseur d'accès internet dispose d'un résolveur, et il existe aussi des résolveurs publics comme ceux de Quad9, Cloudflare ou Google.
Votre ordinateur lui-même ne cherche presque rien. Il possède un petit stub resolver qui transmet la question au résolveur de votre réseau et reçoit la réponse en retour.
Le voyage, étape par étape
Imaginons que le résolveur n'a encore rien mémorisé et que vous demandez l'enregistrement A de www.example.com.
- Votre ordinateur interroge le résolveur : « Quel est l'enregistrement A de www.example.com ? »
- Le résolveur interroge un serveur racine. Chaque résolveur a une liste intégrée des adresses des serveurs racines. Le serveur racine ne sait rien de
example.com, mais il sait qui gère.com. Il répond par un renvoi : « Pour cela, adressez-vous aux serveurs de noms de com : a.gtld-servers.net, b.gtld-servers.net, etc. » - Le résolveur interroge un serveur de noms de .com. Celui-ci ne connaît pas non plus l'adresse IP de
www.example.com, mais il sait quels serveurs de noms gèrentexample.com. Encore un renvoi : « Demandez à ns1.hosting.example ou ns2.hosting.example. » - Le résolveur interroge un serveur de noms de example.com. Celui-ci fait autorité pour ce domaine et donne la réponse : « www.example.com a l'enregistrement A 192.0.2.10. »
- Le résolveur transmet la réponse à votre ordinateur. Votre navigateur se connecte à 192.0.2.10.
Un renvoi d'un niveau supérieur vers les serveurs de noms d'un niveau inférieur s'appelle une délégation. La racine délègue .com à Verisign, .com délègue example.com aux serveurs de noms indiqués par le titulaire du domaine. Pour un domaine .nl, cela se passe exactement de la même façon, sauf que la racine renvoie alors vers les serveurs de noms de .nl (SIDN, le registre de .nl aux Pays-Bas, par exemple ns1.dns.nl). Vous le constaterez vous-même dans l'exercice à la fin de cette leçon. C'est pourquoi il est si important que les serveurs de noms soient correctement enregistrés auprès du registre (leçon 2.1).
Le cache : pas tout le voyage à chaque fois
Si chaque résolveur devait recommencer par la racine à chaque requête, la racine recevrait une quantité de requêtes inimaginable. Cela n'arrive pas, car le résolveur mémorise les réponses pendant un certain temps. Cette mémoire s'appelle le cache.
La durée pendant laquelle une réponse peut être mémorisée figure dans la réponse elle-même : le TTL (time to live), en secondes. Un TTL de 3600 signifie : cette réponse peut être mémorisée pendant une heure. Les renvois sont eux aussi mémorisés. Un résolveur qui vient d'apprendre quels serveurs de noms gèrent .com n'a pas besoin de le redemander à la racine la fois suivante.
Si quelqu'un d'autre chez le même fournisseur demande une minute plus tard l'adresse de www.example.com, le résolveur répond immédiatement depuis son cache. Pas de voyage, pas d'attente.
Les caches se trouvent à plusieurs endroits :
- dans le résolveur de votre fournisseur ou le résolveur public que vous utilisez ;
- dans votre système d'exploitation (Windows, macOS, votre téléphone) ;
- dans votre navigateur ;
- parfois dans votre routeur.
C'est rapide et efficace, mais cela a une conséquence que vous rencontrerez souvent par la suite : si vous modifiez un enregistrement, les caches continuent à donner l'ancienne réponse jusqu'à l'expiration de leur TTL. C'est pourquoi une personne voit déjà une modification alors qu'une autre ne la voit pas encore. Le module 6 traite ce sujet en détail.
Les serveurs racines
Il existe 13 noms pour les serveurs racines : de a.root-servers.net à m.root-servers.net. Ils sont gérés par douze organisations différentes. Derrière chaque nom se trouvent, dans le monde entier, de nombreux serveurs, à des centaines d'endroits, qui partagent la même adresse (c'est ce qu'on appelle l'anycast). Votre résolveur arrive automatiquement sur un serveur proche. Les serveurs de noms des TLD, comme ceux de .com et .nl, fonctionnent de la même façon. Le DNS est ainsi rapide et continue de fonctionner même si un serveur tombe en panne quelque part.
Où cela peut-il se passer mal
Connaître le voyage vous aide à mieux situer les problèmes :
- La délégation est incorrecte. Les serveurs de noms enregistrés auprès du registre ne connaissent plus (ou pas) le domaine. Le résolveur n'avance plus à l'étape 4. La réponse est une erreur, ou il n'y a aucune réponse.
- Le serveur faisant autorité donne une réponse différente de celle attendue. Vous avez alors modifié l'enregistrement à un autre endroit que celui où se trouvent les serveurs de noms (leçon 2.1).
- Le cache contient encore l'ancienne réponse. Rien n'est cassé dans ce cas. Il faut attendre l'expiration du TTL, ou vider votre propre cache.
- Le DNSSEC est incorrect. Un résolveur validant vérifie les signatures en chemin. Si la chaîne n'est pas correcte, il refuse la réponse (leçon 8.1).
Avec l'outil dig +trace, vous pouvez refaire vous-même le voyage, depuis la racine jusqu'au serveur faisant autorité. Vous l'apprendrez dans la leçon 8.2. Des outils en ligne le permettent également.
Résumé
- Les serveurs de noms faisant autorité connaissent la réponse pour leur propre domaine ; les résolveurs cherchent la réponse pour vous.
- Un résolveur commence par la racine, reçoit un renvoi vers le TLD, puis vers les serveurs de noms du domaine, et obtient enfin la réponse.
- Un tel renvoi s'appelle une délégation.
- Les réponses sont mémorisées dans des caches, aussi longtemps que l'indique le TTL ; les modifications ne sont donc pas visibles partout immédiatement.
- Il existe 13 noms de serveurs racines, mais grâce à l'anycast, de nombreux serveurs se trouvent derrière chacun d'eux dans le monde entier.
Quiz
Exercice
Exercice Z1.4 : suivre le voyage. Suivez le voyage pour www.sidn.nl, avec dig +trace www.sidn.nl ou un outil en ligne qui affiche une trace. Indiquez : (1) un serveur de noms de nl. que vous rencontrez en chemin, (2) un serveur de noms faisant autorité de sidn.nl.
Pour aller plus loin
Ces articles décrivent la situation chez WebOké. Chez d'autres fournisseurs, le fonctionnement est comparable.