Le DNS et la résolution de noms

Personne ne mémorise l'adresse IP de ses sites favoris : on tape un nom. Entre ce nom et l'adresse qui permet au paquet de voyager, un service travaille en coulisses des milliards de fois par jour : le DNS. C'est l'annuaire d'Internet, et c'est aussi un outil précieux pour qui s'intéresse à la sécurité.

Dans la leçon précédente, nous avons vu que chaque machine possède une adresse IP et que le DHCP fournit un serveur DNS à utiliser. Voyons maintenant ce que fait ce serveur, et comment vous pouvez l'interroger vous-même depuis votre terminal.

L'annuaire téléphonique de l'Internet

Le DNS (Domain Name System) associe des noms de domaine, faciles à retenir (example.com), à des informations techniques, dont l'adresse IP. Sans lui, il faudrait connaître le numéro de chaque site, comme si l'on devait retenir tous les numéros de téléphone sans carnet d'adresses.

Le DNS est organisé en hiérarchie, que l'on lit de droite à gauche. Dans www.example.com., le point final invisible représente la racine, puis vient le domaine de premier niveau (TLD : .com, .fr, .org…), puis le domaine (example), puis un sous-domaine (www).

Que se passe-t-il quand vous tapez un nom ?

Voici le déroulé simplifié, pour un nom jamais consulté :

1. Votre ordinateur regarde d'abord son cache local et le fichier hosts (une liste manuelle nom → adresse).
2. Sinon, il interroge son résolveur récursif (celui de votre fournisseur d'accès, de votre entreprise ou un résolveur public choisi par vos soins).
3. Ce résolveur interroge un serveur racine : « qui s'occupe de .com ? ». On lui indique les serveurs du TLD.
4. Il interroge le serveur du TLD : « qui s'occupe de example.com ? ». On lui indique les serveurs faisant autorité pour ce domaine.
5. Il interroge enfin ce serveur faisant autorité, qui donne la réponse définitive.
6. Le résolveur renvoie la réponse à votre machine et la garde en cache pour un temps limité.

Ce temps limité s'appelle le TTL (Time To Live), exprimé en secondes. C'est ce qui explique qu'un changement de DNS mette parfois du temps à « se propager » : chacun conserve l'ancienne réponse en cache jusqu'à l'expiration du TTL.

Les enregistrements DNS les plus courants

Un domaine n'a pas qu'une adresse. Sa zone DNS contient plusieurs types d'enregistrements :

Interroger le DNS avec dig et nslookup

Deux outils permettent de poser vous-même la question. Sous Linux et macOS, dig est le plus complet ; nslookup existe sur toutes les plateformes, y compris Windows.

dig example.com
dig example.com MX
dig +short example.com AAAA
dig @192.0.2.53 example.com

nslookup example.com

Dans la réponse de dig, repérez la section ANSWER, qui contient l'enregistrement, son TTL, son type et sa valeur. Le dernier exemple interroge un serveur précis (ici une adresse de documentation fictive) au lieu de votre résolveur habituel ; c'est utile pour comparer les réponses de plusieurs serveurs. Le nom example.com est réservé par convention aux exemples : il est parfait pour s'exercer.

Pourquoi le DNS est important pour la sécurité

Le DNS est omniprésent, et donc un terrain d'intérêt pour les attaquants comme pour les défenseurs :

• Les noms trahissent l'infrastructure. Les enregistrements publics d'une organisation révèlent des sous-domaines, des serveurs de messagerie, des services externes. Nous verrons dans le dernier chapitre comment la reconnaissance passive exploite ces informations publiques, dans un cadre légal.
• Le détournement de résolution. Si un attaquant parvient à fausser les réponses reçues (« empoisonnement de cache », faux résolveur, fichier hosts modifié par un logiciel malveillant), il peut rediriger vers un faux site tout en laissant la bonne adresse affichée dans la barre de navigation. Le cadenas HTTPS et la vérification du certificat (chapitre 6) protègent justement contre ce scénario.
• Les noms trompeurs. Les faux domaines proches des vrais (typosquatting) servent au phishing, comme vous l'avez vu dans le premier cours.
• La surveillance. Les requêtes DNS d'un réseau révèlent beaucoup de choses : les équipes de défense les analysent pour repérer des machines infectées qui contactent des domaines suspects.

Pour limiter les risques, le DNS peut être chiffré (DNS sur HTTPS ou sur TLS, qui empêchent le fournisseur de réseau de lire vos requêtes) et signé (DNSSEC, qui garantit l'authenticité des réponses d'une zone qui l'a activé). Ces protections ne sont pas toujours activées ; sachez simplement qu'elles existent.

Choisir son résolveur : un enjeu de confiance

Le résolveur que votre machine utilise voit la liste de tous les noms que vous demandez. Par défaut, c'est celui de votre fournisseur d'accès ou de votre entreprise, qui peut les journaliser ou filtrer certains domaines (contrôle parental, blocage de sites malveillants). Vous pouvez choisir un autre résolveur public ou en installer un chez vous. Il n'existe pas de choix universellement « meilleur » : l'essentiel est de savoir qui voit vos requêtes, et de faire confiance à cet acteur plus qu'à un autre.

Dans une entreprise, le DNS interne a un rôle de plus : il connaît les noms des serveurs internes (fichiers.entreprise.local, par exemple). C'est particulièrement vrai dans un environnement Windows avec Active Directory, que nous étudierons au chapitre 5 : sans DNS fonctionnel, un domaine Windows ne fonctionne tout simplement pas.

À vous de jouer

Exercice 1. Avec dig ou nslookup, interrogez example.com pour les types A, AAAA, MX et TXT. Notez dans votre carnet le TTL de l'enregistrement A, puis relancez la même commande une minute plus tard. Que remarquez-vous si vous passez par votre résolveur habituel ?

Exercice 2. Ouvrez le fichier hosts de votre machine (/etc/hosts sous Linux et macOS ; C:\Windows\System32\drivers\etc\hosts sous Windows) et lisez-le sans le modifier. Que contient-il ? Pourquoi un logiciel malveillant aurait-il intérêt à le modifier ?

Nous savons maintenant trouver une adresse à partir d'un nom. Il reste à comprendre comment on dialogue avec la machine trouvée : c'est le rôle des protocoles applicatifs comme HTTP, et des ports.