Gouvernance DNS : les quatre façons dont les patrimoines DNS échouent

La plupart des patrimoines DNS ne sont pas gérés. Ils s’accumulent. Des enregistrements sont créés pour de bonnes raisons, les projets qui les ont justifiés prennent fin, et rien ne fait la réconciliation entre ce qui est publié et ce qui est encore réel. Celui ou celle qui hérite du patrimoine hérite aussi de toutes les décisions prises par des personnes qui sont désormais parties, généralement sans documentation et sans moyen de savoir quels enregistrements sont encore importants.

Cette accumulation échoue de quatre manières spécifiques, chacune ayant une cause différente, un coût différent, et une façon différente d’être détectée.

Chacune de ces situations commence de la même manière. Quelqu’un crée un enregistrement pour une bonne raison, le projet pour lequel il a été fait se termine, et rien ne réconcilie l’enregistrement avec la réalité par la suite.

La plupart des patrimoines DNS fonctionnent comme un placard jamais ouvert. Tout y est, la porte se ferme, et tant que les mails passent et que le site web s’affiche, personne n’a de raison d’aller voir. Puis un jour, quelqu’un a besoin de quelque chose de précis, ouvre la porte et découvre ce qui s’est accumulé dedans.

Pendant des années cela a suffi, car rien ne disait le contraire. Les cadres d’analyse de la cybersécurité étaient construits sur les résultats, pas sur les mécanismes. NIST CSF demande si vous gérez vos actifs. NCSC CAF demande si vous comprenez vos systèmes. Aucun ne cite les enregistrements DNS comme une catégorie d’actifs nécessitant une hygiène propre, donc la gouvernance DNS restait une discipline non écrite que seuls les bons élèves appliquaient, les autres reportant à plus tard.

Cela a changé en trois ans et quatre documents, la plupart européens. L’UE a écrit des exigences techniques détaillées pour les organisations gérant des infrastructures DNS, ENISA les a traduites en recommandations implémentables avec des exemples de preuves, et NIST a révisé son guide de déploiement DNS pour la première fois depuis 2013. Ensemble, ils ont fait passer l’hygiène DNS de bonne pratique implicite à élément pouvant être exigé comme preuve.

Ce guide couvre ce que ces textes exigent réellement, à qui ils s’appliquent, les quatre causes d’échec des patrimoines DNS dans la pratique, et un modèle en cinq étapes pour gouverner un patrimoine impossible à cartographier complètement. Il s’adresse aux équipes qui héritent de grands portefeuilles de domaines auprès de plusieurs registrars et fournisseurs, sans jamais avoir construit elles-mêmes le patrimoine dont elles sont désormais responsables.

Deux des quatre modes d’échec ont déjà été traités en détail, et ce guide y renvoie plutôt que de tout répéter. Commencez par dangling DNS : comment le détecter et le corriger avant la prise de contrôle pour l’avis d’OWASP et AWS sur les enregistrements pointant vers des ressources cloud supprimées, et comment les transferts de zone ouverts exposent votre réseau interne pour voir ce que deux vraies zones ont rendu en une seule requête.

Deux points méritent d’être soulignés dans cette séquence. Le premier est le sens du mouvement. En 2022, l’UE pose une obligation. En 2024, elle en précise les exigences techniques. En 2025, l’ENISA publie à quoi doit ressembler la preuve de conformité. Les régulateurs sont passés de « gérez votre risque » à « voici l’exigence et la preuve attendue ». Le DNS a été explicitement cité à chaque étape.

Le second, c’est que NIST est arrivé indépendamment à des conclusions similaires. SP 800-81r3 n’est pas une réponse à NIS2, c’est une mise à jour US d’un guide vieux de treize ans. Que deux démarches sur des continents différents aboutissent, sur la même période, à l’hygiène DNS, dit quelque chose du problème lui-même plus que du régulateur.

C’est là que la plupart des analyses sur NIS2 et DNS deviennent approximatives, et la différence compte si vous devez décider ce que doit faire votre organisation.

NIS2 est une directive, pas un règlement, elle prend donc effet via la loi de transposition de chaque État membre au lieu de s’appliquer directement et uniformément aux entreprises. Les articles 2 et 3 définissent les 18 secteurs et seuils pour les entités « essentielles » et « importantes », mais il y a des exceptions à ce test, et les États membres peuvent désigner des entités en dehors des tailles. L’article 21 pose des obligations de gestion du risque comme objectif, et le DNS y figure dans la sécurité réseau et la gestion d’actifs, pas comme élément cité nommément. En pratique, tout dépend donc de la transposition nationale : la taille et le secteur sont un début, mais pas une fin.

