20 vérifications de sécurité DNS que tout domaine devrait réussir

La plupart des compromissions de domaines ne commencent pas par un mot de passe volé, mais par une erreur de configuration DNS que personne n'a remarquée. Un domaine passe un véritable audit de sécurité DNS lorsque sa chaîne DNSSEC est validée, que son enregistrement CAA restreint les autorités de certification autorisées, que ses enregistrements SPF/DKIM/DMARC sont correctement définis et appliqués, et que l'hygiène de ses serveurs de noms et de sa zone ne laisse ni enregistrements orphelins ni transferts de zone ouverts. Voici 20 vérifications concrètes à exécuter sur n'importe quel domaine, regroupées par catégorie, avec des exemples prêts à copier-coller.

Pourquoi une checklist de sécurité DNS est essentielle

Le DNS se trouve sous tout le reste : la délivrabilité des e-mails, l'émission des certificats TLS, la résolution de votre site. Un seul CNAME obsolète ou un enregistrement CAA manquant peut permettre à un attaquant de prendre le contrôle d'un sous-domaine ou d'obtenir un certificat frauduleux pour votre domaine sans jamais toucher à vos serveurs. Suivre une checklist fixe permet de repérer les points fastidieux mais à fort impact que les audits improvisés laissent passer.

Vérifications DNSSEC (1–2)

1. DNSSEC est activé et la chaîne de confiance est validée. Les extensions de sécurité du DNS (DNSSEC) signent votre zone afin que les résolveurs puissent vérifier que les enregistrements n'ont pas été altérés en transit. Vérifiez que l'enregistrement DS de votre domaine chez le registrar correspond au DNSKEY publié dans votre zone : une incohérence provoque un SERVFAIL sur tous les résolveurs validants, ce qui rend silencieusement le site inaccessible pour les réseaux soucieux de sécurité. Contrôlez-le avec dig +dnssec yourdomain.com ou avec notre outil de recherche DNS.

2. NSEC3 est utilisé à la place du NSEC simple. Les réponses NSEC standard permettent à n'importe qui de « parcourir » votre zone et d'énumérer tous les noms d'enregistrements qu'elle contient, ce qui offre gratuitement une phase de reconnaissance à un attaquant. NSEC3 hache les noms dans les réponses de non-existence, de sorte que l'énumération de la zone n'est plus triviale. Si votre fournisseur DNS le prend en charge, privilégiez NSEC3.

Vérification de l'enregistrement CAA (3)

3. Un enregistrement CAA restreint les autorités de certification autorisées à émettre des certificats pour votre domaine. Sans enregistrement CAA (Certificate Authority Authorization), n'importe quelle autorité de certification publique peut émettre un certificat pour votre domaine si elle est trompée ou compromise. Publiez-en un pour verrouiller l'émission :

yourdomain.com.  IN  CAA  0 issue "letsencrypt.org"
yourdomain.com.  IN  CAA  0 issuewild ";"
yourdomain.com.  IN  CAA  0 iodef "mailto:security@yourdomain.com"

Cet exemple n'autorise que Let's Encrypt à émettre des certificats standard, bloque toute émission de certificats wildcard et indique aux autorités de certification où signaler les tentatives non conformes. Pour comprendre le fonctionnement réel de l'émission et de la chaîne de confiance, consultez Les certificats SSL expliqués.

Vérifications de l'authentification des e-mails (4–7)

4. SPF comporte un seul enregistrement TXT et reste sous la limite de 10 requêtes. Sender Policy Framework (SPF) est défini dans la RFC 7208. Deux enregistrements TXT SPF sur un même domaine constituent en soi une condition d'échec, et dépasser 10 mécanismes générant des requêtes DNS (include, a, mx, ptr, exists, redirect) déclenche une erreur permanente qui peut faire échouer toute la vérification. Validez le vôtre avec le générateur SPF, et lisez comment créer un enregistrement SPF sécurisé si vous devez réduire le nombre de requêtes.

5. Les clés DKIM font au moins 2048 bits et n'utilisent pas rsa-sha1. DomainKeys Identified Mail (DKIM, RFC 6376) signe les e-mails sortants pour que les destinataires puissent vérifier qu'ils n'ont pas été modifiés. La RFC 8301 a rendu obsolète l'algorithme rsa-sha1 et recommande des clés RSA de 2048 bits ou plus : les clés de 1024 bits sont obsolètes et doivent être remplacées.

6. DMARC est publié en mode application, pas seulement en surveillance. Domain-based Message Authentication, Reporting and Conformance (DMARC, RFC 7489) utilise une balise p= avec la valeur none, quarantine ou reject. Un domaine qui reste indéfiniment en p=none reçoit des rapports mais aucune protection réelle contre l'usurpation : passez à quarantine ou reject dès que vos rapports agrégés rua montrent un alignement SPF/DKIM correct. Créez ou vérifiez le vôtre avec le générateur DMARC.

7. Le mode d'alignement DMARC correspond à votre intention. Les balises adkim/aspf déterminent si les domaines SPF et DKIM doivent correspondre exactement au domaine de l'en-tête From: (s, strict) ou simplement partager le même domaine organisationnel (r, relaxed, la valeur par défaut). L'alignement relaxed convient à la plupart des configurations, mais revoyez-le si vous envoyez depuis de nombreux sous-domaines.

Vérifications des serveurs de noms et de l'hygiène de zone (8–14)

8. Les enregistrements NS concordent entre le registrar et la zone. Si les serveurs de noms déclarés chez votre registrar ne correspondent pas à ceux réellement servis dans la zone, la résolution peut devenir incohérente ou divergente selon l'enregistrement auquel le résolveur se fie.

