Enregistrements DNS « en suspens » : de quoi s'agit-il et comment empêcher le détournement de sous-domaines ?

Un enregistrement DNS « orphelin » est une entrée DNS qui pointe toujours vers une ressource qui n'existe plus, comme un service cloud supprimé, un serveur mis hors service ou une plateforme tierce inactive. L'enregistrement continue d'être résolu alors que la destination à laquelle il renvoie a disparu, et c'est précisément cette faille que les attaquants cherchent à exploiter.

Pour les équipes informatiques et de sécurité, la difficulté réside rarement dans l’identification d’un seul enregistrement erroné. Elle consiste plutôt à maintenir une visibilité constante sur l’ensemble des domaines, sous-domaines et enregistrements d’authentification, alors que l’infrastructure sous-jacente évolue. Chaque migration, chaque changement de fournisseur et chaque service mis hors service laisse derrière lui des éléments susceptibles de poser problème.

Qu'est-ce qu'un enregistrement DNS flottant ?

Un enregistrement DNS « dangling » est une entrée DNS qui pointe vers une ressource qui n'existe plus ou qui est inaccessible. Les cybercriminels sur Internet sont constamment à la recherche de ce type d'entrées DNS, car celles-ci sont susceptibles d'entraîner des fuites d'informations. Certaines de ces entrées peuvent contenir des informations sensibles concernant un domaine, ce qui en fait une véritable mine d'or pour les acteurs malveillants.

Situations courantes pouvant entraîner l'apparition d'un DNS « dangling »

Erreurs de configuration du DNS. Le système de noms de domaine (DNS) est configuré indépendamment de la ressource Internet avec laquelle nous souhaitons interagir. Les enregistrements DNS ajoutés au DNS pointent vers ces ressources, ce qui nous permet d’y accéder. Dans certains cas, une ressource précédemment configurée peut être déconfigurée par son hébergeur. Par exemple, un enregistrement DNS a été configuré par le propriétaire d’un domaine pour pointer vers l’adresse IP d’un serveur. Ce serveur n’est désormais plus utilisé. L’enregistrement DNS pointe désormais vers une ressource qui n’existe plus et peut donc être qualifié d’entrée « DNS orpheline ».

Ressources cloud expirées ou supprimées. Si un service cloud utilisé par le propriétaire d’un domaine arrive à expiration ou est supprimé, tout enregistrement DNS pointant vers ce service devient un enregistré orphelin . Cet enregistrement DNS reste actif, et n'importe quel attaquant peut utiliser cette ressource pour diffuser du contenu malveillant.

Adresses IP obsolètes. Une entreprise peut migrer ses services vers un nouveau fournisseur, tandis que les anciennes adresses IP sont obsolètes. Si l'équipe oublie de mettre à jour ou de supprimer les anciens enregistrements DNS, ceux-ci deviennent vulnérables à une prise de contrôle de sous-domaine et peuvent être facilement exploités.

Mise hors service ou arrêt d'un service. Un serveur de messagerie, un compte d'hébergement ou un prestataire de services tiers est interrompu ou mis hors service ; cependant, les enregistrements DNS tels que les enregistrements MX, A et CNAME restent actifs et configurés. Les attaquants peuvent exploiter ces enregistrements DNS actifs et orphelins pour usurper l'identité du service interrompu.

Quels enregistrements DNS se retrouvent « en suspens » et quels sont les risques associés à chacun d'entre eux ?

La vulnérabilité réside dans l'écart entre la couche DNS et la couche des ressources. Un enregistrement peut être syntaxiquement parfait tout en restant dangereux lorsque la destination qu'il désigne n'est plus détenue ou mise à disposition. Le tableau ci-dessous présente cet écart par type d'enregistrement.

Erreur courante

Considérer une recherche DNS réussie comme la preuve que l'enregistrement est valide. Un enregistrement « dangling » se résout normalement, car l'entrée elle-même est valide. Ce qui importe, c'est de savoir si votre organisation détient et contrôle toujours la destination. Vérifier la résolution sans vérifier la propriété est la raison pour laquelle ces enregistrements passent les audits.

Où les enregistrements « en suspens » apparaissent-ils le plus souvent ?