Le règlement d’exécution 2024/2690 lie une liste précise. Ses exigences s’appliquent aux fournisseurs DNS, registres TLD, prestataires cloud, datacenters, CDN, infogérants, MSSP, marketplaces, moteurs de recherche, plateformes de réseaux sociaux et prestataires de services de confiance. Les registrars ne sont pas explicitement nommés, mais peuvent être concernés via NIS2 par la transposition nationale – base légale distincte, non couverte ici. Si vous êtes une entreprise gérant vos propres domaines, ce règlement ne vous impose pas ses exigences techniques directement. Il impose en revanche probablement des obligations à vos fournisseurs. Le guide technique de l’ENISA est le complément pratique, avec mapping vers les normes européennes et internationales.

NIST SP 800-81r3 est une recommandation volontaire, ouverte à tous. Pas d’application, pas de critère d’éligibilité. C’est une bonne référence technique, au même titre que la loi, les contrats ou les normes sectorielles : c’est précisément le type de document qu’un auditeur ou le questionnaire sécurité d’un client citera, car il s’applique quel que soit le secteur ou la géographie. NIST a publié des potentielles mises à jour et errata en juillet 2026, il est donc conseillé de vérifier la page officielle plutôt qu’une copie locale. Pour creuser ce que contient la révision, de la protection DNS jusqu’au durcissement des serveurs autoritatifs, lisez Ivan Ristic sur le guide DNS sécurisé du NIST plutôt qu’un résumé ici.

Traduction concrète pour la plupart des entreprises : vous n’êtes pas directement concerné par les exigences techniques du CIR 2024/2690, NIS2 pourra ou non vous concerner selon la transposition nationale. NIST SP 800-81r3 est le seul document que vous pouvez appliquer immédiatement sans attendre une clarification du périmètre ou une date limite.

Le mode d’échec le plus fréquent et le moins spectaculaire. La résolution cesse de fonctionner correctement, et comme ça dysfonctionne habituellement de façon intermittente, personne ne s’en rend compte.

• Les délégations boiteuses apparaissent quand les NS d’une zone parente pointent vers un serveur de noms non autoritatif pour la zone enfant, ou qui ne répond pas du tout. La délégation est inscrite, mais le serveur derrière ne tient pas son rôle. La résolution dépend alors du serveur tenté par le résolveur : le domaine fonctionne pour certains, renvoie SERVFAIL pour d’autres. Les deux résultats sont corrects, mais un seul est visible dans le test.
• Les enregistrements orphelins pointent vers une infrastructure qui n’existe plus. Un serveur a été supprimé, un load balancer remplacé, un service migré, mais l’enregistrement A ou CNAME est resté. Parfois l’enregistrement échoue simplement. Parfois l’adresse est réattribuée ailleurs, et l’entrée pointe alors vers l’infrastructure de quelqu’un d’autre.
• Les échecs de résolution partielle sont les plus difficiles à détecter car ils contournent le mode de fonctionnement de la plupart des surveillances. Un test « ce domaine résout-il ? » effectué d’un seul point le validera. Mais une partie des utilisateurs passe par un serveur contenant des données obsolètes, ou un résolveur qui valide DNSSEC contrairement au vôtre, ou une branche où un NS est mort. La panne est réelle et reproductible, juste invisible d’où on regarde.

La raison pour laquelle ce genre de problème persiste, c’est que DNS est conçu pour la résilience. La redondance fait qu’un serveur de noms cassé sur quatre ne cause généralement pas de panne visible, juste un service dégradé, un peu plus lent et moins fiable, qui ne déclenche jamais d’alerte assez claire pour être investigué.

Un transfert de zone, ou AXFR, permet à un serveur maître de répliquer un fichier de zone complet vers un secondaire. C’est normal et indispensable, mais dangereux si ce n’est pas restreint, car un serveur qui n’a pas de limitation sur les IP autorisées transmettra toute la zone à quiconque en fait la demande.

