🌐 Résolution DNS — Recherche Récursive & Mise en Cache

La hiérarchie comporte trois niveaux en dessous du résolveur récursif. Les serveurs racine (il existe 13 adresses logiques de serveurs racine, exploitées par des organisations telles que l’ICANN et Verisign, répliquées sur plus de 1 500 nœuds physiques via anycast) ne connaissent rien des noms de domaine individuels mais dirigent vers les serveurs TLD faisant autorité. Les serveurs TLD (pour .com, .uk, .org, etc.) détiennent des enregistrements NS pointant vers les serveurs de noms faisant autorité pour chaque domaine de second niveau. Les serveurs faisant autorité détiennent les enregistrements réels A, AAAA, MX, CNAME et TXT qui résolvent un nom en une valeur finale. Le résolveur effectue des requêtes itératives à chaque niveau et collecte des références jusqu’à ce qu’il reçoive une réponse faisant autorité.

Chaque action Internet qui utilise un nom d’hôte déclenche le DNS. Lorsque vous ouvrez un navigateur, envoyez un e-mail, rejoignez un appel vidéo, ou diffusez des médias, le DNS fonctionne silencieusement en arrière-plan. Des fournisseurs de CDN tels que Cloudflare et Akamai utilisent le DNS pour router les utilisateurs vers le nœud périphérique le plus proche. Les équilibreurs de charge utilisent le round-robin DNS ou des enregistrements pondérés pour distribuer le trafic entre serveurs. Les services cloud utilisent des enregistrements génériques et CNAME pour cartographier dynamiquement les sous-domaines de locataires. Le DNS est aussi exploité pour l’authentification des e-mails (SPF, DKIM, DMARC reposent tous sur des enregistrements TXT) et pour la validation de certificats (défi DNS-01 dans ACME/Let's Encrypt).

Les requêtes DNS classiques voyagent en UDP en clair sur le port 53, ce qui signifie que votre FAI, les opérateurs réseau, et quiconque sur le chemin peut voir chaque nom d’hôte que vous recherchez, même si la connexion HTTPS suivante est chiffrée. C’est une idée fausse courante — beaucoup de gens supposent que HTTPS protège leur DNS. Des alternatives modernes telles que DNS over HTTPS (DoH, RFC 8484) et DNS over TLS (DoT, RFC 7858) chiffrent la conversation DNS, empêchant la surveillance passive. Des navigateurs comme Firefox et Chrome utilisent DoH par défaut vers un résolveur de confiance lorsqu’activé.

Paul Mockapetris a conçu le DNS et l’a publié dans les RFC 882 et 883 en novembre 1983 alors qu’il travaillait à l’USC Information Sciences Institute. Le problème moteur était le fichier HOSTS.TXT maintenu de manière centralisée de l’ARPANET, qui devait être téléchargé manuellement par chaque hôte et devenait ingérable à mesure que le réseau dépassait quelques centaines de nœuds. Le DNS l’a remplacé par un système décentralisé, hiérarchique et automatiquement délégué. Les premiers serveurs racine opérationnels sont entrés en service en 1984, et le DNS est resté depuis l’épine dorsale de nommage d’Internet.

Le DNS s’inscrit dans un paysage plus large de réseau et de cryptographie. Les fonctions de hachage sous-tendent DNSSEC, l’extension de sécurité DNS qui signe numériquement les enregistrements pour empêcher l’empoisonnement de cache — la simulation de Hachage SHA sur ce site montre comment fonctionnent ces fonctions à sens unique. Les arbres de Merkle sont utilisés à l’intérieur de DNSSEC pour le déni d’existence authentifié (NSEC3). Le routage BGP détermine quel chemin physique votre requête DNS emprunte à travers Internet, et les simulations de routage de paquets montrent comment les datagrammes UDP sont acheminés entre routeurs avant d’atteindre un serveur racine.

Les équipes DevOps traitent le DNS comme une préoccupation d’infrastructure de premier ordre. Des TTL courts (30–60 s) sont définis avant les changements d’IP planifiés ou les événements de basculement afin que les enregistrements repointés se propagent rapidement. Des services tels qu’AWS Route 53 et Cloudflare fournissent un basculement basé sur des contrôles de santé qui retire automatiquement les points de terminaison défaillants des réponses DNS en quelques secondes. Kubernetes utilise CoreDNS comme résolveur interne au cluster afin que les noms de service comme my-service.default.svc.cluster.local se résolvent en adresses ClusterIP internes au cluster sans quitter le nœud. Le DNS split-horizon permet aux clients internes et externes de recevoir des réponses différentes pour le même nom, permettant un accès réseau privé.

Les domaines de recherche actifs incluent le DNS chiffré à grande échelle : déployer DoH et DoT universellement tout en préservant la capacité des opérateurs à appliquer des politiques de sécurité et des contrôles parentaux. L’adoption de DNSSEC reste faible (environ 20 % des domaines sont signés) en partie à cause de la complexité de la rotation des clés et des risques d’énumération de zone NSEC qui dissuadent les opérateurs. Oblivious DNS over HTTPS (ODoH) et DNS over QUIC (DoQ, RFC 9250) visent à réduire davantage la latence et à améliorer la confidentialité. Les chercheurs étudient aussi comment des classificateurs basés sur l’IA peuvent détecter le tunneling DNS et l’exfiltration de données cachées dans des charges utiles d’enregistrements TXT ou NULL, de plus en plus utilisées par les logiciels malveillants pour la communication de commande et contrôle.