Vulnérabilités DNS : 10 failles courantes et comment y remédier

Une vulnérabilité DNS est une faille liée à la configuration, à l'hébergement ou à la gestion du DNS d'un domaine, qu'un pirate peut exploiter. Il peut s'agir, par exemple, d'un résolveur ouvert, d'une signature DNSSEC manquante ou d'un enregistrement CNAME oublié. La plupart de ces failles résultent de mauvaises configurations et d'enregistrements obsolètes plutôt que de failles logicielles, ce qui signifie que vous pouvez les identifier et les corriger avant qu'un incident ne se produise.

Quelles sont les vulnérabilités du DNS ?

Une vulnérabilité DNS est une faille opérationnelle, architecturale ou de configuration dans la mise en œuvre de votre système de noms de domaine (DNS) qui compromet la confidentialité, l'intégrité ou la disponibilité de votre trafic réseau.

Ces faiblesses se manifestent généralement à quatre niveaux opérationnels essentiels :

Gestion des enregistrements et des comptes : Identifiants partagés, absence d'authentification multifactorielle et verrous de registre omis, ce qui expose le contrôle de vos serveurs de noms.
Serveurs de noms faisant autorité : Règles de transfert de zone trop laxistes, démons de serveur non mis à jour, absence de limites de fréquence des requêtes ou absence de redondance des fournisseurs.
Résolveurs et transport : Résolveurs récursifs accessibles depuis l'Internet public, transmission non chiffrée via UDP en texte clair ou identifiants de transaction mal aléatoires.
Enregistrements DNS : Entrées CNAME orphelines pointant vers une infrastructure mise hors service, chaînes cryptographiques DNSSEC manquantes ou enregistrements de messagerie et de certificats absents.

Il est important de faire la distinction entre les vulnérabilités et les attaques. Une vulnérabilité est une faille ou une mauvaise configuration sous-jacente présente au sein de votre infrastructure. Une attaque consiste en l’exploitation délibérée de cette faiblesse par un tiers malveillant. Comprendre cette distinction permet aux équipes de sécurité d’éliminer les faiblesses avant les attaques DNS ne puissent se concrétiser.

10 vulnérabilités courantes du DNS

Les dix failles de sécurité suivantes constituent les problèmes les plus courants rencontrés dans les déploiements DNS d'entreprise.

1. Résolveurs DNS ouverts {#open-dns-resolvers}

Un résolveur récursif ouvert est un serveur DNS connecté à l'Internet public qui traite les requêtes récursives de n'importe quel utilisateur, au lieu de limiter la résolution aux clients locaux autorisés.

Ce que cela permet : Les attaquants usurpent l’adresse IP source de la victime ciblée et envoient des requêtes à des résolveurs ouverts, générant ainsi des charges utiles de réponse massives qui submergent la victime dans le cadre d’une attaque par attaques DDoS par amplification .
Comment vérifier : Lancez une requête vers l'adresse de votre serveur public depuis un réseau externe :

dig @<your-server-ip> example.com

Si le serveur renvoie une réponse contenant le indicateur « ra » (récursion disponible) activé, votre résolveur est vulnérable à la récursion publique non autorisée.
Solution : Désactivez complètement la récursivité sur les serveurs faisant autorité, ou limitez-la aux plages d’adresses IP et aux sous-réseaux de confiance à l’aide de listes de contrôle d’accès, conformément à nos meilleures pratiques en matière de sécurité DNS.

2. DNSSEC manquant ou défectueux

Le protocole DNSSEC (Domain Name System Security Extensions) utilise des signatures cryptographiques pour valider l'authenticité des données DNS. Ne pas utiliser le protocole DNSSEC ou autoriser des configurations cryptographiques permettant de contourner des enregistrements RRSIG périmés ou des enregistrements DS non concordants chez le registraire revient à laisser les résolutions non vérifiées.

Ce que cela permet : Sans vérification cryptographique, les résolveurs récursifs peuvent accepter des paquets de réponse falsifiés injectés par des attaquants sur le chemin du réseau, ce qui entraîne un un empoisonnement du cache et à une redirection du trafic.
Comment vérifier : Vérifiez la chaîne cryptographique de votre domaine à l'aide de notre vérificateur DNSSEC, ou découvrez comment les signatures lient les enregistrements dans notre guide d’introduction au DNSSEC.
Solution : Signez vos fichiers de zone, publiez les enregistrements DS (Delegation Signer) correspondants auprès de votre registraire de domaine et mettez en place des procédures automatisées de renouvellement des clés afin d'éviter toute interruption de la validation.

3. Transferts en zone sans restriction (AXFR)

Un transfert complet asynchrone (AXFR) est un mécanisme de protocole conçu pour synchroniser les données de zone entre les serveurs de noms principaux et secondaires. Un transfert de zone sans restriction permet à n'importe quel utilisateur sur Internet de demander et de télécharger l'intégralité du fichier de zone.

Ce que cela permet : Des fuites d’informations de reconnaissance. Les attaquants obtiennent une vue d’ensemble complète de votre surface d’attaque numérique, révélant ainsi les conventions de nommage internes, les serveurs de test, les passerelles VPN et les sous-domaines non répertoriés.
Comment vérifier : Effectuez une requête de transfert de zone directement auprès de votre serveur de noms faisant autorité :

dig AXFR example.com @ns1.example.com

Un serveur sécurisé renvoie le message suivant : Échec du transfert ou refuse la connexion. Si la commande renvoie la liste complète des enregistrements, cela signifie que vos paramètres de transfert sont ouverts.
Correction : Limiter les requêtes AXFR exclusivement aux adresses IP explicites appartenant à des serveurs de noms secondaires authentifiés, à l'aide de listes de contrôle d'accès (ACL) strictes.

4. Enregistrements DNS en suspens

Un enregistrement DNS « en suspens » se produit lorsqu'une entrée de votre zone (telle qu'un enregistrement CNAME, A ou NS) pointe vers une ressource cloud externe, un hébergeur web ou un compartiment de stockage qui a été mis hors service ou supprimé sans que le pointeur DNS correspondant ait été supprimé.