Une seule requête retourne tous les noms d’hôtes de la zone, avec les adresses. Pas besoin de scanner, de brute-forcer ou de deviner. Dans les patrimoines audités, cela a signifié la révélation des conventions internes, de la voix sur IP, d’environnements de développement au sein des zones de production, et presque des cartes réseau complètes en une réponse.

Le schéma à retenir : les zones parentes sont généralement verrouillées, car c’est la zone prioritaire pour la sécurité. Les sous-domaines délégués à d’autres équipes ou dédiés à un projet tournent avec leur propre configuration non auditée. Nous l’avons détaillé, y compris ce que deux vraies zones ont renvoyé, dans comment les transferts de zone ouverts exposent votre réseau interne.

Un enregistrement en suspens pointe vers un service tiers après que celui-ci a été supprimé. Si le nom derrière peut être revendiqué par un tiers, le domaine l’est aussi.

Le mécanisme est aussi simple que peu spectaculaire. Une équipe crée un site de campagne sur un site builder, un bucket de stockage ou un service cloud, publie l’enregistrement DNS, puis le projet se termine. Le service disparaît. L’enregistrement reste, car sa création était un acte planifié et sa suppression ne relève de personne.

Ce qui transforme un enregistrement dormant en prise de contrôle, c’est la plateforme de l’autre côté.

Lors d’une mission, nous avons analysé un portefeuille DNS et vérifié où pointaient réellement les enregistrements par rapport à ce que le client croyait. Un domaine, créé des années plus tôt pour une campagne marketing, avait une entrée A pointant vers un site builder tiers. La campagne était finie et le site supprimé. L’enregistrement était toujours présent, résolvant toujours, apparemment ignoré depuis la fin du projet.

Nous avons testé si la plateforme permettait une nouvelle revendication. Oui. Pas de challenge DNS TXT, pas de fichier à déposer, pas de vérification qu’un autre avait configuré le domaine avant, aucune notification à l’ancien propriétaire. La plateforme considérait l’enregistrement DNS comme intention suffisante – et c’est précisément là-dessus que repose l’échec. Un enregistrement DNS ne prouve rien sur qui peut accéder à la ressource derrière.

Dans la même après-midi, le domaine fut lié à notre compte et servait une page de notre rédaction, à l’adresse réelle du client, sur son vrai domaine, sans alerte de certificat ni anomalie apparente. Un visiteur tapant l’adresse ou utilisant un ancien lien n’aurait rien remarqué.

Le signalement fut fait le jour même. Après validation, l’enregistrement a été supprimé le soir, fermant l’exposition. La faille avait probablement existé des années. La trouver, la prouver, la fermer a pris une après-midi. Le correctif n’a jamais été la partie difficile.

C’est ce qui rend la prise de contrôle plus grave que les autres défaillances. Une fuite donne de l’information à un attaquant. Une prise de contrôle lui donne un canal fiable. Un contenu diffusé depuis un domaine déjà réputé ne déclenche aucune alerte instinctive, contrairement à un nom ressemblant. Cela rend la collecte de mots de passe, la distribution de malwares ou le détournement de trafic simple au lieu de complexe.

Les fournisseurs cloud l’assument : ils ne ferment pas cette faille pour vous. AWS précise que beaucoup de ses services autorisent la réutilisation de noms de ressources, qu’il n’y a pas de mécanisme universel de vérification de domaine entre services, et que ses équipes voient régulièrement des attaquants scanner les DNS publics pour détecter ces enregistrements fantômes [5]. OWASP traite ceci comme un problème opérationnel : il recommande l’inventaire, la suppression des enregistrements avant celle des ressources, et la détection des codes d’erreur générés par les ressources supprimées [6]. Les deux ont raison, mais tout repose sur vous. Pour savoir comment détecter et corriger ces enregistrements, voir dangling DNS : comment le détecter et le corriger avant la prise de contrôle.

Le mode d’échec qui survit aux audits, car tout s’affiche vert.

C’est le cas le plus flagrant, et la défaillance est asymétrique. Une zone signée avec signatures expirées ou un enregistrement DS qui ne correspond plus à la clé échoue à la validation bruyamment : DNSSEC fait son travail, même si l’utilisateur ne voit qu’une panne. L’échec silencieux : une zone qui semble signée à chaque contrôle, mais où nulle part la validation n’a lieu. Apparence DNSSEC mais pas la protection. Notre guide déploiement DNS selon NIST explique comment déployer DNSSEC correctement.