Certaines parties d'un domaine fournissent ces documents de manière bien plus fiable que d'autres. Savoir lesquelles vous permet de mener vos vérifications en fonction de la probabilité, plutôt que de passer au crible l'ensemble de la zone à chaque fois.

• Compartiments de stockage dans le cloud et hébergeurs de sites statiques : les noms de compartiments sont uniques au niveau mondial et peuvent être réenregistrés librement ; ainsi, un compartiment supprimé disposant d’un enregistrement CNAME actif figure parmi les cibles les plus faciles à récupérer
• Sous-domaines personnalisés CDN et SaaS : help.example.com, status.example.com et careers.example.com renvoient généralement vers des plateformes tierces qui libèrent le nom d'hôte dès que l'abonnement arrive à expiration
• Outils de marketing et de pages de destination : les sous-domaines de campagne sont rapidement mis en place par des équipes extérieures au service informatique et sont rarement soumis à un processus de mise hors service
• Environnements de préproduction et de test : les enregistrements « dev », « uat » et « staging » survivent aux projets qui les ont créés, et personne ne s'en rend compte car aucun trafic réel ne dépend d'eux
• Domaines acquis ou filiales : les zones héritées comportent des enregistrements dont les propriétaires d'origine ont cessé leurs activités, et la documentation qui les accompagne est rarement fournie
• Fournisseurs de messagerie électronique et d'assistance qui ont cessé leurs activités : Enregistrements MX, CNAME DKIM et inclusions « SPF » pour une plateforme dont vous avez cessé de payer l'abonnement l'année dernière

Le point commun entre ces cas est la dérive de la propriété. Chaque enregistrement a été créé correctement par une personne habilitée à le faire, puis a survécu à la relation qui justifiait son existence. C'est pourquoi la responsabilité du nettoyage incombe à celui qui met fin à un service, et non à celui qui gère le DNS.

Enregistrements TXT DMARC

Les enregistrements DMARC sont publiés sous forme d'enregistrements TXT et incluent souvent des destinations de rapport via les balises « rua » et « ruf ». Si ces destinations renvoient vers des boîtes mail inactives ou non surveillées, les équipes perdent toute visibilité sur les échecs d'authentification et les tentatives d'usurpation d'identité, sans qu'aucune erreur ne soit signalée. Vérifiez comment vous publiez un enregistrement DMARC chaque fois que les adresses de notification ou leurs propriétaires changent.

SPF Enregistrements TXT

SPF Les enregistrements répertorient les services d’envoi autorisés via des adresses IP et intègrent des mécanismes de contrôle. Si un enregistrement « SPF » fait référence à un service tiers obsolète ou à un domaine abandonné, l’authentification perd de sa fiabilité, et un attaquant qui enregistre ce domaine de fournisseur abandonné hérite de l’autorisation d’envoi. Les enregistrements dépassent également la limite des 10 requêtes DNS à mesure que les expéditeurs SaaS s’accumulent ; il convient donc de SPF les aplatir permet de les maintenir en dessous de ce plafond. En savoir plus sur SPF.

Enregistrements TLS-RPT

Les enregistrements TLS-RPT définissent où se trouve le SMTP TLS doivent être envoyés. Si la destination de ces rapports est inactive, mal configurée ou n’est plus surveillée, les équipes passent à côté des défaillances de sécurité de transport affectant la livraison des e-mails chiffrés. En savoir plus sur TLS-RPT et MTA-STS.

Enregistrements DKIM CNAME

Les enregistrements DKIM peuvent être publiés sous forme d'enregistrements CNAME pointant vers l'hôte DKIM d'un fournisseur de messagerie. Si le compte du fournisseur est supprimé ou si le domaine cible devient inactif, la signature et la vérification DKIM cessent de fonctionner sans que cela soit signalé. Par exemple, le sous-domaine mail.domain.com est un alias du CNAME info.domain.com. Ainsi, lorsqu'un serveur recherche mail.domain.com, il est redirigé vers info.domain.com. Votre système d’authentification DKIM est souvent ajouté au DNS sous la forme d’un enregistrement CNAME.

Remarque : les enregistrements MX, NS, A, AAAA, CNAME et TXT peuvent tous devenir « orphelins » lorsqu’ils font référence à une infrastructure inactive, à des services désaffectés ou à des fournisseurs tiers abandonnés. Cet article se concentre sur les enregistrements d’authentification des e-mails, car ce sont ces défaillances qui restent invisibles le plus longtemps.

