Guide de déploiement DNS sécurisé : 15 bonnes pratiques pour les services faisant autorité

En mars 2026, le NIST a publié SP 800-81r3, son guide de déploiement DNS sécurisé. Il s'agit de la deuxième révision de ce document (publié pour la première fois 13 ans plus tôt), qui s'articule globalement autour de trois volets :

1. l'utilisation du DNS dans l'architecture réseau
2. la consommation sécurisée du DNS
3. la sécurité des serveurs DNS faisant autorité.

Si ce n'est pas déjà fait, nous vous recommandons vivement de lire notre synthèse de ce guide pour vous mettre à niveau. Cela dit, le présent guide se concentre sur le dernier volet : la sécurité des serveurs DNS faisant autorité. D'une certaine manière, il reprend là où le NIST s'est arrêté. Forts de plus de dix ans passés à concevoir des produits dédiés à la sécurité DNS, nous avons voulu apporter davantage de détails sous la forme de bonnes pratiques faciles à suivre pour sécuriser les serveurs DNS faisant autorité.

Ce guide s'adresse à tous ceux qui souhaitent s'informer sur les principales menaces, identifier celles qui les concernent et choisir les stratégies d'atténuation les mieux adaptées à leur situation. Rassurez-vous, il est court !

Si votre public est le grand public, mieux vaut ne pas héberger vous-même vos serveurs DNS faisant autorité, et ce pour plusieurs raisons. Premièrement, c'est une tâche considérable. Pour commencer, vous devez desservir une base d'utilisateurs largement répartie, ce qui implique de déployer plusieurs serveurs dans le monde entier en Anycast afin qu'ils apparaissent tous sous la même adresse IP. Ensuite, vous devez assurer la résilience, idéalement avec au moins deux niveaux de serveurs répartis sur deux réseaux indépendants. Il faut ensuite veiller à ce qu'ils restent disponibles et synchronisés. Et par-dessus tout cela, vous devez vous prémunir contre les attaques par déni de service. La liste est encore longue, mais vous voyez l'idée. Ce n'est vraiment pas une mince affaire.

Deuxièmement, de nombreux fournisseurs de DNS managé de haute qualité sont disponibles à un coût très raisonnable. Héberger votre propre DNS ne vous apporte aucun avantage particulier, vous coûte plus cher et le résultat n'est pas aussi bon que chez les grands fournisseurs. Vous avez tout intérêt à consacrer votre temps et vos ressources à d'autres projets. D'ailleurs, si vous souhaitez une présence DNS très robuste, vous envisagerez probablement de recourir à deux fournisseurs managés afin de rester en ligne si l'un d'eux tombe en panne.

Ce conseil ne s'applique pas nécessairement si vous déployez un serveur DNS faisant autorité pour un public privé. La charge de travail est bien moindre ; vous voudrez de toute façon garder vos données privées, et vous pouvez déployer au plus près de vos utilisateurs.

Lorsque vous confiez vos besoins DNS à un tiers, l'approche habituelle consiste à lui laisser la gestion de vos données faisant autorité, que vous mettez à jour via une API propriétaire. Cela ne pose généralement pas de problème si vous partez de zéro, mais vous disposez peut-être déjà d'un serveur DNS qui fait office de source de vérité. Ou peut-être est-il déjà intégré à votre organisation, avec des workflows que vous ne souhaitez pas modifier.

Il est tout à fait acceptable de conserver la maîtrise de votre serveur primaire, mais en règle générale, vous ne souhaitez pas l'exposer sur l'internet public. Les attaques par déni de service sont courantes, et les attaquants ciblent généralement le maillon le plus faible. S'ils découvrent où se trouve votre serveur primaire, il risque d'être attaqué en premier.

Plusieurs options s'offrent à vous. Vous pouvez d'abord le maintenir en ligne, mais sans en divulguer le nom ni l'adresse IP. Vous pouvez aussi le déployer derrière un pare-feu qui autorise l'accès depuis les réseaux de votre fournisseur DNS, mais pas depuis l'internet public.

Dans cette configuration, votre serveur primaire constitue votre plan de contrôle, tandis que vos fournisseurs de DNS managé gèrent le plan de requêtes (de données).

Cela va sans dire, mais mérite tout de même d'être abordé : mélanger les fonctions faisant autorité et récursives n'est jamais une bonne idée. Même si les deux ressemblent de loin à des serveurs DNS, leurs rôles sont très différents. Sauf dans des cas triviaux, la fonction récursive est plus exigeante et peut nuire au composant faisant autorité.

