Qu'est-ce que le DNS et comment fonctionne-t-il vraiment ?

Chaque appareil sur Internet est joignable par une adresse numérique : une adresse IP. Personne n'a envie de retenir 172.64.80.1, alors on utilise des noms : example.com. Le DNS, le système de noms de domaine, est l'annuaire qui traduit le nom que vous saisissez en l'adresse dont un ordinateur a réellement besoin. On l'oublie facilement précisément parce qu'il fonctionne si fiablement en arrière-plan de presque toutes les requêtes réseau que vous effectuez.

La résolution, étape par étape

Quand vous visitez un domaine pour la première fois, votre appareil ne connaît pas encore son adresse IP. Il demande à un résolveur, généralement exploité par votre FAI ou par un fournisseur public comme Cloudflare ou Google, de la trouver. Ce résolveur ne connaît pas forcément la réponse non plus, alors il remonte une chaîne d'autorité :

1. Un serveur racine l'oriente vers les serveurs responsables du domaine de premier niveau du domaine (.com, .org, .io, etc.).
2. Le serveur TLD l'oriente vers les serveurs de noms faisant autorité pour le domaine précis : ceux que le propriétaire du domaine a réellement configurés.
3. Le serveur de noms faisant autorité renvoie l'enregistrement proprement dit : l'adresse IP (ou les adresses) vers laquelle le domaine pointe actuellement.

Toute cette chaîne se termine généralement en bien moins d'une seconde, et le résultat est ensuite mis en cache pour ne pas avoir à être répété à chaque requête : nous y revenons dans la section sur le TTL ci-dessous.

Un parcours concret, du début à la fin

Supposons qu'un résolveur au cache vide doive résoudre blog.example.com. Il interroge d'abord un serveur racine, qui ne connaît pas la réponse mais sait qui gère .com, et l'y renvoie. Le serveur TLD .com ne connaît pas non plus la réponse finale, mais il sait vers quels serveurs de noms example.com elle-même délègue (ns1.dnshost.com et ns2.dnshost.com, par exemple) et renvoie le résolveur vers eux. C'est seulement alors que le résolveur interroge un serveur qui détient réellement les enregistrements d'example.com, et ce serveur, celui qui fait autorité, répond avec la vraie réponse : un enregistrement A, ou un CNAME à suivre d'un saut supplémentaire. Chaque étape de cette chaîne est elle-même une recherche DNS, ce qui explique que la toute première recherche (à froid) d'un domaine soit nettement plus lente que toutes celles qui suivent une fois les réponses intermédiaires en cache.

La mise en cache intervient à plus de couches que le seul résolveur

Le résolveur récursif n'est pas le seul endroit où une réponse est mise en cache. La plupart des systèmes d'exploitation conservent leur propre cache DNS de courte durée, et certains navigateurs en gardent un autre par-dessus. C'est une deuxième raison courante pour laquelle deux recherches du « même » domaine peuvent sembler se contredire : ce n'est pas toujours un résolveur différent qui donne une réponse différente ; parfois, c'est votre propre machine qui sert une copie locale légèrement périmée alors qu'une requête directe et fraîche montrerait déjà la réponse actuelle.

Les types d'enregistrement que vous rencontrerez réellement

« Enregistrement DNS » n'est pas une chose unique : un domaine détient côte à côte plusieurs types d'enregistrement différents, chacun répondant à un genre de question distinct. Une recherche de l'adresse IP d'un domaine ne touche que deux d'entre eux ; les autres existent à des fins entièrement séparées.

Pourquoi cela compte même si vous ne touchez jamais aux enregistrements DNS

Comprendre ce fonctionnement donne du sens à beaucoup de comportements autrement déroutants : pourquoi un changement DNS ne prend pas effet instantanément, pourquoi un domaine peut se résoudre sans problème depuis un réseau et échouer depuis un autre, et pourquoi « le site est en panne » se révèle parfois être un problème de DNS plutôt que de serveur. Des outils comme celui-ci sautent directement à la dernière étape, en interrogeant directement un résolveur public proche de l'autorité et en vous montrant exactement ce qu'il renvoie, afin que vous voyiez l'état actuel réel du DNS d'un domaine sans deviner.

Cela explique aussi pourquoi « le DNS » et « Internet » sont si souvent confondus dans les dépannages informels. Le DNS ne transporte pas votre trafic, n'héberge pas votre contenu et n'exécute pas votre application : il ne répond jamais qu'à une seule question, « vers quelle adresse ce nom pointe-t-il en ce moment ». Tout ce qui se passe ensuite (la connexion proprement dite, le chargement de la page, la réponse de l'API) relève d'un système entièrement distinct, ce qui est exactement la raison pour laquelle isoler le DNS comme une étape à part, vérifiable indépendamment, vaut la peine avant de supposer un problème bien plus vaste.