Le DNS, de la requête à l'attaque
Comment un nom devient une adresse IP, les types d'enregistrements, et pourquoi le DNS est au cœur de beaucoup d'attaques… et de leur détection.
Elouan
Série Les fondations du réseau · article 5 sur 7
Presque toute action sur un réseau commence par une requête DNS : ouvrir un site, envoyer un mail, joindre un contrôleur de domaine… ou contacter le serveur de commande d’un malware. C’est pour ça que les journaux DNS sont parmi les plus utiles en sécurité.
Le rôle du DNS
Les machines se parlent avec des adresses IP, les humains retiennent des noms. Le DNS (Domain Name System) fait la traduction : www.exemple.fr devient 93.184.216.34.
C’est un annuaire hiérarchique et distribué, découpé en zones confiées à des serveurs différents.
. (racine)
┌─────────┼──────────┐
.fr .com .org ← domaines de premier niveau (TLD)
│
exemple.fr ← domaine, géré par son serveur faisant autorité
│
www.exemple.fr ← nom d'hôteLa résolution, étape par étape
C’est la question la plus classique sur le DNS. Quand un poste veut joindre www.exemple.fr, voilà les étapes :
- Le cache local. Le système regarde s’il connaît déjà la réponse (
ipconfig /displaydnssous Windows). - Le fichier hosts.
C:\Windows\System32\drivers\etc\hostsou/etc/hosts. Un malware qui modifie ce fichier peut détourner des noms. - Le résolveur récursif. Le poste envoie une requête récursive à son serveur DNS (celui de l’entreprise ou du FAI) : « donne-moi la réponse finale ».
- Les serveurs racine. Si le résolveur ne connaît pas la réponse, il demande à un serveur racine, qui répond : « je ne sais pas, mais voici les serveurs de
.fr». - Les serveurs du TLD. Les serveurs de
.frrépondent : « voici les serveurs qui font autorité pourexemple.fr». - Le serveur faisant autorité. Il donne enfin l’adresse de
www.exemple.fr. - Retour et cache. Le résolveur met la réponse en cache pour la durée du TTL et la renvoie au poste.
Récursif ou itératif ?
Le poste fait une requête récursive au résolveur : il veut la réponse finale. Le résolveur fait des requêtes itératives aux serveurs racine, TLD et faisant autorité : chacun lui indique qui interroger ensuite.
Les types d’enregistrements
| Type | Rôle | Exemple |
|---|---|---|
| A | Nom → adresse IPv4 | www.exemple.fr → 93.184.216.34 |
| AAAA | Nom → adresse IPv6 | www.exemple.fr → 2606:2800:220:1::248 |
| CNAME | Alias vers un autre nom | blog.exemple.fr → exemple.hebergeur.com |
| MX | Serveurs de messagerie, avec priorité | 10 mail.exemple.fr |
| TXT | Texte libre | SPF, DMARC, vérifications de domaine |
| NS | Serveurs faisant autorité pour la zone | ns1.exemple.fr |
| PTR | Résolution inverse, IP → nom | 34.216.184.93.in-addr.arpa → www.exemple.fr |
| SOA | Informations sur la zone (serveur principal, numéro de série) | Un par zone |
| SRV | Localiser un service (hôte et port) | _ldap._tcp.dc._msdcs.corp.local |
CNAME et autres enregistrements
Un nom qui a un CNAME ne peut avoir aucun autre enregistrement. C’est pour ça qu’on ne peut pas faire pointer la racine d’un domaine (exemple.fr) vers un autre nom avec un CNAME classique.
UDP ou TCP ?
Le DNS utilise le port 53, en UDP dans la grande majorité des cas : une question, une réponse, pas besoin de connexion. Il passe en TCP :
- quand la réponse est trop grosse (le serveur répond en UDP avec le flag « tronqué », et le client réessaie en TCP) ;
- pour les transferts de zone (AXFR), qui copient toute une zone d’un serveur à l’autre.
Le DNS vu par un attaquant
Le DNS est presque toujours autorisé en sortie. C’est ce qui en fait un outil parfait pour les attaquants.
| Technique | Principe | Ce qu’on voit |
|---|---|---|
| Commande et contrôle (C2) | Le malware résout le nom de son serveur | Requêtes vers des domaines récents ou de mauvaise réputation |
| DGA | Le malware génère des centaines de noms aléatoires | Beaucoup de réponses NXDOMAIN, noms sans sens (xkq7vz3p.com) |
| DNS tunneling | Des données encodées dans des sous-domaines | Sous-domaines longs et aléatoires, beaucoup de requêtes TXT |
| Fast flux | L’IP derrière un nom change en permanence | TTL très courts, réponses qui changent sans arrêt |
| Typosquatting | Un domaine qui ressemble au vrai | rnicrosoft.com, paypa1.com dans les mails de phishing |
| Empoisonnement de cache | Faire accepter une fausse réponse à un résolveur | Réponses incohérentes, résolution vers des IP inattendues |
| Détournement de domaine | Prendre le contrôle du compte chez le registrar | Serveurs NS ou enregistrements modifiés |
À quoi ressemble du tunneling
aGVsbG8gZnJvbSB0aGUgaW5zaWRl.data.attaquant.com, puis des centaines de requêtes semblables vers le même domaine. La partie gauche est de la donnée encodée en base64 ou en hexadécimal. Des outils comme iodine ou dnscat2 fonctionnent sur ce principe.
Le DNS vu par un défenseur
Quelques bonnes pratiques côté défense :
- Centraliser les journaux DNS du résolveur interne dans le SIEM : c’est souvent le moyen le plus simple de retrouver qui a contacté un domaine malveillant.
- Forcer l’utilisation du résolveur interne : bloquer le port 53 sortant vers Internet pour tout le monde sauf les serveurs DNS. Un poste qui interroge directement
8.8.8.8est suspect dans beaucoup de contextes. - Surveiller DoH et DoT : DNS over HTTPS (443) et DNS over TLS (853) chiffrent les requêtes. C’est bien pour la vie privée, mais un navigateur ou un malware qui les utilise contourne ta journalisation.
- Utiliser un DNS filtrant (RPZ, ou des services de filtrage) pour bloquer les domaines malveillants connus.
- Protéger les zones : interdire les transferts de zone à n’importe qui, activer DNSSEC quand c’est possible, et protéger le compte chez le registrar avec une double authentification.
Le DNS et Active Directory
Active Directory ne fonctionne pas sans DNS. Pour trouver un contrôleur de domaine, un poste interroge des enregistrements SRV comme _ldap._tcp.dc._msdcs.corp.local ou _kerberos._tcp.corp.local. C’est pour ça que les contrôleurs de domaine sont presque toujours aussi les serveurs DNS internes, et qu’un problème DNS se traduit souvent par « je n’arrive plus à ouvrir ma session ».
Côté défense, les journaux DNS sont une mine d’or : peu volumineux, et presque chaque action malveillante y laisse une trace.
L'essentiel
- Le DNS traduit un nom de domaine en adresse IP. Il utilise le port 53, en UDP la plupart du temps et en TCP pour les grosses réponses et les transferts de zone.
- Résolution : cache local → fichier hosts → résolveur récursif → serveurs racine → serveurs du TLD (.fr, .com) → serveur faisant autorité.
- Requête récursive : « donne-moi la réponse finale ». Requête itérative : « dis-moi qui interroger ensuite ».
- Enregistrements clés : A (IPv4), AAAA (IPv6), CNAME (alias), MX (mail), TXT (texte, SPF, DMARC), NS (serveurs du domaine), PTR (inverse), SOA (autorité), SRV (services, très utilisé par AD).
- Signaux d'attaque : domaines récents ou générés aléatoirement (DGA), sous-domaines longs et aléatoires (tunneling), forte volumétrie vers un seul domaine, réponses avec TTL très court qui changent sans arrêt (fast flux).
- DoH (DNS over HTTPS, 443) et DoT (DNS over TLS, 853) chiffrent le DNS : bon pour la vie privée, mais ça fait perdre la visibilité aux équipes de sécurité s'ils contournent le résolveur de l'entreprise.
Idées reçues
Que se passe-t-il exactement quand tu tapes www.exemple.fr dans un navigateur, côté DNS ?
L'erreur courante. Répondre « le DNS donne l'IP » sans détailler.
En réalité. Le système regarde son cache puis le fichier hosts. Sinon, il interroge son résolveur récursif (celui de l'entreprise ou du FAI). Si le résolveur n'a pas la réponse en cache, il interroge un serveur racine, qui le renvoie vers les serveurs du .fr, qui le renvoient vers le serveur faisant autorité pour exemple.fr, qui donne l'adresse. Le résolveur met en cache selon le TTL et répond au poste.
Un CNAME peut-il coexister avec un enregistrement MX sur le même nom ?
L'erreur courante. Dire oui sans réfléchir.
En réalité. Non. Un nom qui porte un CNAME ne peut porter aucun autre enregistrement (sauf DNSSEC). C'est pour ça qu'on ne peut pas mettre de CNAME à la racine d'un domaine (exemple.fr) qui porte déjà NS, SOA et souvent MX. Les hébergeurs contournent ça avec des alias propriétaires (ALIAS, ANAME, CNAME flattening).
Comment détecter du DNS tunneling ?
L'erreur courante. Répondre « en bloquant le port 53 ».
En réalité. On ne peut pas bloquer le DNS. On cherche plutôt : des sous-domaines très longs et à forte entropie, un volume anormal de requêtes vers un même domaine, beaucoup de requêtes TXT ou NULL, des réponses inhabituellement grosses, et des postes qui interrogent des serveurs DNS externes directement au lieu du résolveur interne.
Qu'est-ce qu'une attaque par empoisonnement de cache DNS ?
L'erreur courante. La confondre avec la modification du fichier hosts.
En réalité. L'attaquant fait accepter une fausse réponse par un résolveur, qui la garde en cache et la sert à tous ses clients pendant la durée du TTL. Les parades : ports source aléatoires et identifiants de transaction aléatoires (contre l'attaque de Kaminsky), et surtout DNSSEC, qui signe les réponses.
Pourquoi un contrôleur de domaine Active Directory est-il aussi un serveur DNS ?
L'erreur courante. Dire que c'est juste pratique.
En réalité. Parce qu'Active Directory repose sur le DNS pour fonctionner : les postes trouvent les contrôleurs de domaine, Kerberos et LDAP grâce à des enregistrements SRV (par exemple `_ldap._tcp.dc._msdcs.domaine.local`). Sans DNS correct, pas d'ouverture de session au domaine.
Tester ses connaissances
Références
- DNS and BIND (5e éd.)Cricket Liu, Paul Albitz · O'Reilly
- The Practice of Network Security MonitoringRichard Bejtlich · No Starch Press