Un serveur de noms primaire ne communique normalement qu'avec ses serveurs secondaires. Sa mission est simple : détenir les informations de référence du domaine et les distribuer aux serveurs chargés de communiquer avec le public. À l'inverse, les serveurs récursifs doivent desservir un large public (souvent le grand public, soit exactement l'inverse de ce que vous souhaitez pour un serveur DNS faisant autorité), interroger n'importe quel autre serveur DNS sur internet, gérer un cache, etc.

Par définition, les serveurs faisant autorité contiennent des informations publiques, mais cela ne signifie pas qu'elles doivent être fournies en masse à quiconque les demande. La discrétion conserve son utilité. Les transferts de zone sont un mécanisme conçu pour propager les mises à jour des serveurs primaires vers les secondaires, mais on constate fréquemment qu'ils sont accessibles à tous. En pratique, il est préférable de ne communiquer ces informations qu'à ceux qui en ont besoin.

Dans la mesure du possible, utilisez des contrôles d'accès réseau et l'authentification pour éviter que les informations de zone ne tombent entre de mauvaises mains. L'approche habituelle consiste à utiliser l'authentification TSIG, qui repose sur des algorithmes symétriques rapides. Si vous devez authentifier un grand nombre de parties, il existe également SIG(0), qui utilise la cryptographie à clé publique, mais dont le déploiement et la maintenance demandent davantage d'efforts.

Certains serveurs DNS divulguent leur numéro de version. C'est un autre point à vérifier et à désactiver.

Une tactique courante des attaquants consiste à cibler vos interfaces de gestion. Si vous masquez votre serveur primaire, le tenir à l'écart de l'internet public éliminera un vecteur d'attaque important.

Si vos données faisant autorité sont hébergées chez un fournisseur de DNS managé, utilisez tous les moyens disponibles pour protéger les interfaces de gestion et les points de terminaison d'API. Utilisez au minimum l'authentification à deux facteurs, et envisagez également de restreindre les adresses IP autorisées à y accéder.

Dans de nombreuses petites entreprises, la configuration des zones DNS change peu et peut être gérée de manière statique. Traditionnellement, les mises à jour DNS dynamiques (par exemple, RFC 2136) étaient réservées aux grandes entreprises dotées d'environnements complexes. Cependant, la validation automatisée de domaine pour l'émission de certificats X.509 via le protocole ACME est devenue très populaire, et l'une des méthodes repose sur une modification DNS.

Autoriser les mises à jour DNS dynamiques va à l'encontre de votre capacité à verrouiller votre serveur de noms primaire et à le sécuriser. Deux aspects sont à prendre en compte :

• Les points de terminaison distants doivent se connecter à l'endroit où résident vos données
• Vous devez vous assurer que chaque entité n'est autorisée à modifier qu'un ensemble restreint de données, et non la totalité

Votre fournisseur de DNS managé propose peut-être une bonne solution à cet égard dans ses API, mais sa conception et sa gestion mobiliseront tout de même des ressources. Si vous hébergez votre propre serveur de noms, envisagez d'utiliser un proxy renforcé plutôt que d'exposer votre serveur primaire sur internet.

Autre solution, certains fournisseurs proposent des services de validation ACME reposant sur la configuration ponctuelle d'un enregistrement CNAME depuis votre domaine vers un point de terminaison tiers. Ils peuvent ensuite gérer la validation ACME pour vous. Cela permet d'éviter les mises à jour DNS dynamiques, mais en contrepartie, la validation de vos certificats dépend désormais d'un tiers.

La gestion de versions est votre alliée. S'il est primordial que vos zones contiennent et distribuent des informations exactes, savoir quand et pourquoi des modifications ont eu lieu vous aide à déterminer si ces informations sont effectivement correctes. En réalité, diffuser votre configuration DNS au monde entier ne représente plus un défi majeur aujourd'hui, mais garantir l'exactitude de vos informations en est bien un.

Si votre configuration DNS se présente sous forme de fichiers de zone, placez-les sous gestion de versions, avec Git par exemple. Protégez la branche principale et utilisez des workflows de pull requests pour documenter et valider les modifications au fil de l'eau. DNSControl et octoDNS sont deux outils open source populaires qui prennent en charge ce type de workflow.

Les informations que vous placez dans votre configuration DNS ont une raison d'être et doivent être distribuées à ceux qui en ont besoin. Partez du principe que tout ce que vous placez dans vos zones est une information publique. N'y mettez rien que vous ne souhaitez pas voir découvert, car cela finira inévitablement par se savoir. Passez régulièrement en revue ce qui est publié dans vos fichiers de zone et vérifiez si certains éléments peuvent être supprimés.

Voici un bref aperçu des techniques de reconnaissance courantes :

• Transferts de zone. S'ils sont activés, les transferts de zone constituent le moyen le plus efficace d'obtenir l'intégralité du fichier de zone. Toutefois, comme nous l'avons vu, ils doivent être désactivés par défaut et activés uniquement là où ils sont réellement nécessaires.
• Services de DNS passif. Historiquement, le DNS n'a jamais protégé le trafic en transit. Comme les données contenues dans ces paquets UDP renferment de nombreuses informations utiles (par exemple pour le profilage), toute une industrie de la surveillance DNS passive a vu le jour. Ces entreprises déploient des sondes partout dans le monde, aux points de jonction les plus fréquentés, et enregistrent tout ce qu'elles peuvent. Les données sont ensuite mises à disposition, moyennant paiement, de quiconque est prêt à payer. Statistiquement, certains de vos sous-domaines les plus confidentiels pourraient passer inaperçus, mais les plus fréquentés seront assurément observés.
• Certificate Transparency. Certificate Transparency (CT) est un système qui surveille l'émission de tous les certificats publics. Comme les certificats incluent des domaines et des sous-domaines, ils divulguent des informations qui étaient auparavant souvent privées. Désormais, même les sous-domaines les plus confidentiels deviennent publics dès lors qu'un seul certificat est émis. Les certificats wildcard, s'ils sont utilisés de manière sûre, peuvent aider dans une certaine mesure, mais malheureusement, partager des certificats entre des services sans lien entre eux élargit le "rayon d'impact" d'une compromission ou d'une expiration.
• Force brute sur les enregistrements de ressources. Comme il n'existe qu'un petit nombre de types d'enregistrements de ressources principaux, les tester par force brute est très facile et génère peu de bruit une fois qu'un sous-domaine a été découvert.
• Fuite d'informations via DNSSEC. Lors de la conception initiale de DNSSEC, l'approche principale consistait à pré-signer toutes les données, puis à éviter toute opération cryptographique à l'exécution. Cela posait un problème pour répondre à des requêtes portant sur des domaines inexistants arbitraires. La signature dynamique était jugée trop coûteuse. Deux solutions ont été les enregistrements NSEC et NSEC3, qui évitaient la signature dynamique. Cependant, leur conception permettait de "parcourir l'arbre" (c'est-à-dire de découvrir entièrement) n'importe quelle zone dotée de DNSSEC. Les solutions modernes à ce problème sont connues sous les noms de "White Lies" (RFC 4470) et, plus récemment, "Black Lies" (RFC 9824).
• Énumération de domaines DNS. Si tout le reste échoue, les attaquants peuvent toujours compter sur la "bonne vieille" énumération par force brute. Munis de dictionnaires contenant les libellés DNS les plus courants (souvent personnalisés en fonction de ce que l'on sait déjà de votre parc DNS), ils essaient tout simplement toutes les possibilités, souvent à grande vitesse. Ces attaques sont généralement très bruyantes et peu sophistiquées ; une bonne surveillance doit pouvoir les détecter, car elles génèrent un grand nombre de réponses NXDOMAIN.

Comme nous l'avons vu, tout ce que vous placez dans vos zones DNS faisant autorité finira par devenir public, d'une manière ou d'une autre. Vous ne pouvez pas supprimer ce dont vous avez réellement besoin, mais veillez à ne pas en divulguer trop. Les entreprises utilisent souvent un même nom de domaine pour des besoins publics et privés ; dans ce dernier cas, leur DNS faisant autorité contiendra des informations internes.

Si vous partez de zéro, envisagez d'utiliser des noms de domaine distincts pour les activités publiques et privées. Si vous partagez déjà un nom de domaine, envisagez un déploiement DNS en zones séparées (split-zone), dans lequel la partie publique ne contient que ce qui est véritablement public, tandis que les informations privées sont distribuées via une infrastructure distincte, accessible uniquement à vos utilisateurs internes.

Pour masquer les informations, la meilleure approche consiste à utiliser une PKI privée pour vos certificats internes. Cela implique un coût non négligeable, lié aux efforts et aux dépenses nécessaires pour maintenir une CA privée, ainsi qu'à la nécessité d'intégrer ses certificats racines sur tous les appareils clients.

Au départ simple service fournissant principalement des informations sur les adresses IP (enregistrements A), le DNS est devenu de plus en plus complexe au fil du temps. Il comporte aujourd'hui de nombreux éléments interdépendants et modes de défaillance. Non seulement il y a plusieurs serveurs (primaires et secondaires), mais ceux-ci sont également répartis dans le monde entier. Ils doivent fonctionner en IPv4 et en IPv6, ainsi qu'en UDP et en TCP. À grande échelle, des problèmes surviennent en permanence, et le meilleur moyen de les détecter est la surveillance active.

Les journaux de requêtes des serveurs DNS sont souvent oubliés, mais si vous hébergez vos propres serveurs, ils doivent impérativement être surveillés et conservés avec tous vos autres journaux. Si vous suivez ces bonnes pratiques, les journaux de votre serveur de noms primaire seront très succincts. Toute entrée qui y apparaît signalera un contrôle défaillant.

Par défaut, l'intégralité de l'espace de noms de vos zones faisant autorité est sous votre contrôle direct. Le DNS est par nature distribué, avec des pointeurs non seulement vers d'autres emplacements que vous contrôlez, mais aussi vers des tiers. Cela se fait le plus souvent via des enregistrements CNAME, la délégation de sous-zones et parfois, plus rarement, via des enregistrements DNAME.

Ces délégations sont généralement ajoutées pour permettre à un tiers de fournir un service quelconque, mais il faut bien comprendre que chaque délégation introduit un élément de risque. Elles doivent donc être recensées et surveillées dans le cadre de votre gestion des risques. Impliquez votre équipe de sécurité applicative, car elle peut évaluer si les domaines délégués sont susceptibles d'affecter la sécurité des domaines parents ou voisins. Informez les responsables de votre surveillance PKI, car des tiers peuvent émettre des certificats en votre nom auprès de CA différentes des vôtres.

Votre plateforme de surveillance doit idéalement fournir un inventaire complet des délégations à des tiers. Annotez-les avec leur finalité et leur propriétaire et, si possible, fixez-leur une date d'expiration. Incluez bien dans cette liste les délégations de services vers des domaines qui ne vous appartiennent pas.

Les délégations à des tiers évoquées dans la bonne pratique précédente présentent un risque lorsqu'elles sont actives, mais parfois un risque plus grand encore lorsqu'elles cessent de fonctionner. Elles peuvent alors être prises en main par un tiers malveillant.

Voici les causes les plus fréquentes :

• Un abonnement à un service tiers est souscrit, et un CNAME est ajouté pour pointer vers l'infrastructure du fournisseur. Quelque temps plus tard, l'abonnement est résilié, mais le CNAME reste en place. Si la destination du CNAME est également supprimée, le cas est simple, car l'enregistrement de ressource DNS est alors cassé. Cependant, le plus souvent, ces CNAME pointent vers une destination générique (c'est-à-dire une seule destination pour tous les clients), ce qui donne lieu à un service orphelin bien plus difficile à détecter.
• Un nouveau service est configuré dans le cloud, identifié par une ou plusieurs adresses IP. Des enregistrements DNS A et AAAA sont ajoutés. Quelque temps plus tard, le service est arrêté, mais les enregistrements DNS subsistent. Le fournisseur cloud attribue alors les adresses IP devenues inutilisées à ses autres clients.

Ce sont deux des problèmes les plus courants, mais le DNS regorge par nature de moyens de pointer d'un endroit vers un autre. Pratiquement tous les enregistrements de ressources DNS (RR) peuvent causer ce type de problème : A, AAAA, CNAME, NS, SOA, MX, CAA, SRV, TXT, HTTPS… et bien d'autres.

Le problème de fond est qu'une fois un pointeur configuré, il n'existe aucun moyen de le maintenir synchronisé avec sa destination. Une surveillance complète et continue de l'ensemble de la surface DNS est le seul moyen de détecter ces problèmes à temps, avant qu'ils ne puissent être exploités par des acteurs malveillants.

Vos adversaires vous attaqueront par tous les moyens possibles. Parfois, s'ils ne peuvent pas exploiter directement vos noms de domaine (par exemple via un enregistrement DNS orphelin), ils enregistrent des noms de domaine qui pourraient, aux yeux de vos employés comme de vos clients, passer pour les vôtres.

Vous pouvez être alerté de l'existence de ces noms de domaine similaires grâce à un service tiers, tel que Red Sift Brand Trust. La détection repose sur la surveillance de l'inventaire complet des noms de domaine du monde entier, ainsi que sur diverses autres techniques.

Ne libérez pas les noms de domaine que vous avez utilisés par le passé et n'oubliez pas de les renouveler. Sinon, ils risquent d'être réenregistrés et éventuellement utilisés contre vous. Après tout, ils vous appartenaient, et ils conservent probablement une partie de votre réputation implicite.

En outre, la propriété d'un domaine sert parfois à établir des relations de confiance avec des tiers. Si un nom de domaine est abandonné, quiconque le récupère héritera des relations de confiance existantes.

DNSSEC reste un sujet qui divise, et vous avez peut-être remarqué que nous ne l'avons pas inclus dans nos bonnes pratiques. À vrai dire, nous sommes partagés. D'un côté, DNSSEC offre une fonctionnalité introuvable ailleurs : l'intégrité cryptographique de la résolution DNS faisant autorité. (Pour comprendre pourquoi c'est important, consultez cet article de blog, qui explique comment DNSSEC améliore la sécurité de la PKI du Web.)

