Les attaques DNS exploitent les failles de la couche de résolution de noms — soit en falsifiant les réponses (cache poisoning), soit en détournant les enregistrements eux-mêmes (hijacking), soit en récupérant un sous-domaine abandonné (subdomain takeover), soit en exfiltrant des données via des requêtes DNS détournées (tunneling). Toutes ont en commun d'être discrètes : sans monitoring, vous les découvrez par les conséquences, jamais par la cause.
Les attaques DNS contre les PME ont augmenté de plus de 22 % en 2024 selon Cisco Talos, et les attaquants ciblent systématiquement les organisations sans visibilité sur leur zone DNS. Voici les cinq techniques les plus rencontrées en 2026 et comment les contrer.
1. DNS hijacking : la prise de contrôle de la zone
Le DNS hijacking consiste à modifier les enregistrements DNS d'un domaine en obtenant un accès non autorisé au compte registrar ou au panneau DNS. L'attaquant remplace ensuite les A, CNAME ou MX par ses propres valeurs : votre trafic web part vers un site cloné, vos emails vers son serveur.
Vecteurs d'entrée typiques
- Mot de passe registrar faible ou réutilisé
- Compromission de l'email associé au compte registrar
- Faille zero-day chez le fournisseur DNS
- Social engineering du support registrar (« j'ai perdu l'accès »)
Détection
Le seul signal fiable est la comparaison continue de la zone DNS avec un état de référence. Sans monitoring automatisé, le hijacking dure jusqu'à ce qu'un client signale le problème — souvent plusieurs jours.
Contre-mesures
- 2FA (TOTP) actif sur le compte registrar
- Registry Lock pour les domaines critiques
- Monitoring DNS toutes les heures minimum
- DNSSEC actif (empêche au moins la falsification en transit)
2. DNS cache poisoning : la falsification en transit
Le cache poisoning n'attaque pas votre zone DNS directement, mais les résolveurs intermédiaires que vos visiteurs interrogent. L'attaquant injecte une fausse réponse dans le cache d'un résolveur public ou FAI, qui sert ensuite cette mauvaise valeur à tous ses utilisateurs pendant la durée du TTL.
Cas d'école
L'attaque Kaminsky de 2008 a démontré qu'on pouvait empoisonner un résolveur en quelques secondes. Les patches ont durci la randomisation des ports, mais le problème n'est pas réglé sur tous les résolveurs.
Contre-mesures
- DNSSEC sur votre zone (un résolveur compatible vérifie les signatures et rejette les réponses falsifiées)
- Privilégier des résolveurs publics modernes (Cloudflare 1.1.1.1, Quad9 9.9.9.9, Google 8.8.8.8) qui valident DNSSEC par défaut
- TTL raisonnables (ni trop courts, ni trop longs)
3. Subdomain takeover : le sous-domaine abandonné récupéré
Quand un sous-domaine pointe via CNAME vers un service tiers (Heroku, GitHub Pages, Shopify, AWS S3, Azure) et que ce service est ultérieurement supprimé sans mettre à jour le CNAME, n'importe qui peut récupérer la ressource sur le service tiers et s'approprier le sous-domaine.
Conséquences
- Phishing ciblé sur votre marque depuis votre propre sous-domaine
- Vol de cookies sur des sous-domaines partageant le même domaine racine
- Usurpation pour campagnes malveillantes (votre image, vos logos)
- Atteinte durable à la réputation
Détection
Identifier les sous-domaines orphelins via un audit régulier de la zone DNS. Tester chaque CNAME : si le service de destination retourne une erreur "this resource is not claimed" ou similaire, le sous-domaine est vulnérable.
Contre-mesures
- Nettoyage régulier des sous-domaines inutilisés
- Procédure de désaffectation : supprimer le CNAME avant de supprimer la ressource côté service tiers
- Monitoring qui croise vos sous-domaines avec les bases de threat intelligence
4. NXDOMAIN attack : la dégradation par épuisement
Variante du DDoS, l'attaque NXDOMAIN inonde vos serveurs DNS de requêtes pour des sous-domaines aléatoires inexistants (ex. xyz123abc.votre-domaine.fr). Le serveur doit répondre NXDOMAIN à chaque requête, ce qui sature ses ressources et dégrade les vraies résolutions.
Symptômes
- Latence anormale sur les résolutions DNS légitimes
- Pic de logs sur des sous-domaines inexistants
- Indisponibilité intermittente du site sans cause apparente
Contre-mesures
- Utiliser un fournisseur DNS anycast managé (Cloudflare, AWS Route 53, Google Cloud DNS) capable d'absorber le volume
- Activer le rate limiting côté résolveur
- Monitorer le ratio NXDOMAIN/total — un pic soudain indique une attaque
5. DNS tunneling : l'exfiltration discrète
Le DNS tunneling utilise les requêtes DNS comme canal de communication caché, généralement pour exfiltrer des données ou maintenir un canal de commande malveillant depuis une machine compromise dans votre réseau interne. Les données sont encodées dans les sous-domaines (ex. aGVsbG8.command.attacker.com).
Ce n'est pas une attaque contre votre domaine au sens strict, mais une attaque via le DNS qui peut transiter par votre infrastructure si vous ne filtrez rien.
Détection
- Volumes anormalement élevés de requêtes vers un domaine externe peu connu
- Sous-domaines avec patterns base64 / hex inhabituels
- Trafic DNS vers des résolveurs non autorisés (autres que ceux de votre réseau)
Contre-mesures
- Filtrer le trafic DNS sortant pour ne forcer que les résolveurs autorisés
- Solutions DNS firewall (Cisco Umbrella, Cloudflare Gateway, Quad9)
- Monitoring du volume DNS par IP source
Comment se protéger globalement
Les cinq attaques ne se contrent pas avec un seul outil, mais avec un dispositif en couches :
| Couche | Action | Contre quelle attaque |
|---|---|---|
| Compte registrar | 2FA + Registry Lock + mot de passe fort unique | DNS hijacking |
| Zone DNS | DNSSEC actif + audit régulier des sous-domaines | Cache poisoning, subdomain takeover |
| Monitoring | Vérification continue des enregistrements + threat intelligence | Hijacking, takeover |
| Fournisseur DNS | Anycast + rate limiting | NXDOMAIN, DDoS |
| Réseau interne | DNS firewall + filtrage sortant | Tunneling, exfiltration |
Ce qu'il faut retenir
- Cinq attaques DNS dominent en 2026 : hijacking, cache poisoning, subdomain takeover, NXDOMAIN, tunneling.
- Toutes sont silencieuses : sans monitoring, vous les découvrez par les dégâts.
- La défense efficace est en couches : compte registrar verrouillé, DNSSEC actif, monitoring continu, fournisseur DNS managé, filtrage du DNS sortant.
- Les attaques contre PME progressent de 22 % par an — les organisations sans visibilité sur leur zone sont les cibles prioritaires.
Questions fréquentes
Comment savoir si mon domaine a été victime de DNS hijacking ?
Comparer l'état actuel de votre zone DNS (via dig ou un outil DNS Lookup) avec votre dernier export de référence. Toute divergence non documentée est un signal. Le monitoring continu détecte le changement en moins d'une heure.
DNSSEC protège-t-il contre toutes les attaques DNS ?
Non. DNSSEC empêche la falsification des réponses en transit (cache poisoning) mais ne protège pas contre une compromission de votre compte registrar (hijacking direct), un subdomain takeover, ou un DDoS NXDOMAIN. C'est une couche essentielle, pas suffisante seule.
Le subdomain takeover est-il vraiment fréquent ?
Oui. Les chercheurs en sécurité (HackerOne, Detectify) recensent des milliers de sous-domaines vulnérables sur les sites Fortune 500 chaque année. Les CNAME oubliés vers d'anciennes ressources Heroku, GitHub Pages, AWS S3, Azure ou Shopify sont des classiques.
Que faire si je détecte une modification DNS non autorisée ?
Quatre actions immédiates : 1) Restaurer la valeur précédente. 2) Changer le mot de passe registrar et activer le 2FA si pas fait. 3) Vérifier les logs d'accès au compte registrar. 4) Contacter le support du registrar pour comprendre comment l'accès a été obtenu. Documenter chaque étape.
Quelle est la différence entre cache poisoning et hijacking ?
Le hijacking modifie votre zone DNS à la source (vos enregistrements officiels sont compromis). Le cache poisoning n'attaque pas votre zone, il injecte de fausses réponses dans les caches des résolveurs intermédiaires que vos visiteurs interrogent — votre zone reste intacte mais les visiteurs voient une fausse valeur.
Faut-il payer pour Registry Lock ?
Cela dépend du registrar et du TLD. Chez Gandi et Cloudflare Registrar : souvent gratuit. Chez OVH ou Namecheap : payant (10 à 50 €/an selon l'offre). Pour un domaine business critique, c'est une assurance bon marché contre une catégorie d'attaques majeure.
Passer à la défense active
Les cinq attaques décrites partagent un point commun : elles exploitent l'absence de visibilité. La défense ne demande pas une équipe sécurité dédiée — elle demande des fondations correctes (DNSSEC, 2FA, Registry Lock) et un dispositif de monitoring qui détecte les anomalies en moins d'une heure.
Domains Defender surveille vos enregistrements DNS, alerte au moindre changement, croise vos sous-domaines avec URLhaus et Google Safe Browsing pour détecter les compromissions. Hébergé en France, conforme RGPD, essai gratuit 7 jours à partir de 4,99€ HT/mois.
Auditer votre zone DNS gratuitement — ou activer la surveillance continue.