Comment un DNS « en suspens » peut conduire à la prise de contrôle d'un sous-domaine

Caché Les vulnérabilités DNS telles que les DNS « dangling » peuvent conduire à l'exploitation de domaines et à des cybermenaces. Dans les secteurs réglementés tels que la finance, la santé, l’éducation, le commerce de détail et le secteur public, les problèmes non résolus liés au DNS et à l’authentification compliquent également les évaluations de sécurité et la préparation aux audits.

L'attaque elle-même suit un déroulement prévisible, ce qui est utile car cela permet de voir exactement à quel moment un contrôle vient rompre la chaîne.

1. Énumération des sous-domaines. L'attaquant analyse votre domaine à la recherche de sous-domaines à l'aide d'outils DNS publics, de journaux de transparence des certificats ou d'une énumération par force brute.
2. Identification d'un enregistrement « dangling ». L'attaquant identifie un enregistrement CNAME, A ou MX pointant vers un service externe qui renvoie une réponse du type « compte inexistant » ou « non réclamé ».
3. Réclamation de ressources. L'attaquant enregistre ce même compte, ce même compartiment ou ce même nom d'hôte sur la plateforme externe, qu'il s'agisse d'un compartiment de stockage cloud, d'un point de terminaison CDN ou d'un sous-domaine SaaS.
4. Détournement de trafic. Comme votre enregistrement DNS pointe toujours vers ce sous-domaine, chaque requête adressée à celui-ci transite désormais par l'infrastructure contrôlée par le pirate.
5. Abus de confiance héritée. Le sous-domaine de confiance diffuse alors des pages de hameçonnage, héberge des logiciels malveillants, vole des cookies de session, envoie des e-mails usurpés ou collecte des identifiants, le tout sous le nom de domaine de votre organisation.

Qu'est-ce qu'une attaque par prise de contrôle de sous-domaine ?

Lorsqu'un attaquant détecte une entrée DNS orpheline pointant vers une ressource dont la configuration a été supprimée, il peut s'emparer de cette ressource abandonnée et rediriger le trafic vers une infrastructure qu'il contrôle. L'attaquant prend le contrôle du (sous-)domaine vers lequel pointe l'enregistrement DNS orphelin, acheminant ainsi l'intégralité du trafic vers un domaine qu'il contrôle, ce qui lui confère un accès complet au contenu et aux ressources de ce domaine.

Les dégâts vont bien au-delà d'une simple page altérée. Les actions des attaquants comprennent notamment le vol d'identifiants via de fausses pages de connexion, l'hébergement de logiciels malveillants sur un sous-domaine de confiance, l'usurpation d'identité de la marque par e-mail et sur le Web, l'interception de cookies de session, l'exploitation abusive du référencement naturel (SEO) en tirant parti de l'autorité de votre domaine, l'exploitation abusive de la distribution des e-mails due à une mauvaise configuration des enregistrements MX ou « SPF », ainsi que l'atteinte à la réputation qui se révèle ultérieurement lors des audits de conformité.

Nom d'hôte « en suspens » vs. enregistrement DNS « en suspens »

Ces deux termes sont étroitement liés et sont souvent utilisés de manière interchangeable, bien qu'ils désignent des concepts différents. Un enregistrement DNS « dangling » correspond à l'entrée elle-même, c'est-à-dire un enregistrement CNAME ou A qui existe toujours dans votre fichier de zone mais qui pointe vers une ressource supprimée ou dont personne n'est propriétaire. Un nom d'hôte « dangling » correspond au sous-domaine dont la résolution renvoie vers une destination que personne au sein de votre organisation ne contrôle plus.

Concrètement, c'est l'enregistrement qui crée le nom d'hôte. Si dev.example.com dispose d'un enregistrement CNAME pointant vers un compte d'hébergement désactivé, alors dev.example.com est un nom d'hôte orphelin et l'enregistrement CNAME est l'enregistrement orphelin qui se cache derrière. Cette distinction est importante car les outils de scan signalent l'un ou l'autre, alors que les deux nécessitent la même mesure corrective : vérifier la propriété de la cible, puis supprimer ou rediriger l'enregistrement.

