Comment fonctionne le DNS : d'un nom de domaine à une adresse IP

Saisissez example.com dans un navigateur et une page apparaît presque instantanément. Entre ces deux instants, une base de données distribuée à l'échelle de la planète a répondu à une question : quelle adresse IP correspond à ce nom ? Ce système, c'est le DNS, le Domain Name System.

Il vaut la peine de le comprendre correctement, car presque tous les problèmes de site web déroutants (une modification qui ne prend pas effet, des e-mails qui disparaissent, un site qui fonctionne sur un appareil mais pas sur un autre) s'expliquent par le comportement réel de la résolution DNS et de la mise en cache.

Les quatre participants

• Le résolveur stub : le petit client DNS intégré à votre système d'exploitation. Il ne sait presque rien et délègue immédiatement.
• Le résolveur récursif : généralement exploité par votre fournisseur d'accès, ou un résolveur public comme 1.1.1.1 ou 8.8.8.8. C'est le bourreau de travail qui part à la recherche de la réponse et la met en cache.
• Les serveurs racine et TLD : ils ne connaissent pas la réponse, mais savent qui la connaît. La racine renvoie vers .com ; les serveurs du TLD .com renvoient vers les serveurs de noms propres au domaine.
• Les serveurs de noms autoritaires : les serveurs qui détiennent les véritables enregistrements du domaine. Ce qu'ils disent fait, par définition, foi.

Une recherche, étape par étape

1. 1

   Consulter d'abord les caches locaux

   Votre navigateur possède son propre cache DNS, tout comme votre système. Si l'un des deux détient une réponse non expirée pour example.com, la recherche se termine en quelques microsecondes sans aucun trafic réseau.

2. 2

   Interroger le résolveur récursif

   En cas d'absence, le résolveur stub envoie la requête au résolveur récursif configuré : un seul paquet UDP, généralement sur le port 53.

3. 3

   Le résolveur interroge un serveur racine

   Si le résolveur n'a rien en cache, il repart du sommet. Le serveur racine ne connaît pas example.com, mais répond : voici les serveurs de noms de .com.

4. 4

   Le résolveur interroge les serveurs du TLD

   Les serveurs .com répondent par une délégation : les serveurs de noms autoritaires de example.com sont ceux-ci. Toujours pas la réponse : un autre pointeur.

5. 5

   Le résolveur interroge le serveur de noms autoritaire

   Celui-ci détient le véritable fichier de zone. Il renvoie l'enregistrement A : 93.184.216.34, accompagné d'un TTL indiquant combien de temps la réponse peut être réutilisée.

6. 6

   La réponse est mise en cache puis renvoyée

   Le résolveur met le résultat en cache pour la durée du TTL et le transmet à votre système, qui le transmet au navigateur. Ce n'est qu'à ce moment qu'une connexion TCP vers le serveur peut commencer.

Récursif ou autoritaire : la distinction qui compte

On les confond sans cesse, ce qui provoque de vraies erreurs de diagnostic.

La conséquence pratique : lorsque vous modifiez un enregistrement DNS, le serveur autoritaire se met à jour instantanément. Chaque résolveur récursif dans le monde continue de servir sa copie en cache jusqu'à l'expiration du TTL. Cet écart, c'est ce que l'on appelle la propagation DNS.

Ce qu'un résolveur renvoie réellement

Une réponse est plus qu'une adresse. Elle comporte un type d'enregistrement, une valeur et un TTL, ainsi que des indicateurs précisant si la réponse était autoritaire ou servie depuis le cache. Un même domaine publie de nombreux types d'enregistrements à la fois : A et AAAA pour les adresses, MX pour le routage du courrier, NS pour ses serveurs de noms, et TXT pour la vérification et les politiques.

example.com.    3600    IN    A        93.184.216.34
example.com.    3600    IN    AAAA     2606:2800:220:1::248
example.com.    3600    IN    MX       10 mail.example.com.
example.com.   86400    IN    NS       ns1.example.com.

Le nombre après le nom est le TTL en secondes. IN désigne la classe internet. Le reste est le type d'enregistrement et sa valeur.

Où le DNS pose problème en pratique

• La modification ne s'est pas propagée. Le serveur autoritaire est correct ; un cache entre vous et lui ne l'est pas. Rien à corriger, seulement à attendre.
• Les serveurs de noms pointent vers le mauvais fournisseur. Vous avez modifié les enregistrements chez votre bureau d'enregistrement, mais le domaine est délégué aux serveurs de noms de votre hébergeur, donc les modifications sont ignorées.
• Un point final manquant. Dans un fichier de zone, mail.example.com sans point final peut être interprété relativement à la zone, ce qui produit mail.example.com.example.com.
• Pas d'enregistrement AAAA mais des clients uniquement IPv6. Le site leur est inaccessible alors qu'il fonctionne parfaitement pour tous les autres.

Vous pouvez voir chacun de ces enregistrements pour n'importe quel domaine avec l'outil de recherche de la page d'accueil : il les interroge indépendamment, donc un domaine auquel il manque un type affiche quand même les autres.