Résolution DNS : étapes, acteurs et méthode d'analyse

Niveau : débutant à intermédiaire.

Prérequis : connaître les notions d'adresse IP, de client et de serveur. Savoir ouvrir un terminal est utile pour l'exercice. Aucune connaissance préalable de dig n'est requise.

L'exercice doit être réalisé sur ta machine et sur des noms réservés à la documentation. Il vise à apprendre à lire une réponse DNS sans explorer d'autres services ni élargir le périmètre.

Le Domain Name System est une base de données distribuée et hiérarchique. Un nom comme www.example.com est constitué de labels. Dans la hiérarchie DNS, on part de la racine, représentée par un point final souvent omis, puis passe par com, example et www.

Une question DNS associe au moins un nom, une classe et un type. Les types A et AAAA désignent respectivement des adresses IPv4 et IPv6. MX participe au routage du courrier. NS indique des serveurs de noms. TXT transporte du texte utilisé par différents mécanismes. CNAME indique qu'un nom est un alias d'un autre nom. Il ne faut donc pas réduire le DNS à un annuaire d'adresses IP.

Les RFC 1034 et 1035 posent les concepts et le format historique du protocole. La RFC 9499 actualise sa terminologie. La RFC 9499 permet d'éviter une confusion fréquente entre un résolveur minimal dans la machine cliente, parfois appelé « stub resolver », et le résolveur récursif qui poursuit la résolution.

Les concepts historiques sont définis dans les RFC 1034 et RFC 1035. La terminologie actuelle est consolidée par la RFC 9499.

L'application et le résolveur local

Un navigateur ou un autre programme demande au système de résoudre un nom. Le système peut consulter des sources locales, dont son cache ou un fichier d'hôtes, avant d'envoyer une question DNS. Le comportement exact dépend du système et de sa configuration. Cela explique pourquoi deux machines peuvent, temporairement, obtenir des résultats différents.

Le résolveur récursif

Le résolveur récursif reçoit la demande du client et cherche une réponse finale. Il peut être fourni par le réseau local, un opérateur ou un service configuré explicitement. S'il possède une réponse encore valide en cache, il peut la retourner sans recommencer toute la chaîne.

Les serveurs faisant autorité

Un serveur faisant autorité publie les données d'une zone. Les serveurs racine servent la zone racine. L'IANA rappelle que les treize identifiants de serveurs racine correspondent à de nombreuses instances déployées dans le monde déployés dans de nombreux pays. Le nombre de noms d'autorité ne doit donc pas être confondu avec le nombre de machines physiques.

Les serveurs racine orientent vers les serveurs du domaine de premier niveau, par exemple ceux de com. Ces derniers orientent ensuite vers les serveurs faisant autorité pour le domaine demandé. Une orientation de ce type est une délégation, pas encore nécessairement la réponse finale.

La liste officielle des serveurs racine publiée par l’IANA permet d’identifier les opérateurs, tandis que la documentation BIND de l’ISC décrit l’outil dig utilisé plus loin.

Lorsqu'un résolveur accepte une requête récursive, il renvoie au client une réponse finale ou un code d'erreur, en utilisant son cache et, si nécessaire, d'autres requêtes. Le client ordinaire délègue ainsi le travail à son résolveur récursif.

Dans une résolution itérative, l'acteur qui résout suit des références successives. Il interroge un serveur, reçoit l'indication d'un serveur plus proche de la zone recherchée, puis continue. La commande dig +trace illustre ce parcours en partant de la racine, même si son comportement ne reproduit pas exactement tous les détails internes d'un résolveur de production.

Il faut aussi prendre en compte les alias. Une réponse peut contenir un CNAME vers un autre nom, ce qui entraîne une nouvelle étape logique. Les sections d'un message DNS peuvent contenir la réponse, les autorités et des informations additionnelles utiles.

Chaque enregistrement possède une durée de vie, ou TTL, exprimée en secondes. Un cache peut conserver la donnée pendant cette période. Le TTL observé diminue généralement avec le temps. Après son expiration, une nouvelle interrogation devient nécessaire.

Le cache améliore les performances et réduit les requêtes vers les serveurs faisant autorité. Il complique aussi l'analyse : une modification de zone n'est pas instantanément visible partout, et une capture réalisée entre le client et son résolveur ne montre pas forcément les requêtes effectuées en amont.

Les réponses négatives peuvent également être mises en cache. NXDOMAIN indique que le nom demandé n'existe pas dans le DNS selon la réponse reçue. NOERROR avec une réponse vide peut signifier que le nom existe, mais qu'aucune donnée du type demandé n'est disponible. Confondre ces deux situations mène à de mauvais diagnostics.

Commence par le nom interrogé et le type. Vérifie ensuite le code de réponse : NOERROR, NXDOMAIN, SERVFAIL, REFUSED ou un autre code. Observe les indicateurs, dont RD pour recursion desired, RA pour recursion available et AA pour authoritative answer selon le contexte.

Regarde les sections QUESTION, ANSWER, AUTHORITY et ADDITIONAL. Note le serveur interrogé, le temps mesuré et la taille de la réponse. Une adresse présente dans ANSWER n'est pertinente que si tu comprends le nom et le type auxquels elle est associée.

Pour une analyse de sécurité, ajoute le contexte : quel poste a demandé le nom, quelle application était active, à quelle fréquence, quel résolveur a répondu et le nom demandé et les données retournées étaient-ils attendus dans ce contexte ? Un domaine rare n'est pas automatiquement malveillant. Un domaine très connu n'est pas automatiquement sûr.

Utilise uniquement les domaines réservés example.com, example.net ou example.org. Ces noms sont maintenus pour la documentation et évitent de choisir une cible arbitraire.

1. Vérifie que dig est installé. Il est fourni avec les outils BIND sur de nombreux systèmes.
2. Exécute :

dig example.com A

3. Repère le code de réponse, la section QUESTION, la section ANSWER, le TTL et le serveur interrogé.
4. Exécute ensuite :

dig example.com AAAA
dig example.com MX
dig example.com A +noall +answer

5. Compare les types et la présentation.
6. Facultatif, si ta politique réseau autorise les requêtes DNS directes : lance dig +trace example.com et identifie la racine, la délégation vers com, puis les serveurs du domaine.

Critère de réussite

Tu as réussi si tu peux relever, pour une requête, le nom, le type, le code de réponse, le résolveur interrogé et au moins un TTL, puis expliquer la différence entre la récursion demandée au résolveur et le suivi itératif de délégations. Une section ANSWER vide ou une réponse différente de l'exemple n'est pas un échec si tu sais relever le code de réponse et expliquer ce que tu observes si tu sais la décrire sans inventer son contenu.

Première erreur : croire qu'une requête du navigateur va toujours directement aux serveurs racine. Elle va généralement à un résolveur récursif, et un cache peut répondre. Deuxième erreur : interpréter un enregistrement isolé sans son type, son TTL ni son code de réponse.

Troisième erreur : conclure qu'l'absence de trafic DNS non chiffré sur le port 53 signifie qu'aucune résolution de nom n'a eu lieu. Le système peut avoir utilisé un cache, un fichier local ou un transport chiffré tel que DNS over HTTPS ou DNS over TLS. Le point d'observation détermine ce que l'on peut voir.

dig +trace est pédagogique, mais il ne représente ni le cache exact de ton résolveur habituel, ni toutes ses politiques, ni forcément le chemin observé par l'application. Enfin, DNSSEC apporte une validation d'authenticité et d'intégrité des données signées, mais ne chiffre pas à lui seul le nom demandé.