Un enregistrement DNS orphelin (dangling DNS record) est un enregistrement A, AAAA, CNAME, MX ou NS qui se résout toujours, mais qui pointe vers une ressource cloud, une adresse IP ou un serveur de noms qui n'existe plus : un bucket de stockage supprimé, une IP de serveur libérée, un compte SaaS fermé. Si un attaquant parvient à revendiquer cette même ressource sur son propre compte, il peut diffuser son propre contenu sur votre sous-domaine. C'est ce qu'on appelle une prise de contrôle de sous-domaine (subdomain takeover), et c'est l'une des façons les plus discrètes pour un domaine de confiance de se retrouver à héberger la page de phishing ou le malware de quelqu'un d'autre. La solution consiste à supprimer ou à rediriger un enregistrement DNS dès que la ressource qui se trouve derrière est mise hors service, et à auditer régulièrement le reste de la zone pour repérer les enregistrements que personne ne se souvient avoir créés. Le Mois de la cybersensibilisation remettant l'examen de la surface d'attaque sur toutes les listes de tâches, un audit de zone est l'une des actions les plus rentables et les moins coûteuses en effort que vous puissiez mener ce mois-ci.
Qu'est-ce qu'un enregistrement DNS orphelin ?
Le terme n'est défini dans aucune RFC : c'est un raccourci opérationnel désignant un enregistrement dont la cible a discrètement disparu. L'entrée DNS elle-même est parfaitement valide et répond toujours aux requêtes ; ce qui manque, c'est l'élément vers lequel elle pointait. Quatre schémas expliquent la quasi-totalité des cas :
- Un CNAME fait toujours d'un nom d'hôte un alias vers un point de terminaison de service cloud (un bucket S3, une distribution CDN, une application PaaS) qui a été supprimé.
- Un enregistrement A/AAAA pointe toujours vers une adresse IP qui a été restituée au pool d'un fournisseur cloud.
- Une délégation NS pointe toujours la zone d'un sous-domaine vers des serveurs de noms appartenant à un compte fournisseur qui a été fermé.
- Un enregistrement MX achemine toujours le courrier vers une plateforme de messagerie que l'équipe n'utilise plus.
Aucun de ces cas n'est une erreur de protocole. Le DNS ne sait pas, et ne se soucie pas, que l'élément à l'autre bout a disparu : il continue simplement de répondre. C'est précisément ce qui rend les enregistrements orphelins invisibles tant que personne ne vérifie.
Comment fonctionne concrètement un subdomain takeover
De nombreuses plateformes cloud et SaaS permettent à un client de revendiquer une ressource par son nom (un nom de bucket, un slug d'application, un alias de distribution), et ce nom devient disponible pour n'importe qui dès que son propriétaire d'origine le supprime. Si votre DNS contient toujours un CNAME pointant vers old-bucket.s3-website-us-east-1.amazonaws.com et que plus personne dans votre entreprise ne possède ce bucket, un attaquant peut créer un nouveau bucket portant exactement le même nom, y téléverser sa propre page, et votre sous-domaine la diffusera, avec en prime un certificat TLS valide s'il en demande un auprès d'un fournisseur qui ne vérifie pas la propriété du domaine par rapport à vos enregistrements.
asuid.<subdomain>) sont bien plus difficiles à exploiter de cette manière, mais de nombreux services plus anciens ou plus modestes ne le font toujours pas.
Les services les plus souvent en cause
| Service | L'enregistrement orphelin pointe vers | Signal typique de ressource « non revendiquée » |
|---|---|---|
| Site statique AWS S3 | CNAME vers bucket.s3-website-region.amazonaws.com |
Erreur XML NoSuchBucket |
| AWS CloudFront | CNAME vers *.cloudfront.net |
"The request could not be satisfied" |
| GitHub Pages | CNAME vers username.github.io |
"There isn't a GitHub Pages site here" |
| Heroku | CNAME vers *.herokuapp.com |
"No such app" |
| Azure App Service | CNAME vers *.azurewebsites.net |
"404 Web Site not found" |
Cette liste n'est pas exhaustive : Fastly, Shopify, Zendesk, Surge.sh et plusieurs autres plateformes ont figuré dans ce même catalogue à différents moments. Le schéma est toujours le même : une page d'erreur conviviale confirmant que le nom est libre, derrière un enregistrement DNS que vous contrôlez toujours.
Comment auditer votre zone DNS pour trouver les enregistrements orphelins
Commencez par exporter tous les enregistrements de la zone et par résoudre la chaîne de chaque nom d'hôte. Pour les CNAME, suivez la cible et regardez ce qui répond :
$ dig CNAME status.example.com +short
old-bucket.s3-website-us-east-1.amazonaws.com.
$ curl -s https://status.example.com
<Error><Code>NoSuchBucket</Code><Message>The specified bucket does not exist</Message></Error>
Un simple NXDOMAIN sur la cible, ou une page d'erreur « non revendiquée » propre au fournisseur comme celle ci-dessus, signifie dans les deux cas que la ressource a disparu et que le nom est peut-être libre d'être revendiqué. Notre outil de recherche DNS gratuit permet de récupérer rapidement les enregistrements A, CNAME, MX et NS d'un nom d'hôte sans ouvrir de terminal, ce qui est pratique lorsque vous vérifiez à la main une longue liste de sous-domaines.
Au-delà de quelques sous-domaines, automatisez la démarche avec un script : énumérez les sous-domaines (à partir de votre propre inventaire, des journaux Certificate Transparency ou d'une liste de mots de sous-domaines), résolvez chacun d'eux et signalez tout CNAME dont la cible ne se résout pas ou renvoie une empreinte « non revendiquée » connue. Des outils open source comme Subjack, tko-subs, dnsReaper et les templates subdomain-takeover de Nuclei automatisent exactement ce processus à partir de bases d'empreintes publiques.
TipNe vous fiez pas à votre mémoire pour savoir ce qui est « encore utilisé ». Croisez l'export de la zone avec les ressources cloud réellement provisionnées : tout ce qui figure dans le DNS sans ressource active correspondante est candidat à la suppression, aussi ancien ou inoffensif qu'il paraisse.
Supprimer un enregistrement DNS orphelin en toute sécurité
Une fois que vous avez confirmé qu'un enregistrement est orphelin, supprimez-le : n'essayez pas de le « réparer » en ajoutant un autre type d'enregistrement sur le même nom. La RFC 1034 indique explicitement qu'un nom portant un CNAME ne doit comporter aucun autre type d'enregistrement ; vous ne pouvez donc pas superposer un enregistrement A sans supprimer d'abord le CNAME. Si vous n'êtes pas prêt à le supprimer purement et simplement, redirigez-le vers une ressource que vous contrôlez (une page de parking ou un serveur qui vous appartient) plutôt que de le laisser pointer vers le vide.
WarningAvant de le supprimer, vérifiez si l'enregistrement sert aussi de preuve de propriété du domaine (un enregistrement de vérification TXT ou CNAME pour la plateforme que vous quittez). Supprimer trop tôt un enregistrement de vérification peut casser une migration en cours au lieu de la clôturer.
Prise de contrôle via délégation NS : un tout autre problème
Une délégation NS orpheline est un cas distinct et plus grave : elle survient lorsque la zone d'un sous-domaine est déléguée à des serveurs de noms gérés par un compte tiers (un hébergeur DNS, un CDN, un outil de développement) qui a depuis été fermé, et que les noms de ces serveurs de noms deviennent disponibles à l'enregistrement par quelqu'un d'autre. Quiconque contrôle ces noms de serveurs de noms contrôle alors le DNS de tout le sous-domaine, et pas seulement d'un enregistrement. Auditez les délégations NS de la même manière : résolvez chaque nom d'hôte de serveur de noms et vérifiez qu'il appartient toujours à un compte que vous exploitez. Si vous gérez toutes vos zones depuis un seul endroit, c'est beaucoup plus simple à suivre ; découvrez comment une gestion DNS centralisée traite les délégations aux côtés des enregistrements ordinaires.
Intégrer la suppression à la mise hors service, et non après coup
La vraie solution n'est pas un audit ponctuel, c'est un processus. Supprimez ou redirigez l'enregistrement DNS au moment même où vous mettez hors service la ressource qui se trouve derrière, en tant qu'étape obligatoire de la checklist de démantèlement, et non comme un ticket de suivi qui risque de ne jamais être créé. Associez cela à un inventaire d'infrastructure à jour pour que chaque enregistrement ait un propriétaire connu et actif, et envisagez la détection de dérive afin qu'un enregistrement qui devient orphelin soit signalé automatiquement au lieu d'attendre le prochain audit manuel.
Menez cet audit de façon régulière, pas une seule fois. De nouveaux enregistrements orphelins apparaissent chaque fois qu'un projet est abandonné, qu'un compte d'essai expire ou qu'une équipe quitte une plateforme : c'est une tâche de maintenance continue, pas un projet avec une date de fin.
Commencez par analyser gratuitement votre propre zone avec l'outil de recherche DNS, puis intégrez les suppressions à chaque checklist de mise hors service.
Questions fréquentes
#Un enregistrement A orphelin peut-il provoquer une prise de contrôle de sous-domaine, ou seulement les CNAME ?
Les CNAME pointant vers des points de terminaison cloud/SaaS sont le cas classique, car le nom cible lui-même peut redevenir revendicable, mais un enregistrement A orphelin pointant vers une IP cloud libérée peut aussi être exploité si cette même IP est réattribuée à quelqu'un d'autre qui y fait tourner un service.
#La suppression d'un enregistrement orphelin risque-t-elle de casser quelque chose ?
Si vous avez confirmé que la ressource vers laquelle il pointe n'existe plus, la suppression de l'enregistrement ne perturbera aucun trafic actif : il échouait déjà ou ne servait rien d'utile. Vérifiez d'abord que l'enregistrement ne sert pas également d'entrée de vérification de propriété du domaine pour une migration encore en cours.
#À quelle fréquence faut-il auditer sa zone DNS pour trouver les enregistrements orphelins ?
Faites un audit après chaque mise hors service (arrêt d'une application, démantèlement d'un serveur, résiliation d'un SaaS) et selon un calendrier récurrent, par exemple trimestriel, car les enregistrements sont faciles à oublier entre deux revues planifiées.
#Un certificat TLS valide signifie-t-il qu'un sous-domaine est sûr ?
Non : si un attaquant parvient à revendiquer une ressource orpheline, de nombreuses autorités de certification lui délivreront un certificat pour votre sous-domaine, car la validation du contrôle de domaine vérifie l'enregistrement DNS que vous avez laissé en place, et non l'identité de la personne qui a créé le projet à l'origine.
Essayez avec un outil gratuit
Cet article vous a-t-il été utile ?
