Fonctionnement et risques de DNS

Le système de noms de domaine (DNS) traduit les noms faciles à retenir comme example.com en adresses IP telles que 93.184.216.34. Presque toute transaction réseau commence par une résolution DNS, ce qui fait du DNS une cible de choix.

Si un attaquant contrôle ou manipule la résolution des noms, il peut rediriger discrètement les victimes vers des serveurs malveillants, intercepter le trafic ou exfiltrer des données sans toucher à l’application elle-même. Comprendre le chemin de résolution est la première étape pour le protéger.

Une résolution récursive classique parcourt une chaîne de serveurs :

• Résolveur local sur le client (le système d’exploitation, OS).
• Résolveur récursif (votre fournisseur d’accès à Internet (ISP) ou 8.8.8.8) qui effectue le travail.
• Serveurs racine qui indiquent les serveurs TLD.
• Serveurs TLD (par ex. .com) qui indiquent les serveurs faisant autorité.
• Serveurs faisant autorité qui contiennent les véritables enregistrements.

Chaque étape constitue un point d’interception ou d’usurpation potentiel.

Un résolveur récursif répond à toute requête en suivant les renvois pour le compte du client et en mettant le résultat en cache. Un serveur faisant autorité ne répond que pour les zones dont il a la responsabilité, avec les données définitives.

Sur le plan de la sécurité, les résolveurs récursifs ouverts peuvent être utilisés pour des attaques par amplification, tandis que les serveurs faisant autorité sont des cibles pour le détournement de zones et la compromission du bureau d’enregistrement. Limitez la récursion à votre propre réseau.

Voici les enregistrements que vous rencontrerez lors de vos analyses :

• A / AAAA — adresse IPv4 / IPv6.
• CNAME — alias vers un autre nom (attention aux CNAME orphelins qui peuvent permettre de prendre le contrôle d’un sous-domaine).
• MX — serveurs de messagerie.
• NS — délégation vers des serveurs faisant autorité.
• TXT — texte libre, utilisé pour SPF, DKIM et souvent détourné pour la tunnellisation.

Le DNS classique fonctionne sur le port UDP 53, avec un repli vers le TCP 53 pour les réponses volumineuses et les transferts de zone. UDP est sans connexion et sans état ; il n’y a donc pas de négociation permettant de prouver que le répondant est bien celui qu’il prétend être.

Le seul lien entre une requête et sa réponse est un ID de transaction de 16 bits et le port source. Cette association faible est à l’origine des usurpations et de l’empoisonnement du cache.

Pour réduire la charge, les résolveurs mettent les réponses en cache pendant la durée du TTL (durée de vie) de l’enregistrement. Une réponse avec un TTL de 3600 reste en cache pendant une heure.

La mise en cache est à double tranchant : elle améliore les performances, mais une seule réponse empoisonnée peut être fournie à de nombreuses victimes jusqu’à l’expiration du TTL. Les attaquants tentent souvent d’imposer des TTL longs afin que les entrées malveillantes persistent.

Le DNS présente de nombreuses surfaces d’attaque :

• Usurpation sur le chemin — forger des réponses plus vite que le serveur légitime.
• Empoisonnement du cache — injecter de mauvais enregistrements dans le cache d’un résolveur.
• Détournement du bureau d’enregistrement / de la zone — voler le contrôle du domaine lui-même.
• Tunnellisation — coder des données dans des requêtes pour contourner les contrôles des connexions sortantes.
• Amplification DDoS — utiliser abusivement des résolveurs ouverts comme réflecteurs.

Le DNS en clair ne fournit aucune garantie d’intégrité ou d’authenticité. Une réponse est considérée comme fiable si elle correspond à l’adresse IP source, au port de destination, au nom de la requête et à l’ID de transaction. Tous ces éléments peuvent être devinés ou observés par un attaquant situé sur le chemin.

Cette hypothèse de conception (le réseau est digne de confiance) explique l’existence de protections ajoutées après coup comme DNSSEC, DNS sur TLS (DoT) et DNS sur HTTPS (DoH).

Avant d’attaquer, les adversaires énumèrent les éléments DNS pour cartographier votre infrastructure. Des transferts de zone mal configurés (AXFR) peuvent extraire tous les enregistrements. La recherche par force brute de sous-domaines et les journaux de transparence des certificats révèlent des hôtes cachés.

Les défenseurs doivent limiter les transferts de zone aux serveurs secondaires connus et surveiller les schémas de requêtes en masse qui signalent une énumération.

Le DNS sur TLS (port 853) et le DNS sur HTTPS (port 443) chiffrent la requête afin que les observateurs situés sur le chemin ne puissent ni la lire ni la modifier. Cela réduit les risques d’usurpation et protège la confidentialité.

Le compromis pour les défenseurs est que le DNS chiffré peut empêcher votre propre filtrage et votre propre surveillance de voir les requêtes. De nombreuses entreprises configurent les clients pour utiliser exclusivement un résolveur DoH/DoT contrôlé plutôt que de laisser les terminaux en choisir des externes.

Renforcement pratique du chemin de résolution :

• Exécutez des résolveurs récursifs internes ; bloquez les connexions directes sortantes vers le port 53 sur Internet.
• Désactivez la récursion ouverte sur les serveurs faisant autorité.
• Limitez et journalisez les transferts de zone AXFR.
• Verrouillez le domaine auprès du bureau d’enregistrement (verrouillage du registre, MFA).
• Surveillez le volume et l’entropie des requêtes pour détecter la tunnellisation et l’énumération.

Vous avez appris que la résolution DNS parcourt une chaîne allant du résolveur local aux serveurs racine, TLD et faisant autorité, et que les réponses sont mises en cache selon leur TTL. Comme le DNS classique sur UDP/53 ne dispose d’aucune authentification, il est exposé à l’usurpation, à l’empoisonnement du cache, au détournement, à la tunnellisation et à l’amplification.

Principales défenses : récursion fermée, transferts de zone restreints, verrouillage auprès du bureau d’enregistrement, transport chiffré (DoT/DoH) et DNSSEC. Nous allons ensuite examiner en détail l’usurpation et l’empoisonnement du cache.