Sous-domaines orphelins : ce que c'est et comment les trouver avant quelqu'un d'autre

Mis à jour le oct. 2026 · 8 min de lecture

Un sous-domaine orphelin est un sous-domaine dont l'enregistrement DNS pointe encore vers un service, un serveur ou une IP que vous n'utilisez plus. Si quelqu'un d'autre peut récupérer cette cible, il peut diffuser du contenu sous le domaine de votre client (on parle de détournement de sous-domaine, ou subdomain takeover). La solution : recenser les sous-domaines, vérifier chaque cible, supprimer les enregistrements inutiles.

La plupart des agences gèrent des dizaines de domaines clients, et chacun accumule des sous-domaines au fil des ans : préprod, landing pages, centre d'aide, boutique, page de statut, outils marketing. Les services passent, les enregistrements DNS restent.

Pour une agence, le problème tient à l'endroit où le risque se trouve : hors de vue. Le site principal fonctionne, le client ne remarque rien, et l'enregistrement oublié date souvent d'un projet ou d'un prestataire que plus personne ne suit. Si un inconnu s'en sert, c'est le nom du client qui est exposé, et c'est l'agence qu'on appellera pour comprendre ce qui s'est passé.

Ce guide explique comment cela arrive, comment repérer les sous-domaines orphelins et comment éviter que de nouveaux apparaissent. Un domaine expiré est l'autre façon de perdre le contrôle du nom d'un client : voir ce qui se passe quand un nom de domaine expire.

Comment un sous-domaine devient-il orphelin ?

Le scénario type :

  1. 1Un sous-domaine est créé pour un usage précis, par exemple aide.exemple.fr pour un helpdesk hébergé, ou promo.exemple.fr pour un outil de landing pages.
  2. 2Un enregistrement DNS est ajouté, en général un CNAME qui pointe vers le prestataire (du type exemple.helpdesk-provider.com).
  3. 3Des mois ou des années plus tard, le compte chez le prestataire est fermé, l'essai se termine ou le projet est abandonné.
  4. 4Personne ne supprime l'enregistrement DNS.

Le sous-domaine existe toujours dans le DNS, mais sa cible a disparu. Parfois le nom d'hôte cible ne se résout plus du tout (réponse NXDOMAIN). Parfois il affiche la page générique « cette page n'existe pas » du prestataire.

La même chose arrive avec des enregistrements A qui pointent vers l'IP d'un serveur cloud éteint. L'IP retourne dans le stock du fournisseur et peut plus tard être attribuée à quelqu'un d'autre.

Pourquoi un sous-domaine orphelin pose-t-il problème ?

Sur beaucoup de services hébergés, on « revendique » un domaine personnalisé en l'ajoutant dans son compte et en faisant pointer un CNAME vers le prestataire. Si le compte d'origine n'existe plus, quelqu'un d'autre peut parfois créer un nouveau compte, revendiquer le même sous-domaine et y afficher ce qu'il veut.

C'est un détournement de sous-domaine. L'attaquant n'a pas besoin d'accéder à votre DNS : l'enregistrement oublié fait le travail pour lui.

Ce qu'on peut faire d'un sous-domaine détourné :

  • des pages de phishing sous un vrai domaine client, bien plus crédibles qu'un domaine ressemblant ;
  • du contenu malveillant ou gênant affiché à quiconque suit l'ancien lien ;
  • des risques sur les cookies et les sessions, si le site principal pose des cookies valables pour le domaine parent ;
  • une atteinte à la réputation du client, et des questions embarrassantes pour l'agence qui avait fait la configuration.

Tous les enregistrements orphelins ne sont pas exploitables. Cela dépend du prestataire et de la façon dont il vérifie la propriété du domaine. Mais on sait rarement dans quel cas on se trouve sans vérifier, et la correction est presque toujours la même : supprimer l'enregistrement.

Est-ce un vrai risque pour les agences ?

Oui, et c'est l'agence qui le porte, même quand le domaine est au nom du client : quand quelque chose cloche sur un domaine client, le client appelle l'agence qui l'a mis en place. C'est l'une des questions de qui doit être propriétaire du domaine d'un client.

Ce n'est pas théorique. Lors de mini-audits menés sur 57 sites d'agences à partir de données publiques uniquement, nous avons trouvé un sous-domaine client dont le CNAME pointait vers une cible de service cloud qui ne se résout plus (NXDOMAIN). C'était un cas unique dans cet échantillon. Comme la plupart des enregistrements orphelins, il était invisible depuis le site principal et n'apparaissait que si l'on allait le chercher.
Source : mini-audits Lapsentry, 57 agences, données publiques uniquement.

Comment trouver les sous-domaines orphelins ?

Dresser la liste des sous-domaines

On ne peut pas vérifier ce dont on ignore l'existence. Croisez plusieurs sources :

  • La zone DNS elle-même. Exportez-la depuis le registrar ou l'hébergeur DNS (Cloudflare, OVH, Gandi, Route 53, etc.). C'est la source la plus complète si vous y avez accès.
  • Les journaux Certificate Transparency. Tout certificat SSL reconnu publiquement y est consigné, y compris ceux qui ne se renouvellent plus quand un service est abandonné. Une recherche sur un outil comme crt.sh révèle souvent des sous-domaines oubliés, dont certains n'ont existé que pour un ancien projet.
  • Les enregistrements e-mail. Les enregistrements de vérification, mta-sts ou de services d'envoi oubliés montrent quels prestataires ont été utilisés ; voir SPF, DKIM et DMARC.
  • Vos propres archives. Anciens documents de projet, notes de passation, factures d'outils SaaS qui demandaient un domaine personnalisé.