Comment détecter les enregistrements DNS orphelins

Identifier dès les premières étapes les enregistrements DNS qui pointent vers des ressources non provisionnées peut contribuer à protéger votre marque. Vous pouvez procéder de deux manières : manuellement ou de manière automatisée.

Détection manuelle

Bien qu'il soit chronophage, un audit manuel peut permettre de détecter les enregistrements DNS obsolètes, notamment à la suite de migrations vers le cloud, de changements de fournisseur, de la mise hors service de services ou de l'intégration de nouveaux expéditeurs.

• Vérifiez vos enregistrements DNS : Vérifiez que tous les enregistrements DNS de votre système de gestion DNS correspondent bien aux ressources actives de votre environnement. Recherchez les enregistrements pointant vers des services ou des adresses IP inexistants.
• Vérifier les configurations DNS : Utilisez des outils tels que nslookup ou dig pour interroger chaque enregistrement et vérifier que la ressource correspondante est bien provisionnée et active. Une réponse DNS ne suffit pas à elle seule à garantir la sécurité ; assurez-vous donc que la cible appartient à votre organisation et qu'elle est gérée activement par celle-ci.
• Vérifiez s'il existe des services orphelins : Vérifiez les services tels que les hébergements tiers, les plateformes cloud ou les fournisseurs de CDN qui auraient pu être résiliés sans que les entrées DNS associées aient été supprimées.

Pour la validation enregistrement par enregistrement, vous pouvez également soumettre chaque entrée à un outil de vérification des enregistrements DNS afin de vérifier à quoi elle correspond actuellement avant de décider de la conserver ou non.

Pourquoi la détection manuelle s'avère inefficace à grande échelle

Si les méthodes manuelles sont rigoureuses, elles sont toutefois sujettes à l'erreur humaine et peuvent devenir ingérables pour les domaines dont les configurations DNS sont volumineuses ou complexes. Plusieurs facteurs les rendent peu fiables bien avant même qu'une zone n'atteigne une taille importante.

• Répartition décentralisée de la gestion du DNS entre les équipes et les services
• Des environnements de test et de préproduction oubliés qui contiennent encore des enregistrements DNS actifs
• L'informatique « fantôme » et les intégrations SaaS tierces non répertoriées
• Ressources cloud périmées n'ayant jamais fait l'objet d'un processus officiel de mise hors service
• Plusieurs zones DNS héritées à la suite d'acquisitions ou de domaines de filiales
• Documentation insuffisante concernant une infrastructure héritée dont personne n'est actuellement responsable

Détection automatisée

La surveillance automatisée devient indispensable lorsque les domaines, sous-domaines, expéditeurs et services cloud évoluent plus rapidement que la fréquence des audits. Plutôt que de recourir à des contrôles périodiques, une plateforme centralisée met en évidence en continu les enregistrements inactifs, les configurations d'authentification défaillantes et les modifications suspectes sur l'ensemble du portefeuille.

L'avantage concret réside davantage dans la rapidité que dans l'exhaustivité. Un audit trimestriel finira par détecter le même problème, mais seulement après un trimestre d'exposition. La surveillance continue comble cette fenêtre temporelle entre le moment où le service est mis hors service et le prochain contrôle, là où réside en réalité le risque de prise de contrôle.

Comment corriger les enregistrements DNS « en suspens »

Une fois qu'un enregistrement orphelin a été identifié, l'ordre des opérations est crucial. Supprimer l'enregistrement avant de libérer la ressource peut laisser une fenêtre ouverte, et ignorer l'étape relative au TTL signifie que la propagation de votre correction prendra des heures au lieu de quelques minutes.

