Résolution DNS, du début à la fin

Chaque fois que vous entrez un domaine dans un navigateur, une chaîne de recherches s'exécute avant qu'un seul paquet n'atteigne le site que vous souhaitez. La plupart de cette chaîne est invisible, et la plupart des explications s'arrêtent à « c'est comme un annuaire téléphonique ». Voici ce qui se passe réellement, étape par étape, y compris les parties que les gens omettent généralement.

Le stub resolver n'est pas intelligent

Votre système d'exploitation n'effectue pas la résolution DNS tout seul. Il exécute un stub resolver, un morceau de code léger qui transfère simplement votre requête à n'importe quel serveur DNS configuré dans /etc/resolv.conf sur Linux ou dans les paramètres de votre adaptateur réseau sous Windows. Vérifiez le vôtre avec :

cat /etc/resolv.conf

Ce fichier pointe généralement vers votre routeur (comme 192.168.1.1), le resolver de votre fournisseur d'accès, ou un resolver public comme 1.1.1.1 ou 8.8.8.8. Le stub resolver n'a pas sa propre logique de cache au-delà de ce que le système d'exploitation ou un daemon local comme systemd-resolved fournit.

Le recursive resolver effectue le vrai travail

Une fois que votre requête atteint un recursive resolver, ce serveur se charge de trouver la réponse, même s'il doit demander à plusieurs autres serveurs pour y arriver. Si la réponse est déjà en cache à partir d'une recherche antérieure, vous la récupérez immédiatement. Vérifiez le TTL avec :

dig example.com

Regardez la ANSWER SECTION — le nombre avant le type d'enregistrement (comme 300 avant A) est le TTL en secondes. C'est la durée pendant laquelle les resolvers sont autorisés à mettre en cache l'enregistrement avant de demander à nouveau.

Si rien n'est en cache, le recursive resolver commence une traversée de la hiérarchie DNS à partir de la racine.

Serveurs racine, TLD et serveurs autoritaires

Il y a 13 adresses de serveurs racine (a.root-servers.net à m.root-servers.net), chacune soutenue par de nombreuses machines physiques via le routage anycast. Le serveur racine ne sait pas où example.com se trouve, mais il sait quels serveurs gèrent .com, il renvoie donc une délégation.

Le resolver demande alors un serveur TLD .com, qui de nouveau ne connaît pas la réponse finale mais sait quels nameservers sont autoritaires pour example.com spécifiquement. Vous pouvez voir cette délégation vous-même :

dig +trace example.com

Cette commande affiche chaque saut : racine, puis TLD, puis les nameservers autoritaires pour le domaine, se terminant par l'enregistrement A ou AAAA réel. C'est la meilleure commande pour comprendre DNS visuellement plutôt que théoriquement.

Le nameserver autoritaire est la dernière étape. C'est le serveur que le propriétaire du domaine a réellement configuré, souvent via le panneau DNS d'un registraire ou un service comme Route 53 ou Cloudflare DNS. C'est le seul serveur de toute la chaîne qui a la vraie réponse canonique au lieu d'une copie en cache ou d'une délégation.

Types d'enregistrements que vous rencontrerez réellement

Un enregistrement A mappe un nom à une adresse IPv4, AAAA fait la même chose pour IPv6. CNAME pointe un nom vers un autre nom plutôt qu'une IP, c'est ainsi que les CDN comme Cloudflare ou Fastly acheminent le trafic sans exposer les adresses IP brutes. Les enregistrements MX gèrent l'acheminement du courrier, et les enregistrements TXT contiennent du texte arbitraire, actuellement utilisé principalement pour SPF, DKIM et les chaînes de vérification de domaine. Les enregistrements NS indiquent au monde quels serveurs sont autoritaires pour une zone, et c'est le type d'enregistrement qui rend la délégation possible en premier lieu.

Où la mise en cache existe réellement

La mise en cache se produit à plusieurs niveaux simultanément : le navigateur lui-même (Chrome a son propre cache DNS visible à chrome://net-internals/#dns), le cache resolver du système d'exploitation, le routeur local et le recursive resolver en amont. C'est pourquoi un changement DNS peut sembler fonctionner instantanément sur un appareil et prendre des heures pour apparaître sur un autre — vous ne frappez pas le même cache.

Quand vous abaissez le TTL d'un enregistrement avant une migration prévue, vous n'accélérez rien immédiatement. Vous réduisez simplement la fenêtre pendant laquelle les données obsolètes peuvent persister une fois que le changement se produit réellement. Faites ceci au moins un cycle TTL à l'avance, pas cinq minutes avant le basculement.

Pourquoi cela importe pour le dépannage

Quand un site est inaccessible, dig +trace vous indique exactement quelle couche est cassée : un problème racine/TLD a un aspect complètement différent d'un serveur autoritaire mal configuré ou d'un cache obsolète sur votre propre machine. Comparer dig example.com par rapport à un resolver connu bon, comme dig example.com @1.1.1.1, isole si le problème vient de votre resolver local ou de la configuration DNS réelle du domaine.

DNS semble simple de l'extérieur parce qu'il se résout généralement en moins de 100ms et personne n'y pense. Dessous, c'est un système de requête distribué, mis en cache, hiérarchique qui fonctionne largement sans changement de structure depuis les années 1980, ce qui est un très bon argument pour montrer à quel point la conception originale a bien tenu.

Si vous voulez aller plus loin avec cela, Korra Studio a des segments connexes sur DEFENSE_GRID couvrant les extensions de sécurité DNS, le tunneling DNS comme technique d'exfiltration, et la construction de votre propre resolver à partir de zéro en Python.