Un enregistrement TLSA publié n’est pas un déploiement DANE : DANE est effectif uniquement si la chaîne DNSSEC est validée. Sur SMTP, un résultat TLSA non sécurisé est traité comme du TLS opportuniste, pas comme DANE authentifié.

Des NS et SOA incohérents signifient que vos serveurs de noms ne sont pas d’accord sur le contenu de votre zone. Si les NS du parent diffèrent des NS du fils, un résolveur peut atteindre un serveur obsolète. Si les serials SOA divergent entre serveurs, chacun peut servir des données différentes au même instant, selon le NS contacté. Les deux sont invisibles si l’on interroge un serveur unique.

Ce qui lie ces risques, c’est que les contrôles affichent succès. Vous pouvez tenir un scan propre, une zone signée et un enregistrement DANE… sans la protection promise par aucun de ces trois.

Deux enseignements à retenir de cette correspondance.

La délégation boiteuse apparaît dans deux catégories de risques, pour deux conséquences distinctes, ce qui montre l’utilité du classement. La section 3.2.1 la voit comme un problème de disponibilité : une délégation pointant vers un serveur inexistant rend la zone inaccessible ou partiellement accessible. La section 3.6.2 y voit un vecteur de détournement : un sous-domaine délégué chez un fournisseur DNS dont le contrat a expiré peut être repris par un acteur malveillant contractant le même fournisseur. Une erreur, deux issues, la plupart des équipes ne cherchent que la première.

Zone drift et zone thrash (section 3.2.2) sont deux formes d’incohérence. Régler des valeurs Refresh et Retry trop hautes sur une zone à changements rapides rend vos secondaires obsolètes. Trop basses : charge excessive et inutile sur chaque transfert. Dans les deux cas, la qualité descend sans qu’on puisse pointer une panne claire.

Toute la suite en dépend, et c’est là où la plupart des programmes échouent discrètement. L’objectif est la couverture totale : chaque domaine, zone et enregistrement, tous registrars, fournisseurs DNS, comptes cloud, autorités de certification, que l’équipe d’origine existe encore ou non. Le piège, c’est de bâtir la liste sur la mémoire collective, car précisément les enregistrements problématiques sont ceux que personne ne retient. Un domaine hérité lors d’une acquisition jamais migré, des sous-domaines délégués à une équipe désormais dissoute, des sites événementiels créés par le marketing hors processus. Une liste basée sur ce que les gens pensent posséder sera fausse à coup sûr – et se trompera là où il ne faut pas. Notre blog sur le dangling DNS montre ce qu’il advient des enregistrements oubliés.

Une fois l’existant découvert, définissez votre norme de « propre » pour rendre les écarts visibles. Cela suppose de noter les registrars et DNS providers autorisés, les plages d’adresses cloud et autorités de certificats attendues, le niveau d’authentification mail par domaine expéditeur, et les zones signées en DNSSEC. Le but : la comparaison. Une migration prévue et une compromission NS provoquent le même événement DNS, seule la baseline indique quoi penser du changement. Sans baseline, on détecte le changement, pas sa nature.

Comparez en continu le patrimoine en ligne à la baseline, puis classez ce qui ressort. Environ 1 % des noms changent par jour dans un gros patrimoine (sur 37 500 enregistrements, cela fait 375 changements quotidiens). Un flux brut de ce volume est ignoré en quinze jours, ce qui est pire que rien car il donne l’illusion du monitoring. C’est la classification qui rend le tout opérable : distinguer le bruit récurrent fourni par les fournisseurs des vrais changements critiques, pour que seuls les changements anormaux ressortent.

Évaluez le patrimoine au regard de NIST SP 800-81r3, en transformant chaque mode d’échec ci-dessus en liste de vérifications. Refaites l’audit chaque jour, et suivez le taux de réussite dans le temps plutôt que de considérer chaque scan séparément. Un scan propre dit quelque chose d’un instant. Une chute du taux de conformité sur six semaines signale un glissement du patrimoine – c’est la tendance qui importe et elle précède la panne réelle.

Segmenter le patrimoine pour que le modèle reste opérationnel. Priorisez aussi les changements autant que les actifs. Un changement NS sur un domaine critique d’authentification client n’a rien à voir avec le même changement sur un domaine parking, et traiter les deux pareil, c’est perdre l’important. Croisez événement et incidents ouverts : un enregistrement qui change alors qu’une anomalie est déjà signalée doit déclencher une escalade et non rester dans la pile. Les programmes notant tout comme critique s’écroulent sous le volume d’alertes en moins de trois mois.