1. Identifiez l'entrée et sa cible. Utilisez des outils DNS ou une plateforme de surveillance pour localiser l'entrée spécifique et déterminer vers quoi elle pointe actuellement.
2. Vérifiez que vous êtes bien le propriétaire de la cible. Vérifiez si votre organisation contrôle toujours la destination en interrogeant le fournisseur ou le registre des comptes.
3. Commencez par réduire la valeur TTL. Réglez-le entre 60 et 300 secondes avant d'effectuer des modifications afin que les mises à jour se propagent rapidement une fois que vous aurez agi.
4. Récupérez la ressource si elle peut être réclamée. Si la cible est un compartiment cloud ou un point de terminaison CDN non réclamé, réclamez-la avant de modifier le DNS afin de fermer la fenêtre de prise de contrôle.
5. Supprimez l'enregistrement ou modifiez son lien. Supprimez-le si le service n'est plus utilisé. S'il doit rester actif, redirigez-le vers une ressource dont vous êtes actuellement propriétaire et que vous avez provisionnée.
6. Vérifiez la propagation. Utilisez dig ou nslookup pour vérifier que l'enregistrement se résout correctement et que l'ancienne destination ne répond plus.
7. Consignez la modification. Notez ce qui a changé, pourquoi, quand et par qui, puis mettez à jour l'inventaire DNS et attribuez la responsabilité de la gestion à long terme.

Comment empêcher le détournement de sous-domaines dû à des enregistrements DNS orphelins

La prévention allie une bonne hygiène DNS à une surveillance continue. Les mesures ci-dessous revêtent une importance capitale pour les équipes informatiques, les équipes de sécurité et les prestataires de services gérés (MSP) qui gèrent plusieurs domaines.

• Supprimez immédiatement les enregistrements DNS inutilisés : supprimez les enregistrements CNAME, A, AAAA, MX et TXT lorsque les services sont mis hors service, plutôt que de les laisser en place « au cas où ».
• Vérifiez les cibles tierces avant de les pointer : assurez-vous d'abord que les ressources cloud, CDN, de messagerie et d'hébergement sont actives et appartiennent bien à votre organisation
• Surveillez les enregistrements d'authentification des e-mails : vérifiez régulièrement les enregistrements DMARC, SPF, DKIM, MTA-STS, TLS-RPT et BIMI afin de détecter les références inactives ou incorrectes
• Responsabilité des documents : tenez un inventaire des domaines, sous-domaines, expéditeurs et responsables de service, en indiquant un responsable pour chaque entrée
• Intégrer le nettoyage du DNS dans la procédure de mise hors service : faire de la suppression des enregistrements une étape obligatoire chaque fois qu'un service cloud, une plateforme SaaS ou un compte d'hébergement est mis hors service
• Configurer des alertes automatiques : surveillez les services orphelins, les dérives DNS et l'apparition de nouveaux sous-domaines dans votre zone
• Réalisez des audits de sécurité récurrents : tous les mois ou tous les trimestres selon la complexité, et immédiatement après toute migration, tout changement de fournisseur ou toute acquisition de domaine

Que faire des sous-domaines anciens ou inutilisés ?

Lorsqu'un sous-domaine n'est plus nécessaire, la décision prise aboutit généralement à l'une des cinq issues suivantes.

• Supprimer l'enregistrement lorsque le sous-domaine n'a plus de justification commerciale
• Récupérer la ressource externe abandonnée lorsque le sous-domaine doit rester actif et que le compte peut encore être réclamé
• Parquez en toute sécurité en le redirigeant vers une ressource interne contrôlée, jamais vers une plateforme externe, lorsqu'il doit effectuer une résolution mais ne servir aucun contenu
• Rediriger uniquement lorsqu'il existe une raison commerciale justifiant cette redirection, et vérifier que la page de destination appartient bien à l'entreprise et qu'elle est active
• Document Consignez chaque décision et attribuez-en la responsabilité avant de mettre quoi que ce soit hors service

L'aide de PowerDMARC

PowerDMARC centralise la surveillance de l’authentification des domaines et des e-mails afin que les équipes puissent détecter les problèmes liés à DMARC, SPF, DKIM, MTA-STS, TLS-RPT et BIMI sans avoir à vérifier manuellement chaque enregistrement DNS. L’objectif n’est pas de repérer un seul enregistrement erroné, mais de maintenir une visibilité continue sur chaque domaine, sous-domaine et enregistrement d’authentification ayant une incidence sur votre niveau de sécurité.

• Tableau de bord centralisé : domaine, sous-domaine et état d'authentification consultables depuis un seul et même endroit
• Détection rapide des problèmes : les erreurs de configuration sont identifiées avant qu’elles n’affectent la sécurité ou la délivrabilité
• Gestion automatisée de l'SPF : moins d'échecs de recherche et des sources d'envoi plus propres à mesure que les plateformes SaaS évoluent
• Préparation à la conformité : accompagnement à la préparation des audits pour les équipes des secteurs de la finance, de la santé, de l'éducation, du commerce de détail et du secteur public
• Assistance d'experts : une assistance mondiale pour vous aider à analyser, valider et corriger rapidement un enregistrement à risque