Ce que cela permet : Les acteurs malveillants identifient le nom de cible abandonné, provisionnent ce nom de ressource exact sur la plateforme du fournisseur (telle qu’AWS, Azure, GitHub Pages ou Heroku), et prennent le contrôle de votre sous-domaine dans le cadre d’une prise de contrôle de sous-domaine.
Comment vérifier : Exportez votre zone à l'aide de notre outil complet de outil de recherche d'enregistrements DNS et vérifiez que chaque point de terminaison externe, chaque cible CNAME et chaque hôte cloud reste activement revendiqué par votre organisation.
Solution : Mettre en place des protocoles de mise hors service automatisés afin de supprimer les enregistrements DNS correspondants chaque fois qu'une infrastructure cloud ou des services web tiers sont retirés.

5. Sécurité insuffisante des comptes de registraire

Les bureaux d'enregistrement gèrent les délégations des serveurs de noms de niveau supérieur pour vos domaines. La sécurisation de votre portail de bureau d'enregistrement à l'aide d'identifiants à authentification à un seul facteur, de boîtes mail administratives partagées, ou le fait de ne pas activer les verrous de protection au niveau du bureau d'enregistrement, crée un point de défaillance unique.

Conséquences : Les attaquants compromettent les identifiants de connexion du registraire, modifient les délégations de vos serveurs de noms faisant autorité et redirigent l'ensemble du trafic Web et de messagerie mondial vers une infrastructure malveillante, provoquant un détournement DNS .
Comment vérifier : Consultez la console de votre registraire pour vérifier si l'authentification multifactorielle est basée sur du matériel ou sur une application est appliquée est appliquée à tous les postes d'administrateur et si les indicateurs « Registry Lock » ou « Registrar Lock » sont actifs.
Solution : Imposer l'authentification multifactorielle pour toutes les connexions aux bureaux d'enregistrement, appliquer les codes d'état « Registry Lock » aux domaines critiques et mettre en place un accès dédié aux entreprises basé sur les rôles.

6. Serveurs DNS et contrôles d'accès mal configurés

Les déploiements logiciels par défaut sont souvent fournis avec des paramètres d'accès trop larges, des interfaces d'administration accessibles depuis Internet et des bannières de version affichées en réponse à de simples requêtes de sondage.