D'un autre côté, son adoption reste très faible. DNSSEC est difficile à exploiter et les outils manquent encore de maturité. La plupart des entreprises évitent DNSSEC à moins qu'il ne soit automatisé par leur plateforme d'hébergement, même si la sécurité en pâtit.

Pour ne rien arranger, la menace imminente d'ordinateurs quantiques capables de casser la cryptographie actuelle obligera DNSSEC à changer ses algorithmes cryptographiques sous-jacents, mais on ne sait pas encore à quoi ressembleront ces changements, ni même si UDP restera le principal mécanisme de transport, compte tenu de la taille bien plus importante des signatures post-quantiques.

En résumé, nous pensons que DNSSEC remplit une fonction très importante, mais nous ne pouvions pas le classer parmi les bonnes pratiques, car il n'est pas universellement reconnu comme tel.

Si un enregistrement DNS orphelin ou un service orphelin est exploité, les conséquences peuvent être très fâcheuses. Il existe toutefois une mesure d'atténuation possible, qui repose sur le fait que les navigateurs modernes exigent des certificats X.509 valides. Si nous pouvions empêcher les attaquants d'obtenir un certificat valide, leurs tentatives d'exploitation pourraient échouer.

Par défaut, si vous contrôlez une adresse IP vers laquelle pointe un domaine DNS, vous pouvez obtenir un certificat pour celui-ci. Mais il n'a pas à en être ainsi, car les propriétaires de domaines peuvent publier des politiques qui encadrent la validation de domaine. La technologie correspondante s'appelle Certification Authority Authorization (CAA), et toutes les CA publiques sont tenues de la respecter.