Pour les prestataires de services, le regroupement centralisé des domaines et l'accès basé sur les rôles permettent de surveiller facilement plusieurs environnements clients à la fois. Les programmes MSP et MSSP s'articule autour de ce flux de travail.

Si vous souhaitez avoir un aperçu rapide de votre situation actuelle, vérifiez votre domaine à l'aide de l'analyseur gratuit. Saisissez votre domaine, cliquez sur « Vérifier maintenant », et vous pourrez consulter la configuration de vos enregistrements DNS, les erreurs de configuration détectées, ainsi que des conseils pratiques pour y remédier.

Foire aux questions

Celles-ci traitent des questions opérationnelles qui se posent une fois que le concept est bien défini.

Comment corriger les enregistrements DNS orphelins ?

Identifiez l'enregistrement obsolète, vérifiez si votre organisation est toujours propriétaire de la cible, puis réduisez la durée de vie (TTL). Récupérez d'abord la ressource si elle peut l'être, supprimez l'enregistrement ou modifiez son point de référence, validez la propagation à l'aide de la commande « dig », puis consignez la modification.

Qu'est-ce qu'un nom d'hôte « dangling » ?

Un sous-domaine qui pointe vers une destination qui n'est plus contrôlée par le propriétaire du domaine. C'est l'enregistrement DNS « orphelin » qui en est à l'origine. Si dev.example.com pointe vers un compte cloud désactivé, il s'agit d'un nom d'hôte « orphelin ».

Les enregistrements DNS « en suspens » peuvent-ils avoir une incidence sur la sécurité des e-mails ?

Oui. Les enregistrements DMARC ( SPF), DKIM, MTA-STS et TLS-RPT deviennent tous « orphelins » lorsqu’ils font référence à des domaines inactifs, à des expéditeurs obsolètes ou à des boîtes aux lettres de rapport non surveillées. Il en résulte des échecs d’authentification et des lacunes de visibilité qui passent inaperçues.

À quelle fréquence les entreprises devraient-elles vérifier leurs enregistrements DNS ?

Après chaque mise hors service d'un service, migration de fournisseur, acquisition de domaine ou changement d'expéditeur. Prévoyez des audits récurrents, mensuels ou trimestriels selon la complexité, ainsi qu'une surveillance continue afin de détecter tout écart entre ces audits.

Un enregistrement en suspens signifie-t-il systématiquement qu'un sous-domaine peut être détourné ?

Non. Pour qu’une prise de contrôle soit possible, la ressource cible doit pouvoir être revendiquée par un tiers, ce qui est courant avec les compartiments de stockage cloud, les points de terminaison CDN et les sous-domaines SaaS. Un enregistrement pointant vers une adresse IP inactive entraîne toujours des interruptions de service et un risque d’interception.

À qui devrait-il incomber, en interne, de procéder au nettoyage des enregistrements DNS ?

C'est à la personne responsable de la mise hors service du service qu'il incombe de s'en charger, et non à l'administrateur DNS seul. Les enregistrements deviennent obsolètes dès qu'un service est retiré, c'est pourquoi leur suppression doit figurer dans la liste de contrôle de fin de contrat plutôt que dans un audit DNS distinct.

• À propos de
• Derniers messages

Yunes Tarada

Expert en sécurité des domaines et des e-mails chez PowerDMARC

Yunes est chef d'équipe des opérations chez PowerDMARC et possède des connaissances approfondies en matière d'authentification et de sécurité des courriels. Yunes est certifié Microsoft Azure Administrator Associate et possède des certifications CompTIA A+ et bien d'autres encore.

Derniers messages de Yunes Tarada (voir tous)

• Guide de configuration de Happyfox DKIM, DMARC et « SPF » - 13 août 2026
• Qu'est-ce que la politique DMARC Quarantine? p=quarantine ? Explications - 12 août 2026
• Guide de configuration de Twikey SPF, DKIM et DMARC - 11 août 2026