Ce que cela permet : Les attaquants identifient les logiciels serveurs et les niveaux de correctifs grâce à des requêtes de bannière telles que version.bind, identifient les failles non corrigées et exploitent les contrôles d’accès insuffisants pour manipuler les paramètres de configuration. Consultez notre guide de base intitulé ce qu’est un serveur DNS pour comprendre les principes de base d'une exploitation sécurisée.
Comment vérifier : Interroger la chaîne d'identité du serveur depuis un terminal :

dig version.bind CHAOS TXT @ns1.example.com

Un serveur sécurisé masque ces informations ou renvoie une réponse générique.
Correction : Masquer les chaînes de caractères indiquant la version du serveur, limiter l'accès aux interfaces de gestion aux VPN administratifs, mettre en œuvre la limitation du taux de réponse (RRL) et appliquer le principe du moindre privilège dans tous les fichiers de configuration.

7. Point de défaillance unique dans l'hébergement DNS

Le fait d'héberger tous les serveurs de noms faisant autorité auprès d'un seul fournisseur DNS, ou de déployer des serveurs de noms au sein d'un même système autonome (AS) physique, engendre une fragilité opérationnelle dangereuse.

Conséquences : Une attaque DDoS ciblée, une panne de fournisseur d’accès ou une erreur de routage peut rendre vos serveurs de noms de référence totalement inopérants, rendant ainsi vos sites web, vos API et vos e-mails professionnels totalement inaccessibles, comme l’a démontré la panne généralisée de Dyn en 2016.
Comment vérifier : Inspectez les enregistrements NS de votre domaine pour vérifier si vos serveurs de noms pointent vers des blocs réseau distincts et des systèmes autonomes indépendants.
Solution : Déployez une architecture DNS secondaire à deux fournisseurs, en répartissant la résolution faisant autorité entre deux services DNS distincts et géographiquement dispersés.

8. Trafic DNS non chiffré

Les requêtes et réponses DNS traditionnelles transitent par le port 53 via les protocoles UDP et TCP en clair. En l'absence de chiffrement, chaque recherche de domaine est lisible par les réseaux locaux, les fournisseurs d'accès à Internet et les opérateurs de transit.

Ce que cela permet : l'écoute sur le chemin de transmission, le profilage des utilisateurs et la manipulation sur le chemin de transmission, où des attaquants réseau interceptent des requêtes en clair et renvoient des réponses frauduleuses.
Comment vérifier : Vérifiez les paramètres du terminal et du routeur pour vous assurer que les résolutions sont acheminées via DNS sur HTTPS (DoH), DNS sur TLS (DoT) ou DNS sur QUIC (DoQ) plutôt que via le port UDP 53 brut.
Correction : Configurer les résolveurs, les points de terminaison et les redirecteurs locaux afin d'imposer un chiffrement de transport moderne à l'aide des protocoles cryptographiques standard TLS.

9. Logiciel DNS non mis à jour

Les démons DNS tels que BIND, Unbound, PowerDNS et le service DNS de Windows Server nécessitent une mise à jour régulière des correctifs. L'utilisation de versions obsolètes de ces démons expose les réseaux à des vulnérabilités connues répertoriées dans les bases de données CVE publiques.

Ce qu'elle permet : L'exécution de code à distance, la corruption de mémoire et les attaques par complexité algorithmique qui bloquent les serveurs de noms, telles que la vulnérabilité KeyTrap (CVE-2023-50387) dans les moteurs de validation DNSSEC ou le vecteur d'empoisonnement du cache DNS SAD (CVE-2020-25705).
Comment vérifier : Comparez les chaînes de compilation des démons en cours d'exécution avec les avis de sécurité des éditeurs et abonnez-vous aux flux de notifications des principaux développeurs de logiciels DNS.
Solution : Respectez les calendriers de mise à jour, isolez les services DNS dans des conteneurs restreints ou des environnements d'exploitation minimaux, et vérifiez que les versions compilées sont conformes aux derniers correctifs de sécurité.

10. Absence de registres relatifs à la sécurité et à la messagerie électronique

Si vous ne publiez pas les enregistrements de sécurité « affirmative » dans votre fichier de zone DNS, votre domaine est exposé à la délivrance non autorisée de certificats et à l'usurpation d'identité dans les e-mails sortants.

