Audit des noms de domaine : qui s’en occupe après le rapport ?

Posez la question en comité de direction : « qui est responsable de nos noms de domaine ? ». Vous aurez un silence, puis trois réponses. L’office manager, qui paie le renouvellement. L’agence, qui a acheté le domaine de la campagne. Le développeur, qui a touché le DNS un jour et qui est parti depuis. Trois personnes, donc personne. C’est pourquoi votre portefeuille de domaines n’a jamais été nettoyé : non par négligence, mais parce que le nettoyage n’est le travail de personne.

Le jour où vous demandez quand même, on vous répond que « le DNS est à jour ». Cette phrase ne dit ni quels domaines ont été regardés, ni ce qui manque, ni qui s’en occupe. Un audit des noms de domaine qui mérite ce nom donne une réponse qu’un dirigeant peut vérifier et redemander six mois plus tard. La méthode tient en deux choses : un inventaire daté, et un propriétaire en face de chaque nom.

Pour la rendre concrète, je reprends la PME fictive de l’article Usurpation par email : votre domaine oublié écrit à vos clients. Son domaine de campagne, campaign.example, ne doit envoyer aucun message. Nous suivons ce seul domaine, d’une configuration nue jusqu’au contrôle suivant. Données illustratives ; évaluations calculées avec le moteur de dns-posture, un outil gratuit et open source que j’ai publié sur npm, documenté sur GitHub, compatible OVHcloud et Cloudflare. Il est destiné à l’équipe technique. Ses rapports sont destinés à vous.

Tout commence par une observation datée. L’équipe relit la configuration chez le fournisseur, et en garde une sauvegarde. Un vieux fichier peut être réanalysé hors ligne, mais il décrit le domaine tel qu’il était, pas tel qu’il est. L’écart entre les deux est l’endroit où les problèmes se cachent.

Pour campaign.example, l’observation est courte : le domaine ne contient qu’une entrée indiquant son serveur DNS. Rien ne déclare qui peut envoyer des messages en son nom, rien ne dit quoi faire de ceux qui l’empruntent. À partir des enregistrements présents, l’outil le classe comme dormant.

Puis vient le moment qu’aucun outil ne fera à votre place, et c’est là que le propriétaire entre en scène. Quelqu’un doit confirmer qu’aucune facture, aucune application, aucune campagne n’utilise ce domaine pour envoyer. Pas supposer : confirmer. Parce que l’erreur inverse coûte cher. Un fournisseur de messagerie inconnu dans la configuration n’est pas un déchet à supprimer, c’est un usage à retrouver, souvent celui d’un outil souscrit sans le dire, comme ces accès qui survivent aux outils. C’est pour cela que dns-posture protège par défaut la messagerie active contre tout durcissement automatique. Un domaine sans propriétaire, c’est un domaine sur lequel personne n’ose répondre à cette question. Donc personne ne touche à rien. Donc rien n’est nettoyé.

dns-posture produit trois sorties : un rapport lisible, un CSV pour le tableur, un JSON pour l’automatisation. On y trouve les domaines, leurs scores, les contrôles en échec, leur gravité et une indication de correction. Le tableau ci-dessous est une lecture simplifiée de deux contrôles, pas une capture d’écran.

Contrôle sur campaign.example	Première observation	Après la correction simulée
Règle sur les serveurs autorisés à envoyer, SPF	Absente (spf.present: fail)	Présente, aucun envoi autorisé (pass)
Consigne de rejet des messages non authentifiés, DMARC	Absente (dmarc.reject: fail)	Rejet demandé (pass)

Dans cet exemple minimal, le score du référentiel 1.1.0 passe de 45/100 à 85/100 après l’ajout des règles SPF et DMARC décrites dans la documentation de l’exemple. Attention à ce chiffre. Il compte des contrôles de configuration satisfaits. Il ne dit pas que 85 % des attaques sont bloquées, ni que vous êtes « sûr à 85 % ». D’autres contrôles restent en échec et se lisent un par un.

Ce que vous pouvez retenir, et redemander dans six mois, tient en une ligne : l’interdiction d’envoi est déclarée sur le domaine de campagne, la preuve est archivée, et chaque écart restant a un nom en face de lui. C’est ce dernier point qui change tout. Un rapport sans responsable est une photo. Un rapport avec un responsable est une liste de tâches.