Dans le contexte des enregistrements DNS orphelins, CAA vous offre plusieurs options : 1) centraliser l'émission de certificats pour l'ensemble du nom de domaine, empêchant totalement les serveurs individuels d'obtenir directement des certificats ; ou 2) imposer, pour chaque domaine donné, l'utilisation d'un compte ACME spécifique.

La plateforme Attack Surface Monitoring de Red Sift (ASM), anciennement Hardenize, a été la première plateforme au monde de découverte et de surveillance continues et approfondies, conçue pour les entreprises souhaitant surveiller leur propre présence sur internet. Au sein d'ASM, le composant DNS de ce produit met pleinement en œuvre les aspects de surveillance décrits dans ce document, notamment la surveillance de l'état des services faisant autorité, des connexions avec des tiers, ainsi que la détection des enregistrements DNS orphelins et des services orphelins.

L'offre Brand Trust de Red Sift bloque les attaques par domaines sosies avant qu'elles ne nuisent à votre marque. Elle détecte, surveille et fait supprimer les domaines sosies malveillants grâce à une protection des domaines et de la marque alimentée par l'IA.

• RFC 9499 : Terminologie DNS
• NIST SP 800-81 Rev. 3 : Guide de déploiement DNS sécurisé
• Red Sift : Guide de déploiement DNS sécurisé du NIST : bonnes pratiques
• IANA : Exigences techniques applicables aux serveurs de noms faisant autorité