Ce que cela permet : Sans enregistrement CAA, n’importe quelle autorité de certification publique peut émettre des certificats SSL/TLS pour votre nom de domaine. De même, l’absence de SPF, de DKIM et de DMARC permet aux spammeurs d'envoyer des messages frauduleux en se faisant directement passer pour votre marque.
Comment vérifier : Vérifiez vos configurations de sécurité actuelles à l'aide de notre outil de vérification CAA, vérifiez vos politiques d'authentification avec notre vérificateur d'enregistrements DMARC, ou effectuez une évaluation complète via l’ analyseur de domaine.
Solution : Publier des enregistrements CAA restrictifs détaillant les émetteurs de certificats autorisés, et appliquer DMARC avec p=reject sur tous les domaines et sous-domaines de l'organisation.

Risques liés à la sécurité du DNS : ce que vous coûtent ces failles

Ne pas remédier aux vulnérabilités du DNS expose directement l'entreprise à des risques sur les plans financier, opérationnel et réglementaire.

Interruptions de service et perte de chiffre d'affaires : Les configurations reposant sur un seul fournisseur et les risques d'amplification non maîtrisés favorisent les pannes qui mettent hors ligne les opérations web et les plateformes commerciales.
Interception d'identifiants et redirections frauduleuses : l'empoisonnement du cache et le détournement DNS redirigent les visiteurs vers des serveurs sosies conçus pour récupérer les identifiants de connexion des entreprises.
Exfiltration de données d'entreprise : des résolveurs sans restriction et des redirecteurs mal configurés permettent aux attaquants de contourner les pare-feu et d'exfiltrer des données internes.
Usurpation d'identité de marque et compromission des e-mails professionnels : L'absence d'enregistrements SPF, DKIM et DMARC permet aux pirates de tromper les clients, les partenaires et les employés à l'aide d'e-mails falsifiés.
Génération de certificats frauduleux : L'omission d'enregistrements CAA augmente le risque de création de certificats TLS malveillants, ce qui compromet les principes de sécurité du transport.
Échecs d'audit et sanctions réglementaires : Les ressources DNS non gérées enfreignent fréquemment les exigences de contrôle obligatoires prévues par les normes SOC 2, ISO 27001 et PCI DSS.

Le tableau ci-dessous résume le lien direct entre les vulnérabilités courantes liées à la configuration du DNS et les vecteurs de cyberattaques qu'elles permettent :

Vulnérabilité DNS identifiée	Vecteur d'attaque activé
Résolveurs récursifs ouverts	Attaques par amplification et par réflexion DNS
DNSSEC manquant ou non validé	Empoisonnement et usurpation du cache DNS
Transferts en zone non restreinte (AXFR)	Reconnaissance de la surface d'attaque et découverte du réseau interne
Enregistrements CNAME et A « en suspens »	Prise de contrôle de sous-domaines et usurpation d'identité de compte
Comptes de registraire non sécurisés	Détournement DNS et redirection de domaine
Contrôles d'accès permissifs aux serveurs de noms	Exploitation du serveur et manipulation non autorisée des zones
Fournisseur d'hébergement avec un seul serveur de noms	Interruption totale du service en cas de panne chez les fournisseurs
Trafic UDP en clair sur le port 53	Interception sur le chemin de transmission et manipulation non autorisée des requêtes
Versions obsolètes du démon DNS	Déni de service à distance et exploitation de serveurs
Enregistrements CAA et DMARC manquants	Émission non autorisée de certificats SSL et usurpation de domaine sortant

Comment vérifier si votre domaine présente des failles DNS

La réalisation d'un audit structuré de l'ensemble de votre parc de domaines permet de détecter les erreurs de configuration avant que les attaquants ne les identifient :

Effectuez une analyse de référence de votre domaine : Saisissez votre domaine Apex dans notre outil d'analyse de domaine gratuit afin d'évaluer votre niveau de sécurité global et d'identifier les configurations manquantes.
Vérifiez votre chaîne DNSSEC : Testez vos clés racines et déléguées à l'aide de notre outil de vérification DNSSEC afin de vous assurer que les signatures sont valides et que les clés ne sont pas périmées.
Test authoritative zone transfer restrictions: Execute dig AXFR example.com @<nameserver> against every authoritative host to confirm that public zone dumping is rejected.
Vérifiez les autorisations de récursivité : Interrogez vos serveurs de référence depuis l'extérieur de la plage d'adresses IP de votre entreprise pour vous assurer que la résolution récursive est désactivée.
Vérifier les enregistrements de zone actifs à la recherche de pointeurs orphelins : Exportez toutes les entrées publiées à l'aide de notre outil de recherche d'enregistrements DNS et vérifiez que chaque ressource cloud externe et chaque cible CNAME reste valide.
Vérifiez les certificats et les mesures de protection des e-mails : Vérifiez les autorités de certification autorisées à l'aide de notre outil de vérification CAA et assurez-vous du respect des politiques grâce à notre outil de vérification des enregistrements DMARC.
Vérifier les paramètres de sécurité du registraire : Vérifiez les listes d'accès administratives, assurez-vous que l'authentification multifactorielle est bien activée et vérifiez que les verrous du registre restent activés.