La peur qui empêche de nettoyer est légitime : on ne sait plus ce qui dépend de quoi, donc on ne touche à rien. La réponse n’est pas le courage, c’est la procédure. Un plan d’abord : quels enregistrements sont concernés, lesquels doivent être conservés. L’application exige une demande explicite, une sauvegarde de l’état courant, et une relecture finale chez le fournisseur. À la première erreur, les écritures s’arrêtent sur le domaine concerné. Les sous-domaines délégués et les redirections existantes ont leurs garde-fous, pour qu’une correction locale ne coupe pas un service dont personne ne se souvenait.

Pour une messagerie qui envoie réellement, le travail est d’une autre nature : identifier les expéditeurs légitimes, configurer les services concernés, dont la signature des messages. L’outil ne transforme pas tout seul un domaine actif en domaine muet. Il n’est pas non plus un service qui surveille ce que reçoivent vos clients.

La relecture finale confirme un état chez votre fournisseur DNS. Elle ne prouve pas que tous les destinataires appliquent déjà la nouvelle règle : la propagation et le traitement des courriels se passent ailleurs.

Une semaine plus tard, un prestataire intervient sur la campagne. Il modifie quelque chose dans la zone, il repart. Dans la suite fictive de notre exemple, la règle DMARC a disparu. Personne ne l’a fait exprès. Personne ne s’en est aperçu non plus : un audit réussi vieillit à la vitesse de votre dernier prestataire.

Un contrôle périodique qui relit le fournisseur retrouve l’échec. Réévaluer la sauvegarde de la semaine précédente aurait affiché le même rapport qu’avant, devenu trompeur sur l’état actuel. L’organisation est modeste : une tâche planifiée relit les domaines, produit les rapports, archive chaque résultat avec sa date. Le CSV sert à la revue humaine. Le JSON permet à un petit script de comparer avec la période précédente et d’envoyer une notification quand un contrôle bascule. dns-posture n’a ni ordonnanceur ni envoi d’alertes intégré : c’est l’équipe qui monte cette planification autour de lui, et qui la branche sur le reste du monitoring et des alertes de production.

La fréquence hebdomadaire est un choix d’organisation, pas une règle de l’ANSSI. Ajoutez un contrôle après chaque intervention d’un tiers. Et une exigence que les équipes oublient : si la lecture échoue, le suivi doit dire « aucune observation récente », pas réafficher l’ancien rapport. Un silence qui ressemble à un succès est pire qu’une alerte.

Cette surveillance porte sur la configuration. Les rapports DMARC que vous envoient les opérateurs de messagerie parlent d’autre chose, des messages qu’ils ont réellement traités. dns-posture ne les collecte pas et ne les analyse pas.

Ce que la PME obtient, ce n’est pas un DNS propre. C’est un suivi qu’elle peut exiger à nouveau : un périmètre connu, une observation datée, des écarts précis, un responsable par écart, une vérification rejouée après chaque correction. La règle qui disparaît devient un point à traiter, au lieu de rester cachée derrière le souvenir d’un audit réussi.

L’outil n’est pas né d’une théorie. Il s’appuie sur des journaux conservés : 61 domaines sauvegardés, 51 domaines distincts avec une application rapportée sans erreur, 138 suppressions et 147 créations enregistrées. Ces journaux ne prouvent ni attaques évitées ni temps gagné. Ils disent seulement qu’on écrit et qu’on supprime beaucoup quand on nettoie, d’où le travail sur la sauvegarde, les garde-fous et la relecture.

Si vous ne faites qu’une chose après cet article, ne faites pas l’audit. Nommez le propriétaire. L’audit suivra, parce que quelqu’un aura désormais une raison de le demander. Sans responsable, le rapport de cette année rejoindra celui de l’année dernière, et personne ne saura ce qui a changé entre les deux.

Le guide du risque d’usurpation replace ces contrôles dans les recommandations de l’ANSSI. L’équipe trouvera l’outil sur npm et l’exemple reproductible de rapport et de suivi périodique sur GitHub.