9. Les enregistrements glue sont corrects pour les serveurs de noms internes au domaine. Si vos serveurs de noms sont des sous-domaines du domaine lui-même (par ex. ns1.yourdomain.com), la zone parente a besoin d'enregistrements glue pointant directement vers leurs adresses IP, sans quoi la résolution peut boucler ou échouer.

10. Les transferts de zone (AXFR) sont limités aux serveurs secondaires autorisés. Un transfert de zone ouvert livre l'intégralité de votre zone DNS à quiconque la demande. Testez-le depuis l'extérieur :

dig axfr yourdomain.com @ns1.yourdomain.com

Si cette commande renvoie l'ensemble de vos enregistrements depuis l'extérieur de votre infrastructure, verrouillez-la immédiatement : elle ne doit réussir que pour vos propres serveurs secondaires déclarés.

WarningUne réponse AXFR ouverte est l'un des moyens les plus rapides pour un attaquant de cartographier chacun de vos sous-domaines, serveurs de messagerie et noms d'hôtes internes : traitez tout transfert de zone externe réussi comme une faille critique.

11. Aucun enregistrement orphelin ne pointe vers des ressources supprimées. Un CNAME pointant toujours vers un bucket de stockage cloud, un répartiteur de charge ou un point de terminaison SaaS supprimé est un vecteur classique de prise de contrôle de sous-domaine. Confrontez chaque CNAME et chaque enregistrement A à ce qui est réellement encore provisionné. Notre guide des types d'enregistrements DNS est une référence utile pour vérifier le rôle de chaque enregistrement lors de l'audit.

12. Les enregistrements wildcard sont intentionnels, et non des restes. Un enregistrement *.yourdomain.com capte tous les sous-domaines non déclarés, ce qui peut discrètement faire résoudre des domaines de phishing ressemblants vers votre infrastructure ou faire passer des fautes de frappe pour des adresses légitimes. Supprimez les wildcards que vous n'avez pas configurés délibérément.

13. Les TTL sont ajustés, et non laissés par défaut. Le TTL (time to live, durée de vie) détermine combien de temps les résolveurs mettent un enregistrement en cache. Trop élevé, vous ne pouvez pas basculer rapidement lors d'un incident ; trop bas, vous ajoutez une charge de requêtes inutile. Quelques centaines à quelques milliers de secondes constituent une base raisonnable pour la plupart des enregistrements, à abaisser avant les changements planifiés.

14. Les serveurs de noms sont diversifiés géographiquement et topologiquement. Héberger tous vos serveurs de noms faisant autorité sur un seul réseau ou chez un seul fournisseur signifie qu'une seule panne met tout votre domaine hors ligne. Répartissez-les sur des réseaux ou des ASN indépendants.

Vérifications opérationnelles et de surveillance (15–20)

15. Le DNS inverse (PTR) est configuré pour chaque IP d'envoi d'e-mails. De nombreux serveurs de messagerie destinataires rejettent ou classent en spam les e-mails provenant d'IP sans enregistrement PTR correspondant, et c'est un signal anti-usurpation de base.

16. Le verrouillage de transfert et la 2FA sont activés chez le registrar. Un verrou de transfert empêche les transferts non autorisés de votre domaine vers un autre registrar, et l'authentification à deux facteurs (2FA) sur le compte empêche les prises de contrôle par credential stuffing.

17. L'accès au fournisseur DNS est contrôlé et journalisé. Toute personne disposant d'un accès en écriture à votre zone peut rediriger le trafic ou les e-mails. Utilisez des rôles au moindre privilège et vérifiez que les modifications d'enregistrements sont journalisées.

18. Les journaux Certificate Transparency sont surveillés pour détecter les émissions frauduleuses. Chaque certificat de confiance publique est consigné dans les journaux Certificate Transparency (CT). Surveiller les journaux CT pour votre domaine permet de repérer un certificat émis à votre insu, même par une autorité de certification autorisée.

19. L'expiration du domaine et des clés DNSSEC est suivie de manière proactive. Un domaine expiré ou une clé de signature DNSSEC non renouvelée mettent tous deux un site en production hors ligne. Consultez notre guide comment récupérer un domaine qui expire pour savoir ce qui se passe si vous laissez passer l'échéance.

20. La santé DNS est vérifiée selon un calendrier, et pas seulement après un incident. Effectuez régulièrement une vérification complète (A, AAAA, MX, TXT, NS, CAA) sur votre zone en production plutôt que seulement lorsque quelque chose tombe en panne. Associez-la à un uptime monitoring et à une surveillance des certificats pour qu'une défaillance au niveau DNS soit détectée immédiatement ; consultez la surveillance de sites web expliquée pour voir comment tout cela s'articule.

Tableau récapitulatif

TipCommencez par les vérifications 3, 4, 6 et 10 : CAA, SPF, DMARC et les transferts de zone ouverts sont les points de cette liste qui ont le plus d'impact et se corrigent le plus vite.

Effectuer manuellement ces 20 vérifications sur plusieurs domaines devient vite fastidieux, surtout si vous gérez des enregistrements chez plusieurs registrars et fournisseurs. Les fonctionnalités DNS d'InfraNest vous permettent d'auditer et de gérer vos enregistrements, DNSSEC et votre politique CAA depuis un seul tableau de bord : commencez par un premier passage avec l'outil de recherche DNS gratuit sur chaque domaine dont vous êtes responsable.