Un audit ponctuel de l'infrastructure offre un aperçu de son état actuel, mais pour bénéficier d'une visibilité permanente, il est nécessaire de mettre en place une surveillance continue de la sécurité DNS afin de détecter les écarts en temps réel.

Comment corriger les failles de sécurité liées au DNS

Pour remédier aux vulnérabilités du DNS, il convient de donner la priorité aux configurations administratives et structurelles ayant un fort impact :

Sécurisez la couche de gestion : Appliquez l'authentification multifactorielle sur les portails des bureaux d'enregistrement de domaines et des DNS cloud, attribuez des rôles avec le moins de privilèges possible et activez immédiatement les protections de verrouillage des bureaux d'enregistrement.
Limiter l'exposition du réseau : Limitez les transferts de zone exclusivement aux adresses IP secondaires désignées, désactivez la récursivité sur les serveurs faisant autorité et mettez en place une limitation de débit.
Supprimer les enregistrements orphelins : Supprimez les enregistrements CNAME, A et NS orphelins pointant vers une infrastructure abandonnée ou des applications cloud tierces désaffectées.
Mettez en place une vérification cryptographique : Signez vos zones avec DNSSEC, vérifiez les enregistrements DS du registraire et imposez une authentification stricte des e-mails via DMARC, SPF et DKIM.

Pour découvrir l'intégralité de notre processus de renforcement de la sécurité administrative, consultez les directives officielles du NIST en matière de sécurité DNS.

Foire aux questions

Quelle est la faille de sécurité DNS la plus courante ?

La vulnérabilité DNS la plus courante est une mauvaise configuration. Des paramètres trop permissifs, tels que des résolveurs récursifs ouverts, des transferts de zone sans authentification, des enregistrements orphelins oubliés et des contrôles d'accès administratifs insuffisants, sont à l'origine de bien plus d'incidents de sécurité que les failles logicielles de type « zero-day ».

Quelle est la différence entre une faille de sécurité DNS et une attaque DNS ?

Une vulnérabilité DNS désigne une faiblesse sous-jacente, une mauvaise configuration ou une lacune architecturale au sein de votre système de noms de domaine. Une attaque DNS correspond à la tentative active d'un attaquant d'exploiter cette vulnérabilité pour voler des données, rediriger le trafic ou provoquer une interruption de service.

Le port 53 représente-t-il un risque pour la sécurité ?

Le port 53 n'est pas malveillant en soi ; il s'agit du port standard utilisé pour le DNS sur UDP et TCP. Cependant, laisser le port 53 ouvert aux requêtes récursives du grand public transforme le serveur en un résolveur ouvert, vulnérable aux attaques par amplification et à l'inspection.

À quelle fréquence dois-je effectuer un audit de sécurité du DNS pour détecter les vulnérabilités ?

Vous devez vérifier régulièrement vos configurations DNS. Bien que les contrôles manuels des autorisations des bureaux d'enregistrement et des fichiers de zone doivent être effectués au moins une fois par trimestre, il est recommandé de mettre en place une surveillance automatisée afin de détecter dès leur apparition les modifications non autorisées des enregistrements, les certificats arrivés à expiration et les noms d'hôtes orphelins.

En conclusion

Les vulnérabilités du DNS offrent aux attaquants des moyens d'intercepter le trafic, de lancer des attaques par déni de service et d'usurper l'identité des marques d'entreprise. Étant donné que la majorité des problèmes de sécurité liés au DNS proviennent davantage de négligences administratives courantes et de dérives de configuration que d'exploits de code « zero-day », un audit proactif et une maintenance régulière permettent de réduire considérablement votre surface d'attaque globale.