Vérifier où pointe chaque enregistrement

Pour chaque sous-domaine, consultez ses enregistrements, puis vérifiez que la cible elle-même se résout encore :

dig +short CNAME aide.exemple.fr
dig +short A aide.exemple.fr
dig +short <cible>

Puis, pour chacun, posez-vous ces questions :

  • La cible du CNAME se résout-elle encore ? Si dig sur la cible ne renvoie rien ou NXDOMAIN, c'est un signal d'alerte.
  • Le service est-il toujours utilisé, et le compte est-il toujours le vôtre ? Une cible qui se résout peut quand même être orpheline si le compte derrière est fermé.
  • L'IP de l'enregistrement A appartient-elle encore à un serveur que vous contrôlez ? Si le serveur a été décommissionné, l'IP est peut-être désormais à quelqu'un d'autre.
  • Qu'affiche le sous-domaine dans un navigateur ? Les pages d'erreur de prestataire comme « no such app », « site not found » ou « repository not found » sont des signes classiques.

Prioriser

Traitez d'abord :

  • les CNAME dont la cible renvoie NXDOMAIN ;
  • les sous-domaines qui affichent une page « introuvable » ou « non revendiqué » d'un prestataire ;
  • les sous-domaines des domaines les plus sensibles (marque principale, e-commerce, tout ce qui gère des connexions).

Comment corriger un sous-domaine orphelin ?

  • Si le service n'est plus utilisé, supprimez l'enregistrement DNS. C'est la solution la plus propre.
  • S'il est encore nécessaire, revendiquez à nouveau le domaine personnalisé dans le compte du prestataire et vérifiez qu'il affiche le bon contenu.
  • Pour les enregistrements A vers des serveurs retirés, supprimez-les ou faites-les pointer vers une infrastructure que vous contrôlez.

Comment éviter que de nouveaux orphelins apparaissent ?

Un nettoyage ponctuel aide. Rester propre demande un processus :

  • Intégrez le DNS à la fin de contrat. Quand un client résilie un outil ou qu'un projet se termine, la suppression des enregistrements associés figure dans la check-list, à côté de la résiliation de l'abonnement.
  • Tenez un inventaire simple par client : sous-domaine, usage, prestataire, titulaire du compte.
  • Utilisez un seul hébergeur DNS par client quand c'est possible, pour qu'aucun enregistrement ne se cache dans une zone oubliée.
  • Passez les sous-domaines en revue régulièrement, par exemple lors de la maintenance trimestrielle ou à chaque passation.
  • Surveillez les changements. Un enregistrement qui se met à renvoyer NXDOMAIN, ou un nouveau sous-domaine qui apparaît dans les journaux de certificats, mérite une alerte plutôt qu'une découverte annuelle.

Check-list rapide

  • Exporter la zone DNS de chaque domaine client
  • Chercher des sous-domaines supplémentaires dans les journaux Certificate Transparency
  • Vérifier que chaque cible de CNAME se résout encore
  • Confirmer que chaque compte de service ciblé existe toujours et vous appartient
  • Supprimer les enregistrements des services qui ne sont plus utilisés
  • Ajouter « supprimer les enregistrements DNS » à la check-list de fin de contrat
  • Mettre en place une surveillance continue

Comment Lapsentry vous aide

Lapsentry surveille le DNS, les certificats SSL et les dates d'expiration des domaines des sites que vous gérez, pour que les changements et les problèmes à venir vous parviennent avant que votre client ne les remarque. Pour voir où en sont vos domaines aujourd'hui, commencez par le scan gratuit, ou consultez les offres sur la page tarifs.

FAQ

Qu'est-ce qu'un enregistrement DNS orphelin (dangling DNS record) ?

C'est un enregistrement DNS, le plus souvent un CNAME et parfois un enregistrement A, qui pointe encore vers un service, un serveur ou une adresse IP qui n'est plus utilisé. L'enregistrement reste dans votre zone, mais ce vers quoi il pointait a disparu : il ne mène nulle part, ou vers une ressource que quelqu'un d'autre pourrait revendiquer.

Tous les sous-domaines orphelins peuvent-ils être détournés ?

Non. Cela dépend du prestataire et de la façon dont il vérifie qui possède un domaine personnalisé. Certains laissent n'importe qui revendiquer un nom qui n'est rattaché à aucun compte, d'autres non. On sait rarement dans quel cas on se trouve sans vérifier : supprimer l'enregistrement reste donc la solution.

Comment lister tous les sous-domaines d'un domaine ?

Croisez la zone DNS, exportée depuis le registrar ou l'hébergeur DNS, avec les journaux Certificate Transparency consultés via un outil comme crt.sh. La zone est la source la plus complète, et les journaux révèlent les sous-domaines oubliés.

Faut-il supprimer un enregistrement DNS si je ne suis pas sûr qu'il serve ?

Vérifiez d'abord dans le compte du prestataire vers lequel il pointe. Si le service n'est plus utilisé, supprimez l'enregistrement. S'il est encore nécessaire, revendiquez à nouveau le domaine personnalisé dans ce compte et vérifiez qu'il affiche le bon contenu.

Vous créez une intégration ?L'API REST, les webhooks et le serveur MCP sont documentés séparément.Ouvrir la documentation