Chargement de Smiley Hoster
Aller au contenu

Prévenir le subdomain takeover : auditer et nettoyer les DNS abandonnés

Équipe Smiley Hoster · · 4 min de lecture
Un inventaire DNS montre une branche active et une branche abandonnée à retirer.

Une campagne est terminée et son application SaaS supprimée, mais promo.example.com pointe toujours vers elle. Selon le fonctionnement du fournisseur, cette référence abandonnée peut exposer votre sous-domaine à une reprise par un tiers. Le guide Microsoft sur le dangling DNS donne un point de départ défensif.

Intention de recherche : repérer et retirer les dépendances DNS abandonnées sur vos domaines. Les exemples sont fictifs ; n’essayez jamais de revendiquer une ressource tierce pour « prouver » le risque.

1. Construire un inventaire et confirmer les anomalies

Exportez vos zones et rapprochez-les des comptes cloud, SaaS et déploiements. Pour chaque sous-domaine, notez propriétaire interne, service, compte fournisseur, cible, TTL et date de fin prévue. Incluez les délégations NS, MX et adresses d’anciens services, pas seulement les CNAME.

Un exemple de dépendance à examiner :

Exemple
promo.example.com. 300 IN CNAME old.example.net.

Interrogez le nom puis sa cible, en remplaçant ces valeurs par les vôtres :

Exemple
dig promo.example.com CNAME +noall +answerdig old.example.net Adig old.example.net AAAAhost promo.example.comnslookup promo.example.com 1.1.1.1

La première réponse expose l’alias et son TTL. Un NXDOMAIN sur la cible est un signal d’enquête, pas une preuve que quelqu’un peut la reprendre. Certains services retirés continuent de résoudre ; une page « application introuvable » n’est pas non plus une preuve suffisante.

Vérifiez la ressource et l’association du domaine dans votre propre console fournisseur. Demandez confirmation au propriétaire interne. Un historique de certificats peut compléter l’inventaire, mais il ne prouve pas le contrôle actuel et ne remplace pas l’export DNS.

2. Retirer la référence avant de libérer la ressource

Risque : supprimer un alias encore utilisé peut casser une campagne, un webhook, une connexion OAuth ou un service mail. Conservez l’export et vérifiez les dépendances applicatives avant la modification.

  1. Classez chaque anomalie : service actif, retrait confirmé ou propriétaire inconnu. Pour ce dernier, attribuez une investigation plutôt qu’une suppression automatique.
  2. Si la ressource existe encore et doit disparaître, retirez ou remplacez d’abord sa référence DNS. Maintenez la ressource sous votre contrôle pendant la durée pertinente des caches avant de la libérer.
  3. Si la cible est déjà abandonnée, retirez l’entrée confirmée obsolète. Ne recréez pas une ressource sur un compte qui n’est pas le vôtre. Pour conserver le nom, pointez-le vers une destination maîtrisée, avec certificat et réponse applicative prévus.
  4. Retirez les références dans les applications, liens, listes CORS et URL de rappel. Si une reprise est suspectée, préservez les traces et examinez l’exposition de cookies ou de secrets avec votre procédure d’incident.
  5. Ajoutez le retrait DNS à la procédure de décommissionnement. Programmez une revue régulière et des alertes sur les changements de cible ou de propriétaire.

Retour arrière

Si le nettoyage coupe un service légitime, restaurez uniquement une destination dont vous avez confirmé le contrôle et l’association du domaine. Ne remettez jamais aveuglément un CNAME vers une ressource libérée. Une restauration DNS reste soumise aux caches.

3. Vérification finale

Exemple
dig @ns1.example.net promo.example.com CNAMEdig @1.1.1.1 promo.example.com CNAME

Remplacez le NS par votre autoritatif. L’ancien CNAME doit avoir disparu, ou être remplacé par la cible approuvée. L’absence peut apparaître comme NXDOMAIN ou comme une réponse vide selon les autres enregistrements et wildcards. Contrôlez aussi le service depuis un autre réseau.

Erreurs courantes

Un certificat HTTPS ne prouve pas que la ressource appartient encore à votre organisation. Ne supprimez pas les jetons TXT de vérification sans connaître leur rôle protecteur chez le fournisseur. Ne confondez pas une panne temporaire avec un abandon, et ne considérez pas un scan ponctuel comme une surveillance durable.

Sources : Microsoft, prévention des DNS abandonnés, ISC, inspection DNS avec BIND.

Slide 1 of 6: Domains and DNS. Retired service. Lingering DNS.. Leftover DNS references may expose a subdomain to takeover. Audit before you delete.
Slide 2 of 6: Confirm ownership. Confirm ownership. Match zone records to provider accounts.. Record each hostname owner, target and TTL.. Check CNAME, NS and MX dependencies.. NXDOMAIN alone does not prove takeover risk.
Slide 3 of 6: Controlled cleanup. Clean up in order. Back up zones; check app dependencies and owners.. Remove DNS first; keep the resource as caches expire.. Remove confirmed stale records for abandoned targets.. Clean links, callbacks and CORS allowlists.
Slide 4 of 6: Safe recovery. Rollback needs verified control. Restore only a destination with verified ownership.. Confirm its custom-domain binding before restoring.. Never restore a CNAME toward a released resource.. Keep the approved replacement available as caches expire.
Slide 5 of 6: Verify and monitor. Verify the cleanup. Check authoritative DNS and a public resolver.. Confirm the old target is gone or replaced.. Test the app from another network; log approvals.. Repeat inventory reviews and monitor target changes.
Slide 6 of 6: Your DNS audit checklist. Retire services. Check DNS.. Save this checklist for your next service shutdown. Explore the full DNS audit guide.
Sur les réseaux sociaux

Retrouvez-le dans nos publications

Les étapes clés de cet article, en carrousel. Suivez-nous pour découvrir les prochaines. Nos publications sont rédigées en anglais.

Cet article a-t-il répondu à votre question ?
Vos retours orientent ce qu'on écrit ensuite.

Votre site en ligne aujourd'hui

Migration gratuite* · remboursé 30 jours

Commencer* Un site de moins de 30 Go, offres cPanel, WordPress et VPS.