Le saut qui compte le plus est du niveau 2 au niveau 3, car c'est là que la détection ne dépend plus du fait que quelqu'un décide d'aller regarder.

Passez en revue ces éléments sur votre propre parc. Tout point auquel vous ne pouvez pas répondre de manière sûre constitue déjà une constatation en soi.

• Vous pouvez produire une liste de tous les domaines que possède votre organisation, tous registraires confondus
• Cette liste inclut les domaines acquis via fusions et acquisitions
• Vous savez quel fournisseur DNS héberge chaque zone
• Vous pouvez lister chaque sous-domaine délégué vers un serveur de noms que vous ne contrôlez pas
• Chaque zone a un propriétaire nommé qui travaille encore dans l'organisation

• Chaque enregistrement NS dans chaque zone parent pointe vers un serveur de noms faisant autorité pour la zone enfant
• Les numéros de série SOA correspondent sur tous les serveurs de noms pour chaque zone
• L'ensemble des NS au parent correspond à l'ensemble publié dans la zone enfant
• Vous testez la résolution depuis plusieurs résolveurs et géographies, et pas un seul

• Les transferts de zone sont restreints à des adresses IP secondaires nommées sur chaque serveur de noms
• Vous avez testé AXFR sur chaque sous-domaine délégué, pas seulement sur le parent
• Aucune zone ne contient de noms d’hôtes révélant une convention de nommage interne ou une infrastructure non publique
• Les environnements de développement et pré-production ne résident pas dans les zones de production

• Vous pouvez lister chaque enregistrement DNS pointant vers une plateforme SaaS tierce, un service cloud ou un bucket de stockage
• La suppression de l'enregistrement DNS est une étape obligatoire lors de la mise hors service de tout service tiers
• Vous savez lesquelles de ces plateformes vérifient la propriété de domaine avant d'autoriser un rattachement
• Quelqu’un révise ces enregistrements selon un planning, et non suite à un incident

• Vous savez quelles zones sont signées avec DNSSEC et lesquelles ne le sont pas
• L'expiration des signatures est surveillée, elle n'est pas présumée
• Toute zone publiant des enregistrements TLSA pour DANE est signée DNSSEC
• Les enregistrements DS au parent correspondent aux clés actuelles de la zone enfant
• Vous avez vérifié que la validation échoue vraiment lorsque cela doit être le cas

• Il existe une baseline définissant les registraires, fournisseurs, plages cloud et autorités de certification autorisés
• Les modifications sur les enregistrements NS, MX et TXT génèrent une alerte
• Le parc est hiérarchisé selon l'importance, et non traité de façon uniforme
• Quelqu’un est responsable de l’hygiène DNS à titre nominal, et non implicite

L’étape qui arrête la plupart des programmes est la première, car tout ce qui en découle repose sur la connaissance de ce qui existe. Les vérifications de configuration cloud-native sont utiles mais conçues par compte unique. Les scanners open source couvrent plus de terrain mais ne s’exécutent que lorsque quelqu’un y pense. Aucun ne couvre un parc réparti entre plusieurs registraires, fournisseurs DNS et comptes cloud appartenant à des équipes qui ne relèvent pas de la sécurité.

Red Sift ASM établit cet inventaire en se connectant directement à vos registraires, fournisseurs DNS et comptes cloud plutôt qu’en se basant sur une liste entretenue manuellement. Il surveille la configuration DNS et DNSSEC sur tout le parc en continu, signale les enregistrements orphelins et les ressources revendicables dès leur apparition, et valide la configuration DANE, ce qui fait que les modes d'échec de ce guide deviennent des constats plutôt que des incidents.

• [1] Directive (UE) 2022/2555 du Parlement européen et du Conseil du 14 décembre 2022 sur des mesures destinées à assurer un niveau élevé commun de cybersécurité dans l’Union
• [2] Règlement d’exécution (UE) 2024/2690 de la Commission du 17 octobre 2024
• [3] NIS2 Technical Implementation Guidance
• [4] Secure Domain Name System (DNS) Deployment Guide, NIST SP 800-81r3
• [5] Threat Tactic Spotlight: Subdomain Takeover
• [6] Subdomain Takeover Prevention Cheat Sheet