Audit DNS 2026 : Sécuriser SOA, SPF, DMARC, DNSSEC, DANE

Le Domain Name System constitue la fondation invisible mais critique de l'Internet contemporain : aucun service moderne — courrier électronique, navigation web, voix sur IP, messagerie instantanée, plateformes SaaS, terminaux IoT, fintech ou systèmes industriels — ne fonctionne sans cette résolution silencieuse qui traduit les noms humains en adresses IP machines. Pourtant, en 2026, le DNS demeure le maillon le plus négligé des programmes de sécurité, alors même que la pression réglementaire NIS2 (transposition française d'octobre 2024), les exigences Yahoo et Google de février 2024 sur l'authentification email, et la multiplication des incidents BEC, subdomain takeover et DKIM replay ont fait basculer cet héritage technique des années 1980 dans la catégorie des actifs cyber stratégiques. Un audit DNS rigoureux en 2026 dépasse largement la simple vérification des enregistrements SPF et MX : il mobilise plus de trente-cinq RFC IETF actives, couvre cinq niveaux d'analyse (résolution, authentification email, intégrité cryptographique, état de l'art, hardening transverse) et confronte la configuration observée à six kill chains MITRE ATT&CK aujourd'hui banalisées par les groupes cybercriminels comme par les acteurs étatiques. Ce guide expose la méthodologie complète que nous appliquons chez Ayi Nedjimi Consultants sur les missions d'audit, les contrôles techniques précis à exécuter, les seuils de conformité aux référentiels ANSSI, NIS2 et Part-IS aviation, et le plan de remédiation type qui permet à un client passant d'un score de 30/100 à 85/100 sur internet.nl en moins de vingt-huit jours. Vous y trouverez les commandes dig exactes, les snippets DNS prêts à copier-coller, les pièges opérationnels que nous avons rencontrés en production sur Microsoft 365, OVH, AWS Route 53 et Google Workspace, ainsi que les recommandations de veille post-quantique, DKIM2 et ECH qui définissent le standard 2027.

Pourquoi le DNS est devenu un actif cyber stratégique en 2026

Le constat est paradoxal : le DNS, défini par les RFC 1034 et 1035 de Paul Mockapetris en 1987, est l'annuaire téléphonique d'Internet, et pourtant il demeure le composant le plus mal documenté, le moins surveillé et le moins audité dans la majorité des systèmes d'information que nous accompagnons. Trois raisons expliquent cette anomalie historique. Le DNS est invisible quand il fonctionne — un utilisateur final ne réalise pas qu'une simple navigation vers https://www.example.com déclenche une chaîne de cinq à dix lookups DNS distincts, et il n'en perçoit l'existence que lorsque la résolution casse, comme lors de l'incident BGP/DNS Facebook d'octobre 2021 (six heures d'indisponibilité mondiale) ou de l'incident Akamai DNS du 22 juillet 2021 où Sony, UPS, Steam, Airbnb et FedEx sont tombés simultanément. Le DNS est invisible dans les outils de sécurité — les SIEM, EDR et NDR collectent prioritairement les logs réseau, OS et applicatifs, et les logs DNS, quand ils sont collectés, sont rarement corrélés aux autres signaux. Le DNS est lent à évoluer — les standards d'authentification courrier comme SPF (2006), DKIM (2007) et DMARC (2015) mettent en moyenne dix ans à atteindre un seuil d'adoption de 50 % dans les entreprises, et DNSSEC, déployable depuis 2010, n'est actif que sur moins de 10 % des domaines mondiaux selon les statistiques ICANN de 2026.

Cette invisibilité a longtemps protégé le DNS de l'attention adverse. Cette époque est révolue. Plusieurs basculements structurels ont fait du DNS un sujet brûlant en 2024-2026. Premier basculement : les exigences Yahoo et Google de février 2024. Tout expéditeur supérieur à 5 000 emails par jour vers Gmail ou Yahoo doit publier SPF, DKIM et DMARC, avec un taux de spam Postmaster Tools inférieur à 0,3 % — sans ces contrôles, les emails sont silencieusement rejetés. Cette décision a touché des dizaines de milliers d'entreprises européennes et nord-américaines, dont beaucoup ont découvert à cette occasion qu'elles n'avaient absolument aucun de ces standards correctement configuré. Deuxième basculement : la directive NIS2 UE 2022/2555, transposée en droit français par la loi du 24 octobre 2024, qui impose à environ 160 000 entreprises européennes classées entités essentielles ou importantes un niveau de sécurité informatique incluant explicitement la résilience DNS, l'authentification email et le monitoring 24/7, avec reporting d'incident sous 24 heures et 72 heures, et sanctions pouvant atteindre 10 millions d'euros ou 2 % du chiffre d'affaires.

Troisième basculement : la multiplication des incidents BGP, DNS et email-borne médiatisés. L'incident Klay/Brewdog de 2024 a démontré l'utilisation de domaines tiers signés pour contourner DMARC strict. Le hijack DNS de Twilio Authy en juin 2024 résulte d'une compromission d'un compte registrar mal protégé. La compromission MGM Resorts de septembre 2023 inclut un faux DNS et de l'ingénierie sociale helpdesk. La panne Route 53 AWS US-East-1 de décembre 2024 a duré quatre heures. Et la vague de DKIM Replay attacks sur Gmail en 2024 a exposé une faiblesse de signature qui permet à un attaquant de réutiliser des signatures DKIM légitimes pour délivrer du spam authentifié au nom d'un domaine victime. Quatrième basculement : la finalisation des standards post-quantiques NIST FIPS 203 (ML-KEM) et FIPS 204 (ML-DSA) en août 2024, et le déploiement par Cloudflare et Google de l'algorithme hybride X25519MLKEM768 en TLS 1.3 production dès septembre 2024 — qui annonce une migration cryptographique majeure pour DNSSEC sur l'horizon 2027-2030.

Le triptyque attaque DNS : usurpation, interception, compromission

Les attaques exploitant le DNS se rangent en trois familles techniquement distinctes mais opérationnellement combinables. La première famille, l'usurpation d'identité par DNS, regroupe l'email spoofing sans DMARC (envoi de courriers forgés avec From: ceo@victim.com acceptés par les MTA destinataires en l'absence de politique stricte), la mis-issuance de certificats lorsque CAA est absent (n'importe quelle autorité de certification peut alors émettre un cert pour *.victim.com, comme l'ont démontré les incidents DigiNotar 2011 et Symantec EOL 2018), et le typosquatting par enregistrement de variantes incluant des homoglyphes IDN (viсtim.com avec un с cyrillique) qui rendent un phishing visuellement indiscernable de l'original. La deuxième famille, l'interception du transport, exploite l'absence de MTA-STS, de TLS-RPT ou de DANE pour mener des attaques STARTTLS strip où un attaquant en position adversary-in-the-middle (par compromission d'un ISP, hijack BGP court ou hotspot WiFi) supprime l'annonce STARTTLS dans le handshake SMTP et capture les emails en clair. La troisième famille, la compromission de l'infrastructure DNS elle-même, couvre le hijack registrar (compromission du compte client OVH, GoDaddy, Cloudflare avec changement des NS authoritatifs vers ceux de l'attaquant — voir le cas Sea Turtle 2019 ciblant des domaines gouvernementaux moyen-orientaux), le BGP hijack des préfixes IP des NS authoritatifs (cas Russie/Rostelecom 2017), le cache poisoning par bruteforce de l'identifiant de transaction (mitigation : DNSSEC plus DNS COOKIE) et le subdomain takeover.

Cette tripartition n'est pas qu'une commodité pédagogique : elle structure la méthodologie d'audit elle-même. Sur chaque domaine périmètre, l'auditeur doit produire un verdict de couverture pour les trois familles, et chaque finding doit être tracé à au moins une famille. Cette traçabilité permet au RSSI client de prioriser les remédiations en fonction de son modèle de menace — une PME B2B craint surtout le BEC (famille 1), un opérateur télécom craint surtout l'interception (famille 2), un État ou un grand groupe coté craint le hijack à grande échelle (famille 3). Pour une exploration approfondie du framework attaquant qui couvre ces trois familles avec ses techniques et procédures, nous renvoyons le lecteur à notre article de référence sur MITRE ATT&CK et la cartographie des TTPs 2026, qui détaille les identifiants T1583, T1584, T1098, T1557 et T1588 que nous mobiliserons en section kill chain.

Quinze ans d'évolution des standards DNS sécurité

L'histoire du DNS sécurité se découpe en quatre générations clairement identifiables, et un auditeur qui ne maîtrise pas cette stratification commet l'erreur de juger la conformité d'une zone selon des critères de la mauvaise génération. La génération zéro (1987-2000) est celle du DNS originel : RFC 1034 et 1035 de Mockapetris, simplicité fonctionnelle, aucune sécurité cryptographique des réponses. À cette époque les TLDs sont peu nombreux, Internet est académique, les attaques sont rares — la première faille notable est le DNS spoofing par prédiction de l'identifiant de transaction sur 16 bits, dont l'efficacité ne sera démontrée publiquement qu'avec l'attaque Kaminsky de 2008.

La première génération de sécurité (2000-2010) répond au spam massif et à la prise de conscience post-Kaminsky. SPF est standardisé en RFC 4408 (2006) avec sa limite de 10 lookups DNS et son mécanisme d'autorisation par IPs. DKIM apparaît en RFC 4871 (2007) puis RFC 6376 (2011) avec ses signatures cryptographiques RSA 1024 bits initialement, puis 2048 bits à partir de 2012. DNSSEC est finalisé par les RFC 4033 à 4035 (2005-2010), la racine est signée en juillet 2010, la zone .fr de l'AFNIC en 2010, la zone .com de Verisign en mars 2011 — mais l'adoption demeure inférieure à 1 % des domaines en 2015. TSIG (RFC 8945) sécurise les transferts AXFR entre serveurs, et DNS Cookies (RFC 7873) ajoutent une mitigation légère contre le cache poisoning.

La génération moderne (2010-2020) apporte les briques aujourd'hui indispensables. DMARC (RFC 7489, 2015) unifie SPF et DKIM avec une politique d'alignement adkim et aspf et un mécanisme de reporting rua et ruf. CAA (RFC 6844 puis 8659) permet à un domaine de déclarer en DNS quelles AC sont autorisées à émettre des certificats pour lui, et devient obligatoire pour toutes les AC depuis le 8 septembre 2017 (CA/B Forum BR §3.2.2.8). DANE (RFC 6698, 7671, 7672) combine DNSSEC avec un nouvel enregistrement TLSA pour valider les certificats TLS via DNS au lieu — ou en complément — des AC. MTA-STS (RFC 8461) et TLS-RPT (RFC 8460) en 2018 forcent l'utilisation de TLS pour le SMTP entre serveurs et fournissent un canal de feedback en cas d'échec.

La génération 2020-2026 (SOTA) est celle des contrôles que nous auditons aujourd'hui chez les clients matures. BIMI 1.0 (BIMI Group, 2020-2024) affiche un logo vérifié à côté des emails dans Gmail, Apple Mail iOS 16+, Yahoo et La Poste Mail — moyennant un VMC à 1 500 euros par an ou un CMC à 300 euros par an. ARC (RFC 8617) préserve l'authentification email au passage par des forwarders ou listes de diffusion qui modifient les headers. HTTPS RR et SVCB (RFC 9460, 2023) permettent la découverte de HTTP/3, le service binding et le support d'Encrypted Client Hello pour protéger le SNI. ZONEMD (RFC 8976) ajoute un hash global de la zone signée par DNSSEC pour détecter une corruption ou un transfert pirate. Et la finalisation NIST FIPS 203/204/205 d'août 2024 pose les bases d'une migration post-quantique de DNSSEC sur l'horizon 2027-2030. Les projets DKIM2 (draft IETF) et l'extension RPKI vers ASPA (RFC 9774, juillet 2024) complètent ce paysage en pleine évolution.

État chiffré des déploiements DNS sécurité en 2026

Pour calibrer un audit, l'auditeur doit avoir en tête les taux d'adoption réels — qui définissent ce qui est rare (et donc avantage compétitif), ce qui est attendu (et donc finding négatif si absent), et ce qui est marginal (et donc bonus). Le tableau ci-dessous synthétise les statistiques croisées d'ICANN, NLnetLabs, Google Postmaster Tools, internet.nl et de notre propre observation sur 200+ domaines audités sur 18 mois.

Standard	Mondial 2026	Top 1M Tranco	Entreprises FR	Verdict d'audit attendu
SPF (TXT v=spf1)	~70 %	~85 %	~75 %	Présence obligatoire
DKIM (≥1 sélecteur actif)	~60 %	~80 %	~55 %	Présence obligatoire
DMARC p=none	~30 %	~55 %	~20 %	Étape transitoire
DMARC p=quarantine ou reject	~12 %	~30 %	~8 %	Cible 2026
MTA-STS enforce	~3 %	~10 %	~2 %	Recommandé NIS2
TLS-RPT	~2 %	~7 %	~1 %	Recommandé
BIMI	~0,5 %	~2 %	~0,3 %	Différenciant marque
DNSSEC signé	~8 %	~15 %	~12 %	Recommandé ANSSI
DANE TLSA SMTP	~1 %	~5 %	~0,5 %	Différenciant maturité
CAA	~50 %	~70 %	~40 %	Quasi-obligatoire
HTTPS RR / SVCB	~5 %	~15 %	~3 %	Optionnel mais favorable

La conclusion qu'il faut tirer de ce tableau est que la majorité des organisations françaises sont en dette technique sur les standards 2020-2026, et que cette dette se concentre précisément sur les contrôles que NIS2 et les exigences Yahoo/Gmail rendent désormais obligatoires. C'est exactement ce constat qui rend l'audit DNS si productif aujourd'hui : le ratio remédiation rapide sur réduction de risque y est extrêmement favorable, contrairement à beaucoup d'autres domaines de la cybersécurité où les gains marginaux exigent des investissements massifs. Pour le RSSI, la séquence rationnelle consiste à commander un audit DNS, prioriser les findings selon les six kill chains que nous détaillerons plus loin, et exécuter le plan de remédiation 28 jours — l'investissement total dépasse rarement vingt jours-homme et les bénéfices en délivrabilité, anti-phishing et conformité NIS2 sont immédiats.

Méthodologie d'audit DNS en six phases

Une mission d'audit DNS professionnelle ne s'improvise pas. Sur les missions que nous conduisons, nous structurons systématiquement le travail en six phases distinctes — cadrage, collecte, analyse, rédaction, restitution, suivi — chacune avec ses livrables, ses risques opérationnels et ses checkpoints client. Cette structuration en phases répond à plusieurs exigences : couverture juridique de l'auditeur (la lettre de mission doit précéder tout test), traçabilité opérationnelle (chaque finding doit être daté et reproductible), valeur ajoutée pour le client (le rapport seul ne suffit pas, la restitution orale ancre les recommandations), et continuité défensive (un audit unique n'a aucune valeur si le client ne déploie pas un suivi mensuel et trimestriel ensuite).

Phase 1 — Cadrage et lettre de mission

La phase de cadrage couvre la période J-7 à J-1 et mobilise côté client le RSSI, le DSI, le ou les owners DNS (souvent un administrateur systèmes ou un responsable OPS), et idéalement la direction si l'audit s'inscrit dans une démarche NIS2. Côté auditeur, on aligne un lead auditeur et un à deux ingénieurs selon le périmètre. La réunion de cadrage doit aborder en bloc le périmètre — domaines apex, sous-domaines connus, IPs publiques, prestataires DNS (OVH, Cloudflare, Route 53, Azure DNS, AFNIC), services email (Exchange on-prem, Microsoft 365, Google Workspace, Zoho), SaaS émetteurs (Mailchimp, SendGrid, HubSpot, Brevo) — ; les objectifs (conformité NIS2, score internet.nl, posture défensive contre BEC, prérequis Yahoo/Gmail, certification ISO 27001) ; les contraintes (black-out periods comme une campagne email importante en cours, restrictions réglementaires comme la sous-traitance défense ou ITAR) ; et le niveau d'intrusivité autorisé.

Ce dernier point est critique. Certains tests d'audit DNS sont strictement passifs (lookups dig contre les NS publics, requêtes WHOIS et RDAP, parsing crt.sh) et ne nécessitent aucune autorisation particulière au-delà du contrat. D'autres sont semi-actifs et présentent un risque opérationnel léger (test AXFR — risque faible si refusé côté serveur, mais signal détectable en logs ; test open relay — risque réputation IP si la cible est mal configurée ; queries DNSBL — rate-limited mais traçables). D'autres enfin sont actifs et nécessitent une autorisation explicite signée (test de phishing simulé — haut risque, soumis aux régulations CNIL et au consentement employés ; bruteforce de sous-domaines à fort débit — peut déclencher des alertes IDS côté hébergeur). La lettre de mission doit lister précisément les cibles (domaines, IPs, services), la période d'exécution, les tests autorisés et exclus, le plan de notification incident en cours d'audit, le droit à la livraison et la confidentialité (NDA). Sans cette lettre signée, l'auditeur s'expose juridiquement à des accusations d'intrusion non autorisée — la jurisprudence française est claire depuis l'arrêt Kitetoa de 2002.

L'inventaire pré-audit complète le cadrage : le client fournit, ou à défaut l'auditeur reconstitue par OSINT, la liste des domaines apex (idéalement avec exports du compte registrar), l'inventaire des SaaS émetteurs email avec leurs sélecteurs DKIM préexistants, le schéma réseau du flux email (MX entrants, smarthost sortants, gateway anti-spam type Barracuda ou Vade), et l'architecture multi-tenant si applicable (M365 ou Google Workspace en mode multi-domaines). Pour les missions avec composante Active Directory intégrée, on récupère également la liste des comptes de service ayant des permissions sur les zones DNS internes — ce qui constitue un vecteur d'attaque distinct mais corrélé.

Phase 2 — Collecte multi-résolveur et OSINT

La phase de collecte démarre J+0 et produit le matériau brut sur lequel l'analyse va opérer. La technique fondatrice est la résolution DNS multi-résolveur : pour chaque domaine apex et sous-domaine connu, on requête tous les types d'enregistrements pertinents depuis quatre résolveurs publics distincts (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9, OpenDNS 208.67.222.222). Cette redondance permet de détecter les incohérences géographiques (un résolveur retourne des données différentes — symptôme potentiel d'un GeoDNS mal calibré ou d'une compromission), de vérifier la propagation des changements post-modification (utile en cours de remédiation), et de détecter les manipulations potentielles côté résolveur attaquant.

#!/bin/bash
# Script de collecte multi-résolveur — phase 2 audit DNS
DOMAINS=("example.fr" "exemple.com" "groupe-exemple.fr")
TYPES=("SOA" "NS" "A" "AAAA" "MX" "TXT" "CAA" "DNSKEY" "DS" "CDS" "CDNSKEY" "HTTPS" "SVCB" "TLSA")
RESOLVERS=("1.1.1.1" "8.8.8.8" "9.9.9.9" "208.67.222.222")

mkdir -p raw/
for D in "${DOMAINS[@]}"; do
  for T in "${TYPES[@]}"; do
    for R in "${RESOLVERS[@]}"; do
      echo "=== ${D} ${T} @${R} ==="
      dig @${R} ${D} ${T} +nocomments +noquestion +nostats +time=3 +tries=2
    done
  done
done > raw/all_records_$(date +%Y%m%d).txt

L'enrichissement WHOIS et RDAP fournit les métadonnées registrar : whois example.fr et curl -s https://rdap.org/domain/example.fr permettent de vérifier le Domain Status (présence ou absence de clientHold, redemptionPeriod, pendingDelete), la date d'expiration, les registrar locks (clientUpdateProhibited, clientTransferProhibited, clientDeleteProhibited) et le statut DNSSEC au niveau registry. L'énumération de sous-domaines combine techniques passives (sans toucher au DNS du client) et actives. Côté passif, on enchaîne subfinder -d example.fr -all -silent, amass enum -passive -d example.fr, assetfinder example.fr et un parsing crt.sh via curl -s "https://crt.sh/?q=%25.example.fr&output=json" | jq -r '.[].name_value' | sort -u. Côté actif, dnsrecon -t std -d example.fr, puredns bruteforce subdomains-all.txt example.fr et gobuster dns -d example.fr -w jhaddix-all.txt complètent la cartographie.

L'OSINT complémentaire extrait les informations difficiles à obtenir par DNS direct. Les CT-logs (crt.sh, Censys), le framework MITRE ATT&CK pour la qualification adversaire listent tous les certificats émis pour *.<domaine> historiquement — ce qui révèle souvent des sous-domaines internes ayant fui via la transparence des AC. Les bases de passive DNS commerciales (DNSDB Farsight, SecurityTrails, Mnemonic) reconstruisent l'historique des résolutions sur dix ans. La Wayback Machine de l'Internet Archive expose les sous-domaines cités dans des archives web. Les recherches GitHub et GitLab sur la chaîne <domaine> dans les repos publics révèlent souvent des configurations internes leakées par des développeurs négligents. Pastebin, leak databases et l'API HIBP fournissent l'inventaire des credentials fuités. Et les Google dorks (site:<domaine>, inurl:, filetype:pdf "@<domaine>") complètent la collecte.

Phase 3 — Analyse multi-niveau

L'analyse s'organise en cinq niveaux successifs (sections 4 à 8 ci-après), exécutés systématiquement par domaine et croisés transversalement. Pour chaque finding, l'auditeur produit cinq éléments structurés : description technique avec référence RFC précise et valeur observée versus valeur attendue ; sévérité graduée Critique / Haute / Moyenne / Faible / Info selon une grille qui croise l'impact technique et le contexte business ; impact business explicite (BEC potentiel, risque exfiltration, takeover, indisponibilité, non-conformité réglementaire) ; probabilité d'exploitation argumentée (existence de PoC public, classe d'attaquant requise, prérequis) ; recommandation de correction avec snippet DNS prêt et procédure step-by-step ; et référence MITRE ATT&CK quand applicable. Cette structuration en cinq éléments est non négociable — c'est elle qui transforme une liste de configuration en un rapport actionnable.

Phases 4 à 6 — Rédaction, restitution, suivi continu

La rédaction (J+4 à J+5) produit un rapport en Markdown versionnable, idéalement converti en PDF pour les destinataires non techniques. La structure type comporte une synthèse exécutive de deux pages (top findings, scoring sur 100 sur grille internet.nl ou hardenize), le périmètre et les données collectées, l'analyse détaillée par domaine, l'analyse transverse, les contrôles SOTA, les six kill chains MITRE évaluées, le plan de remédiation 28 jours, la checklist de contrôle, et les annexes (RFC référencées, outils utilisés, données brutes, scripts). La restitution orale (J+6) se découpe en une heure pour l'équipe technique avec démonstrations live des findings critiques, et trente minutes pour la direction avec verdict global, top trois risques, plan d'action et budget.

Le suivi continu est ce qui distingue un audit utile d'un audit décoratif. Hebdomadairement, on monitore les rapports DMARC RUA, les rapports TLS-RPT, et les alertes CT-logs sur émission de nouveaux certificats. Mensuellement, on fait tourner un score automatisé (mxtoolbox, hardenize, internet.nl) et un scan dnstwist pour détecter les nouveaux typosquats. Trimestriellement, on re-audite les niveaux 1 à 3 pour comparer à la baseline. Annuellement, on conduit l'audit complet cinq niveaux, on rote les clés DKIM, et on renouvelle le VMC ou CMC BIMI. Sans ce rythme, la dette technique repart à la hausse en six mois — nous l'avons vérifié sur plus de cinquante missions.

Niveau 1 — Hygiène DNS de base : SOA, NS, glue, FCrDNS

Le niveau 1 d'audit constitue le prérequis non négociable : aucun client ne peut prétendre déployer DMARC p=reject, DNSSEC ou DANE si son hygiène DNS de base est défaillante. Ce niveau couvre les enregistrements obligatoires (SOA, NS, A et AAAA, MX, PTR, FCrDNS, glue records), l'hygiène des serveurs de noms (refus AXFR, masquage version.bind, support EDNS0, anycast), la cohérence des TTL, le statut registrar EPP avec Registry Lock, et la chasse aux subdomain takeover et records dangling.

SOA, NS et cohérence parent-enfant

Le record SOA défini par RFC 1035 §3.3.13 contient les métadonnées de la zone. Format type observable :

example.fr. 86400 IN SOA dns10.ovh.net. tech.ovh.net. (
                  2026050801  ; serial — format YYYYMMDDnn recommandé RFC 1912 §2.2
                  86400       ; refresh (1 jour)
                  3600        ; retry (1 heure)
                  3600000     ; expire (~41 jours)
                  86400       ; minimum / negative TTL
                  )

Les vérifications auditeur portent sur le format serial (YYYYMMDDnn recommandé), le refresh raisonnable entre 3 600 et 86 400 secondes, le retry inférieur à refresh divisé par dix, l'expire compris entre sept jours et un mois, et le minimum ou negative TTL entre 300 et 3 600 secondes. Un SOA avec un serial à zéro, un expire d'un an ou un negative TTL d'une seconde signale une zone mal configurée — souvent par usage d'un panel registrar avec valeurs par défaut non revues.

Les NS authoritatifs doivent être au minimum deux (RFC 1034 §4.1), tous résolus en A et AAAA pour éviter une lame delegation, avec un SOA serial cohérent entre eux (delta inférieur à cinq minutes) et identiques entre les NS publiés par le parent (le registry) et ceux dans la zone enfant. Les glue records sont publiés si le NS est interne au domaine — typiquement ns1.example.fr IN A x.x.x.x publié dans le parent .fr. La commande de vérification de cohérence :

for NS in $(dig example.fr NS +short); do
  echo "$NS : $(dig @$NS example.fr SOA +short | awk '{print $3}')"
done

Si les serials divergent au-delà de cinq minutes, on a un problème de réplication entre primaire et secondaires — souvent lié à un AXFR cassé ou une notification DNS non émise. Si les NS publiés par le parent diffèrent de ceux dans la zone, on a un problème de stale delegation au registrar. Les deux findings sont de sévérité moyenne, à corriger sous sept jours.

Multi-fournisseurs DNS et résilience après l'incident Dyn

L'incident Dyn du 21 octobre 2016 reste l'archétype de la défaillance DNS à grande échelle : une attaque DDoS Mirai contre Dyn (fournisseur DNS managé pour Twitter, GitHub, Netflix, Spotify, Reddit, Airbnb, Heroku, Etsy, Box, Pinterest, PayPal, SoundCloud, Vox Media, Yelp et Zillow) a rendu environ sept millions de sites inaccessibles pendant six heures sur la côte est des États-Unis. Le constat opérationnel : aucune des entreprises touchées n'avait de NS authoritatif secondaire chez un autre fournisseur. Une politique multi-fournisseurs (par exemple OVH primaire + Hurricane Electric secondaire en mode AXFR slave gratuit, ou OVH primaire + Cloudflare Secondary à 5 dollars par mois) aurait fait passer l'incident inaperçu pour l'utilisateur final.

L'auditeur recommande systématiquement deux fournisseurs distincts pour les domaines critiques (chiffre d'affaires direct dépendant ou opérations 24/7), avec délégation à au moins quatre NS répartis sur les deux fournisseurs. Le primaire reste l'autorité de la zone, le secondaire transfère via AXFR avec authentification TSIG (RFC 8945) — ce qui pose le problème de la signature DNSSEC en environnement multi-signer (RFC 8901) que nous traiterons plus loin.

AXFR refusé et masquage version.bind

Le transfert de zone AXFR doit être strictement refusé aux clients non autorisés. Test :

dig @ns10.ovh.net example.fr AXFR
# Attendu : "; Transfer failed."

Si l'AXFR fonctionne contre un NS public, l'attaquant obtient l'intégralité de la zone — tous les sous-domaines internes, tous les records — ce qui est un finding critique systématiquement classé sévérité haute. La remédiation passe par allow-transfer { localhost; trusted-secondaries; }; dans named.conf pour BIND, ou le réglage équivalent côté OVH, AWS Route 53 ou Cloudflare. Pour un AXFR autorisé entre primaire et secondaire externe, l'authentification TSIG (RFC 8945) est obligatoire — pas d'IP allowlist seule, qui est usurpable par BGP hijack.

Le leak de version BIND ou NSD via la classe CHAOS doit également être bloqué :

dig @ns10.ovh.net version.bind TXT CHAOS
# Réponse leaky : "BIND 9.16.50-Ubuntu"
# Réponse propre : NO_DATA ou "(redacted)"

Configuration BIND recommandée pour masquer la version logicielle, le hostname et le server-id :

options {
    version "anonymous";
    hostname "anonymous";
    server-id "anonymous";
};

OVH par exemple retourne NO_DATA par défaut sur ses NS managés — c'est une bonne pratique. BIND 9 historique leak la version, et c'est à désactiver explicitement. Le finding est de sévérité faible mais systématique.

EDNS0 bufsize, DNS Flag Day et anycast

Depuis le DNS Flag Day 2020, les NS doivent supporter EDNS0 avec une bufsize supérieure ou égale à 1 232 octets, valeur conçue pour éviter la fragmentation IP en transit IPv6 sur Ethernet (1500 - 40 IPv6 - 8 UDP - 220 marge = 1232). Le DNS Flag Day 2024 ajoute des exigences sur le comportement face aux requêtes ANY (RFC 8482, qui standardise une réponse minimale) et sur la limitation de 4 096 octets UDP. Test pratique : dig @ns10.ovh.net +bufsize=4096 +dnssec example.fr ANY | grep "MSG SIZE". Une réponse en TC (truncated) avec basculement automatique en TCP est conforme — l'absence totale de réponse est un finding.

L'anycast est le standard de fait pour les NS authoritatifs de production. Il distribue le même préfixe IP sur plusieurs sites géographiques distincts via BGP, ce qui rend le service résilient aux DDoS volumétriques et améliore la latence utilisateur. Un audit qualifié vérifie que le NS est en anycast (au moins trois sites géographiques distincts), en double-stack IPv4 plus IPv6, et hébergé sur des AS distincts du primaire — pour mitiger un incident type Dyn 2016. La détection anycast s'effectue par traceroute multi-points : mtr -n -z <ns_ip> depuis trois pays différents, comparaison des routes finales — si elles convergent vers des PoP différents, l'anycast est probable.

Statut EPP et Registry Lock

L'ICANN définit neuf codes EPP de protection (RFC 5731 §2.3). Les plus critiques pour l'audit :

Code EPP	Effet	Recommandation auditeur
clientTransferProhibited	Bloque les transferts vers un autre registrar	Activer toujours (gratuit)
clientUpdateProhibited	Bloque les modifications zone et NS	Activer pour domaines critiques
clientDeleteProhibited	Bloque la suppression du domaine	Activer toujours
serverHold ou clientHold	Domaine retiré du DNS racine	NE DOIT PAS apparaître — incident
redemptionPeriod	Domaine expiré, en grâce 30 jours	URGENCE — renouveler
pendingDelete	Suppression définitive imminente (5 jours)	URGENCE absolue — racheter
pendingTransfer	Transfert en cours non sollicité	INVESTIGUER immédiatement

La distinction Registrar Lock versus Registry Lock est subtile mais fondamentale. Le Registrar Lock — gratuit, automatique chez la plupart des registrars — correspond au flag clientTransferProhibited côté registrar : il protège contre un transfert non sollicité, mais peut être levé par n'importe qui ayant accès au compte registrar. Le Registry Lock — payant, environ 50 euros par an — correspond au flag serverUpdateProhibited au niveau registry (AFNIC pour .fr, Verisign pour .com), qui ne peut être levé que via un appel téléphonique avec vérification d'identité forte. Toute modification (changement NS, renouvellement, transfert) nécessite une procédure hors-bande. C'est exactement ce qui aurait empêché l'incident Twitter de juillet 2020 où un employé victime d'un SIM-swap a débloqué les transferts du compte Twitter @Jack — Registry Lock aurait coupé court à la kill chain.

Subdomain takeover et records dangling : la chasse aux CNAME orphans

Un subdomain takeover survient quand un sous-domaine pointe via CNAME (ou A) vers un service tiers désactivé ou libérable. Exemple type : blog.example.com → CNAME oldcorp.github.io mais le repo GitHub oldcorp.github.io a été supprimé. Un attaquant peut alors créer un nouveau repo avec ce nom et héberger une page de phishing sur blog.example.com — avec certificat HTTPS valide via Let's Encrypt obtenu en moins d'une minute par challenge HTTP-01. Le sous-domaine apparaît parfaitement légitime visuellement, et héberge des credentials voleurs, des malwares ou un faux portail SSO. Test systématique :

# Énumération des CNAME externes
for SD in $(cat subdomains.txt); do
  TARGET=$(dig $SD CNAME +short | sed 's/\.$//')
  if [ -n "$TARGET" ]; then
    echo "$SD CNAME $TARGET"
  fi
done

# Détection automatique avec subzy et nuclei
subzy run --targets subdomains.txt
nuclei -t http/takeovers/ -l subdomains.txt

La liste des services connus pour subdomain takeover ne cesse de s'allonger : AWS S3, Heroku, GitHub Pages, Fastly, Shopify, Tumblr, WordPress.com, Zendesk, Netlify, Vercel, Azure CDN, Cargo, Surge.sh, Helprace, Unbounce, Tilda, Strikingly, Pingdom, JetBrains. La remédiation est triviale — supprimer le CNAME orphan — mais la détection exige un audit mensuel automatisé et une discipline d'inventaire : à chaque création de sous-domaine, on documente la propriété, la date de création, le service tiers cible, et la date de revue. C'est précisément le type de processus qu'une mission d'audit infrastructure formalise dans la documentation client.

Niveau 2 — Authentification email : SPF, DKIM, DMARC, ARC

Le niveau 2 est le plus dense de l'audit DNS, et le plus actuellement bouleversé par les exigences Yahoo et Gmail de 2024 et la transposition NIS2. Il couvre quatre standards complémentaires — SPF, DKIM, DMARC, ARC — plus deux extensions opérationnelles, NULL MX et List-Unsubscribe-Post, dont l'absence pénalise désormais la délivrabilité. La logique d'ensemble est simple à formuler mais subtile à exécuter : SPF autorise l'expéditeur réseau, DKIM authentifie la signature cryptographique, DMARC orchestre les deux avec une politique d'alignement et un canal de reporting, ARC préserve la chaîne en cas de forwarding. Sans les quatre, un attaquant peut usurper l'identité d'un domaine victime auprès de n'importe quel destinataire — le scénario CEO Fraud que nous détaillerons en kill chain.

SPF (RFC 7208) : limites strictes, void lookups et flattening

SPF publie en TXT à l'apex la liste des sources autorisées à émettre du courrier au nom du domaine. Format minimal observable :

example.fr. IN TXT "v=spf1 ip4:57.128.13.197 include:mx.ovh.com -all"

Le récepteur, lors de la réception d'un email, fait un lookup du SPF du domaine MAIL FROM (l'adresse de l'enveloppe SMTP, pas du header From:), vérifie si l'IP source de l'email est autorisée, et si non applique le qualificateur final : -all signifie reject, ~all signifie soft fail, ?all signifie neutral, +all signifie pass (équivalent à pas de SPF — à proscrire). Les limites strictes définies par le RFC sont d'au maximum 10 lookups DNS — incluant les include, redirect, a, mx, exists, ptr — et au maximum 2 void lookups (queries qui retournent NXDOMAIN ou NODATA). Un seul record SPF est autorisé par domaine (RFC 7208 §3.2) : la présence de deux TXT commençant par v=spf1 rend la configuration invalide selon la spec, et certains récepteurs vont rejeter, d'autres ignorer le second, d'autres appliquer le premier — comportement non déterministe.

Les erreurs courantes que nous auditons en mission incluent : la présence de records SPF multiples (résultat fréquent de la cohabitation entre l'ancien provider et le nouveau lors d'une migration M365 mal finie) ; l'utilisation de +all qui autorise n'importe quelle IP ; le qualificateur ~all au lieu de -all qui laisse passer du soft fail souvent accepté quand même ; le mécanisme ptr déconseillé par le RFC 7208 §5.5 car lent et fragile ; et surtout le dépassement de la limite des 10 lookups par chaînage include récursif (l'exemple classique étant _spf.google.com qui inclut _netblocks.google.com qui inclut...). La limite des 10 lookups est extrêmement facile à dépasser : un client avec M365, un service marketing Mailchimp, un service transactionnel SendGrid, un service support HubSpot et un Salesforce dépasse souvent les 10 lookups si tous sont en include.

La technique de remédiation pour les zones complexes est le SPF flattening : on résout statiquement tous les include en ip4: au moment de la publication, ce qui élimine les lookups récursifs côté récepteur. L'inconvénient est que la liste IP doit être régénérée chaque fois que les inclus changent (les ranges IP de Mailchimp, SendGrid, HubSpot évoluent régulièrement), ce qui implique soit un script automatisé via cron qui interroge les include et republie, soit un service tiers comme Valimail Enforce, EasyDMARC ou Easy365Manager qui fait la maintenance pour environ 50 à 200 euros par mois selon le volume. Le SPF flattening manuel sans automatisation est un anti-pattern : six mois après le déploiement, l'IP ranges des inclus ont divergé, et les emails légitimes commencent à être rejetés sans alerte.

NULL MX pour les domaines non émetteurs

Un domaine sans email — typiquement un domaine apex utilisé uniquement pour le redirect 301 vers le domaine principal — doit publier un NULL MX (RFC 7505) :

example-redirect.com. IN MX 0 .
example-redirect.com. IN TXT "v=spf1 -all"
_dmarc.example-redirect.com. IN TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-rua@example.com"

Les MTAs conformes RFC 7505 retournent immédiatement un code 550 pour les emails vers ce domaine, sans tester les A records (anti-fallback RFC 5321 §5.1). C'est une mitigation cruciale contre l'usurpation d'un domaine non émetteur que les attaquants utilisent fréquemment pour leurs campagnes BEC : ils ciblent un domaine secondaire de la victime (un ancien domaine, un domaine de campagne marketing) qui n'a pas SPF/DKIM/DMARC parce qu'il "ne sert pas à envoyer d'email", et l'utilisent pour usurper l'identité auprès des partenaires.

DKIM (RFC 6376) : tags, sélecteurs, oversigning et anti-replay

L'expéditeur signe les headers de l'email avec sa clé privée DKIM. La clé publique correspondante est publiée en TXT dans le DNS à l'emplacement <selector>._domainkey.<domain> :

ovh._domainkey.example.fr. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4..."

Le récepteur extrait le header DKIM-Signature:, récupère la clé publique via DNS au sélecteur indiqué, recalcule la signature et compare. Les tags critiques sont récapitulés ci-dessous :

Tag	Description	Recommandation auditeur 2026
v=	Version DKIM	1
a=	Algorithme signature	rsa-sha256 ou ed25519-sha256 — jamais rsa-sha1
c=	Canonicalization	relaxed/relaxed
d=	Domaine signataire	Doit aligner avec From: pour DMARC
s=	Sélecteur	Unique par émetteur, daté de préférence
h=	Headers signés	Oversigning From/Subject/Date/To/Reply-To/Message-ID
bh=	Body hash	Auto
b=	Signature	Auto
t=	Timestamp	Recommandé
x=	Expiration	Recommandé 7 jours (anti-replay)
l=	Body length	NE PAS UTILISER — autorise ajout de contenu

Le choix de l'algorithme est aujourd'hui structurant. RSA 1024 bits est proscrit (ANSSI 2024, attaques théoriques type ROCA). RSA 2048 bits est le minimum 2026. RSA 4096 bits est sur-sécurisé mais peut poser des problèmes de TXT record dépassant 512 octets nécessitant une concaténation par TXT chunks. Ed25519 (RFC 8032) sur 256 bits offre une signature compacte, plus rapide à valider, et une sécurité équivalente à RSA 3000 bits — c'est l'algorithme recommandé pour les nouvelles configurations 2026, à condition que tous les MTA récepteurs principaux le supportent (Microsoft 365 a longtemps eu un support partiel, désormais correct depuis 2023).

La rotation DKIM est recommandée annuellement par l'ANSSI et la plupart des référentiels. La procédure type comporte cinq étapes : générer un nouveau sélecteur (par exemple ovh-2027 à partir de ovh-2026) ; publier la clé publique correspondante en TXT ; configurer le MTA pour signer désormais avec le nouveau sélecteur ; conserver l'ancien sélecteur publié pendant 30 jours pour couvrir les emails en transit dans des queues ; supprimer l'ancien sélecteur. Cette discipline n'est jamais maintenue spontanément — elle exige un cron documenté avec rappel calendaire RSSI.

Le scandale DKIM Replay 2024 et les contre-mesures opérationnelles

L'année 2024 a exposé une faiblesse opérationnelle majeure de DKIM. Le scénario, illustré par plusieurs incidents médiatisés impliquant Mailgun, Resend et d'autres, est le suivant : un attaquant capture un email signé DKIM légitimement par victim.com (par exemple un email transactionnel automatique), puis le ré-émet en masse vers ses propres victimes. Si la signature DKIM couvre uniquement From + Subject + Date — configuration par défaut de nombreux MTA — l'attaquant peut modifier To, Reply-To, List-* sans invalider la signature. Résultat : un email de spam signé DKIM par victim.com, qui passe DMARC, atteint la boîte de réception, et discrédite la marque victime aux yeux de Gmail Postmaster Tools.

Les contre-mesures sont au nombre de trois et doivent être déployées conjointement. Premièrement, l'interdiction stricte de l= dans la configuration DKIM — ce tag autorise une longueur partielle du body, et donc l'ajout de contenu sans invalider la signature. Deuxièmement, le tag x= à 7 jours qui force une expiration de la signature, limitant la fenêtre de replay (un attaquant capture un mail en mai, ne peut plus l'utiliser en juin). Troisièmement, l'oversigning des headers critiques : on inclut deux fois les headers sensibles dans h=, ce qui les "scelle" et interdit leur ajout après signature. Configuration MTA recommandée :

h=From:From; Subject:Subject; Date:Date; To:To; Reply-To:Reply-To; Message-ID:Message-ID; MIME-Version:MIME-Version; List-Unsubscribe:List-Unsubscribe

La présence d'un header dans h= deux fois indique au MTA récepteur de considérer la signature invalide si ce header est ajouté postérieurement. Cette configuration est aujourd'hui le standard de fait pour toute organisation maturé en 2026 — Postfix, Exim et OpenDKIM la supportent nativement, M365 nécessite une action de configuration post-déploiement.

DMARC (RFC 7489) : l'orchestrateur de l'authentification email

DMARC publie une politique en TXT à _dmarc.<domaine> :

_dmarc.example.fr. IN TXT "v=DMARC1; p=reject; sp=reject; np=reject; adkim=s; aspf=s; pct=100; fo=1:d:s; rua=mailto:dmarc-rua@example.fr"

Le récepteur, après avoir vérifié SPF et DKIM, compare l'alignement : SPF aligné si le domaine du MAIL FROM SMTP correspond au domaine du From: header ; DKIM aligné si le domaine d= de la signature DKIM correspond au domaine du From:. DMARC est OK si SPF aligné OU DKIM aligné. Sinon, il applique la politique p=. Les tags critiques :

Tag	Description	Recommandation cible 2026
v=DMARC1	Version	Obligatoire en premier
p=	Politique apex	reject (cible après quarantine)
sp=	Politique sous-domaines	reject
np= (RFC 9091)	Politique sous-domaines inexistants	reject
pct=	Pourcentage application	100
adkim=	Alignement DKIM	s strict (après vérification)
aspf=	Alignement SPF	s strict
fo=	Forensic options	1:d:s
rua=	Rapports aggregates	mailto:dmarc-rua@<domaine>
ruf=	Rapports forensics	Optionnel — RGPD attention
ri=	Reporting interval	86400 (24h)

La progression DMARC en quatre étapes que nous appliquons systématiquement en mission est la suivante :

J+1   _dmarc  TXT "v=DMARC1; p=none; pct=100; rua=..."
J+14  Analyse rapports : identifier les émetteurs légitimes manquants en SPF/DKIM
J+14  _dmarc  TXT "v=DMARC1; p=quarantine; pct=10; rua=..."
J+21  _dmarc  TXT "v=DMARC1; p=quarantine; pct=100; rua=..."
J+28  _dmarc  TXT "v=DMARC1; p=reject; sp=reject; np=reject; adkim=s; aspf=s; pct=100; fo=1:d:s; rua=..."

Cette progression en quatre paliers permet d'observer en RUA les émetteurs légitimes oubliés (presque toujours présents : un service RH SaaS, un outil de monitoring, un newsletter), de corriger leur configuration SPF/DKIM, puis de durcir la politique sans casser le métier. Sauter directement à p=reject sans phase d'observation est l'erreur classique qui produit un incident métier majeur en quelques heures — typiquement la blocage des notifications RH, des invitations clients, ou des notifications SaaS.

RGPD et DMARC RUA : un sujet souvent oublié

Les rapports XML aggregates DMARC peuvent contenir des métadonnées identifiables (IP source de l'émetteur, count d'emails, dates, sélecteurs DKIM utilisés). RGPD article 28 impose un DPA — Data Processing Agreement — avec tout sous-traitant. En pratique, un audit RSSI doit privilégier les services UE-base comme URIports (Pays-Bas) ou EasyDMARC EU plutôt que DMARCian US ou Valimail US qui exigent un transfert hors-UE soumis aux clauses contractuelles types post-Schrems II. L'auto-hébergement reste une option robuste avec parsedmarc plus PostgreSQL plus Grafana — c'est ce que nous déployons pour les clients aux contraintes ITAR ou DGAC Part-IS. La conservation des rapports doit être limitée à 13 mois maximum (durée RGPD standard), et l'anonymisation du ruf= forensic est recommandée si les emails contiennent des données sensibles.

ARC pour les forwarders et listes de diffusion

ARC (RFC 8617) résout un problème historique de DMARC : les forwarders et listes de diffusion modifient les headers (Subject: avec préfixe [liste], body avec footer ajouté), ce qui invalide DKIM et donc DMARC. ARC ajoute trois headers à chaque hop forwarder : ARC-Authentication-Results qui copie les résultats SPF/DKIM/DMARC vus en entrée, ARC-Message-Signature qui signe les headers (DKIM-like), et ARC-Seal qui signe les ARC-* précédents. Le récepteur final, voyant ARC-Seal cv=pass, sait que la chaîne d'authentification a été préservée — même si DKIM apex est cassé par modification body en cours de route.

ARC s'active côté MTA forwarder (Postfix avec OpenARC, Exchange via filtre, M365 supporte nativement), pas côté DNS. Au niveau DNS, il faut publier les sélecteurs comme pour DKIM. C'est un control SOTA encore peu déployé en 2026 — moins de 5 % des domaines Top 1M selon nos mesures — mais pertinent pour les organisations gérant des listes internes ou des forwarders entre filiales.

Niveau 2bis — MTA-STS, TLS-RPT et BIMI

MTA-STS (RFC 8461) force le SMTP entrant à utiliser TLS, même en l'absence de DANE et de DNSSEC, en publiant une politique HTTPS authentifiée. Le mécanisme combine trois éléments : un record DNS TXT à _mta-sts.<domaine> qui annonce une id et la version STSv1 ; une politique HTTPS servie à https://mta-sts.<domaine>/.well-known/mta-sts.txt avec le mode (none, testing, enforce), la liste des MX autorisés, et un max_age en secondes ; et un certificat valide sur le sous-domaine mta-sts servant la policy.

# DNS
_mta-sts.example.fr. IN TXT "v=STSv1; id=20260507120000Z"

# https://mta-sts.example.fr/.well-known/mta-sts.txt
version: STSv1
mode: enforce
mx: mx0.mail.ovh.net
mx: mx1.mail.ovh.net
max_age: 604800

Les modes opérationnels sont none (cancellation, transition pour retirer MTA-STS), testing (monitoring sans rejet, recommandé en initial 14 jours), et enforce (rejet des MX non listés ou TLS rate). La transition testing vers enforce doit se faire après vérification que les MTAs partenaires émettent correctement les rapports TLS-RPT — sans cette vérification on s'expose à un blocage métier sur la communication B2B.

TLS-RPT (RFC 8460) complète MTA-STS en fournissant un canal de feedback. Configuration :

_smtp._tls.example.fr. IN TXT "v=TLSRPTv1; rua=mailto:tls-rua@example.fr"

Les MTAs conformes envoient un rapport JSON quotidien des échecs STARTTLS — handshake fail, cert expiré, MTA-STS violation, certificat non aligné. Ces rapports sont précieux pour détecter les tentatives de STARTTLS strip que nous décrirons en kill chain : une vague soudaine de starttls.not.supported depuis un partenaire habituel signale un MITM en cours.

BIMI : afficher le logo de marque vérifié dans Gmail et Apple Mail

BIMI (Brand Indicators for Message Identification) affiche un logo vérifié à côté des emails dans Gmail, Apple Mail iOS 16+, Yahoo et La Poste Mail. Les prérequis sont stricts : DMARC p=quarantine ou reject actif sur le domaine et les sous-domaines (sp=), DKIM aligné, logo SVG conforme SVG Tiny PS (Profile Tiny plus Portable Subset) sans scripts, sans animations, sans liens externes, format carré 1:1, et certificat de marque (VMC à 1 500 euros par an avec trademark INPI/EUIPO/USPTO requis, ou CMC à 300 euros par an introduit en 2023 sans nécessiter de trademark — usage supérieur à 12 mois suffit).

default._bimi.example.fr. IN TXT "v=BIMI1; l=https://example.fr/bimi/logo.svg; a=https://example.fr/bimi/vmc.pem"

BIMI est encore marginal en 2026 (environ 0,5 % des domaines mondiaux), mais son adoption croît rapidement chez les banques, le retail, les gouvernements — visibilité de marque plus anti-phishing visuel. Pour une organisation qui a déjà tout DMARC et MTA-STS en place, le ROI BIMI s'évalue à environ 300 à 1 500 euros par an pour un gain de notoriété et une réduction du phishing visuel difficile à quantifier mais réel.

Niveau 3 — Intégrité cryptographique : DNSSEC, DANE, CAA

Le niveau 3 protège l'intégrité même des réponses DNS et des certificats émis pour le domaine. DNSSEC ajoute des signatures cryptographiques aux records DNS, validables par le résolveur. DANE publie en DNS le hash du certificat TLS attendu, ancrant la confiance dans la zone signée. CAA déclare en DNS quelles AC sont autorisées à émettre des certs pour le domaine, prévenant la mis-issuance. ZONEMD ajoute un hash global de la zone elle-même. DNS COOKIE durcit le canal entre client et serveur DNS.

DNSSEC : algorithmes 2026, rollover KSK/ZSK et NSEC3

DNSSEC ajoute trois types d'enregistrements à la zone : DNSKEY (clé publique de la zone, structurée en KSK plus ZSK), RRSIG (signature de chaque RRset), DS (digest de la KSK publié dans la zone parente, ce qui ferme la chaîne de confiance), et NSEC ou NSEC3 (preuve cryptographique de la non-existence d'un record). La chaîne de confiance va de la racine — signée depuis le 15 juillet 2010 — vers le TLD vers le domaine. Pour .fr, l'AFNIC signe depuis 2010, et environ 12 % des domaines .fr sont signés au niveau registry en 2026.

Les algorithmes recommandés en 2026 (RFC 8624 et ANSSI 2024) sont l'algorithme 13 (ECDSA P-256 plus SHA-256) et l'algorithme 15 (Ed25519). Les algorithmes 5 et 7 (RSA-SHA1) sont proscrits depuis la démonstration de collision SHA-1 par Google en 2017. L'algorithme 8 (RSA-SHA256) est toléré mais recommandé pour migration. Les algorithmes 14 (ECDSA P-384) et 16 (Ed448) sont optionnels — sur-sécurisés pour la plupart des cas. La taille de signature ECDSA P-256 (64 octets) ou Ed25519 (64 octets) est nettement plus compacte que RSA 2048 (256 octets), ce qui réduit la taille des réponses DNS et améliore la performance — argument secondaire mais non négligeable sur des NS à fort trafic.

La gestion KSK / ZSK distingue deux clés : la KSK (Key Signing Key) signe les DNSKEY records, est long-terme avec un rollover annuel ou biennal selon RFC 7583. La ZSK (Zone Signing Key) signe les autres records, est court-terme avec un rollover trimestriel à annuel. Cette séparation permet de roter la ZSK fréquemment sans toucher au DS publié au registry. OVH gère le rollover automatiquement post-activation DNSSEC, et publie automatiquement les CDS et CDNSKEY (RFC 7344) qui permettent au registrar de mettre à jour le DS sans intervention manuelle — un mécanisme cruciale pour les rollovers d'urgence en cas de compromission de clé.

NSEC versus NSEC3 : NSEC permet la zone walking, c'est-à-dire l'énumération de tous les records de la zone par chaînage NSEC successifs — donc non recommandé pour les zones publiques où l'on souhaite éviter la divulgation des sous-domaines internes. NSEC3 hashe les noms (SHA-1 itéré, salt rotatif), ce qui empêche le walking direct mais reste vulnérable à du bruteforce hors ligne. La RFC 9276 recommande des iterations inférieures ou égales à 100 — au-delà la charge CPU côté résolveur devient prohibitive. La meilleure pratique 2026 : NSEC3 avec opt-out désactivé, iterations à 0 ou 1, salt rotatif à chaque ZSK rollover.

DANE TLSA : pinner le certificat dans la zone signée

DANE (DNS-Based Authentication of Named Entities, RFC 6698) publie des records TLSA qui contiennent un hash du certificat ou de la clé publique du serveur. Le client TLS valide le certificat réel contre ce hash. Format type pour SMTP :

_25._tcp.mail.example.fr. IN TLSA 3 1 1 abcdef0123456789...

Les paramètres sont quatre : Usage (0 PKIX-TA, 1 PKIX-EE, 2 DANE-TA, 3 DANE-EE — recommandé pour SMTP) ; Selector (0 Cert, 1 SPKI — recommandé) ; Matching (0 Full, 1 SHA-256 — recommandé, 2 SHA-512) ; Data (le hash). Le mode 3 1 1 (DANE-EE plus SPKI plus SHA-256) est l'option opérationnelle de référence : il permet une rotation de certificat sans réémission DNS tant que la clé publique reste identique, et il ignore les AC publiques au profit du trust DNS direct.

Le prérequis absolu : DNSSEC doit être actif sur la zone, sinon TLSA n'est pas opposable (un MITM peut forger les records TLSA en absence de signature DNSSEC). DANE TLSA SMTP est adopté massivement par les domaines néerlandais (plus de 50 % des domaines émetteurs .nl) et reste rare en France (environ 0,5 %). Microsoft 365 ne supporte pas DANE en réception en 2026 — limitation pour les hybrides M365 qui doivent prévoir un détour par MTA-STS pour la même finalité. Le calcul du hash SPKI à publier :

openssl x509 -in /etc/ssl/exchange.crt -pubkey -noout |
  openssl pkey -pubin -outform DER |
  openssl dgst -sha256 -binary |
  od -An -tx1 | tr -d ' \n'

CAA : restreindre l'émission de certificats par AC

CAA (RFC 8659, 8657) publie en DNS quelles autorités de certification sont autorisées à émettre des certificats pour le domaine. Configuration recommandée :

example.fr. IN CAA 0 issue     "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12345; validationmethods=dns-01"
example.fr. IN CAA 0 issue     "sectigo.com"
example.fr. IN CAA 0 issuewild ";"
example.fr. IN CAA 0 iodef     "mailto:security@example.fr"
example.fr. IN CAA 0 contactemail "security@example.fr"

Les AC sont obligatoirement tenues de vérifier CAA depuis le 8 septembre 2017 (CA/B Forum Baseline Requirements §3.2.2.8). Les tags d'extension RFC 8657 sont précieux : accounturi= bind l'émission au compte ACME spécifique — empêche un autre compte Let's Encrypt ou ZeroSSL d'émettre même avec la même AC ; validationmethods=dns-01,http-01 restreint les méthodes de validation autorisées (utile pour interdire HTTP-01 si on craint un BGP hijack court). Les tags RFC 8659 §4.1.3 ajoutent contactemail et contactphone — point de contact en cas d'émission douteuse, utile pour le canal IODEF.

L'auditeur vérifie également la tree-walking CAA : si mail.example.fr n'a pas de CAA propre, le résolveur remonte à example.fr — ce qui est généralement le comportement souhaité. On ne surcouche que si une AC différente doit être autorisée pour un sous-domaine spécifique. Le finding le plus fréquent en mission est l'absence totale de CAA, observée sur environ 60 % des domaines français — c'est un pré-requis kill chain mis-issuance que nous détaillerons.

Niveau 4 — État de l'art 2026 : HTTPS RR, ECH, RPKI, DoQ

Le niveau 4 couvre les standards récents (2020-2026) qui ne sont pas encore obligatoires mais constituent l'avantage compétitif des organisations matures. Quatre familles structurent ce niveau : la découverte et performance (HTTPS RR / SVCB, ECH), la protection BGP (RPKI plus ASPA), la confidentialité DNS (DoT / DoH / DoQ), et la lecture post-quantique.

HTTPS RR / SVCB et Encrypted Client Hello

HTTPS RR et SVCB (RFC 9460, standardisés en 2023) sont des nouveaux types de records DNS qui permettent la découverte directe de capacités de service au niveau DNS. Format :

example.fr. IN HTTPS 1 . alpn="h2,h3" port=443 ipv4hint=213.186.33.2 ech="..."

Trois effets opérationnels : auto-découverte de HTTP/3 sur QUIC sans round-trip Alt-Svc ; service binding alternatif (le client peut joindre directement www.example.fr sans passer par un 302 depuis example.fr) ; support d'ECH (Encrypted Client Hello, RFC 9180) qui chiffre le SNI dans le ClientHello TLS 1.3, empêchant un MITM ou un censeur de voir quel domaine est consulté. Cloudflare déploie ECH à grande échelle depuis 2023, Firefox depuis 2024, Chrome depuis 2024. Pour le client : aucune action, le mécanisme est transparent. Pour le serveur : configurer la ECHConfigList dans le record HTTPS DNS, et activer ECH au niveau du reverse proxy ou du load balancer.

Adoption en 2026 : environ 5 % des domaines mondiaux publient un HTTPS RR, principalement les sites Cloudflare-fronted où c'est automatique. Pour un audit, l'absence de HTTPS RR n'est pas un finding négatif — sa présence est un bonus de maturité. La bascule structurelle viendra probablement quand Chromium imposera HTTPS RR pour le préchargement HTTP/3 — annonce attendue 2027.

RPKI et ASPA — protection BGP

RPKI (Resource Public Key Infrastructure, RFC 6480) authentifie l'origine des annonces BGP de préfixes IP. Une ROA (Route Origin Authorization) déclare publiquement quel AS est autorisé à annoncer un préfixe. Pour les clients hébergés (OVH, AWS, Cloudflare), RPKI est géré par l'hébergeur — c'est dans l'audit l'occasion de vérifier que les ROA sont publiées au RIPE, ARIN ou APNIC selon la région. Pour les entreprises avec leur propre AS — typiquement les grandes ETI, les opérateurs télécom, les universités — RPKI est à configurer chez le RIR (Réseau IP Régional). Vérification rapide via le service Team Cymru :

dig 197.13.128.57.origin.asn.cymru.com TXT +short
# Sortie type : "16276 | 57.128.0.0/17 | FR | ripencc | 2010-08-23"

ASPA (RFC 9774, juillet 2024) étend RPKI à la validation du chemin AS, pas seulement l'origine. Là où RPKI valide que l'AS qui annonce le préfixe est bien autorisé, ASPA valide que la séquence d'AS du chemin BGP est cohérente — détecte donc les route leaks (annonces incorrectes mais avec origine valide). En 2026, ASPA est en phase d'adoption précoce : RIPE déploie l'infrastructure, les premiers grands opérateurs (Cloudflare, Google) commencent à valider. Pour un audit, c'est encore une veille — pas un finding actionable.

DoT, DoH, DoQ sur NS authoritatifs

DNS over TLS (RFC 7858, port 853 TCP), DNS over HTTPS (RFC 8484, port 443 TCP), DNS over QUIC (RFC 9250, port 853 UDP) chiffrent les requêtes DNS pour protéger la confidentialité contre l'ISP ou l'observation réseau. Côté résolveurs publics — 1.1.1.1, 8.8.8.8, 9.9.9.9 — DoT et DoH sont largement déployés depuis 2020. Côté NS authoritatifs, c'est encore rare en 2026 : RFC 9230 standardise le DoH authoritatif depuis 2022, mais OVH, AWS Route 53 et Cloudflare DNS authoritatif ne le supportent pas encore en production. À surveiller : annonce 2026-2027 par les grands fournisseurs.

Post-Quantum readiness

NIST a finalisé en août 2024 trois algorithmes post-quantiques : FIPS 203 (ML-KEM, ex Kyber, encapsulation de clé), FIPS 204 (ML-DSA, ex Dilithium, signature digitale), FIPS 205 (SLH-DSA / SPHINCS+, signature long-terme hash-based). Cloudflare et Google déploient X25519MLKEM768 (TLS 1.3 hybrid KEM) en production depuis septembre 2024 — c'est un hybride RSA/ECDH classique plus ML-KEM, transparent pour les clients qui supportent au moins X25519. Pour DNSSEC, l'IETF travaille sur des drafts ML-DSA mais aucun standard n'est finalisé en 2026. Pour DKIM, l'horizon ML-DSA est plus lointain (2028+) en raison de la taille de signature qui pose problème dans les TXT records.

Pour l'audit, la posture post-quantique consiste à : vérifier que les fournisseurs (M365, OVH, AWS, Azure) annoncent un calendrier de migration ; documenter dans le rapport la veille à conduire ; ne pas considérer comme finding actionable l'absence de PQ — sauf pour des organisations à très long horizon de confidentialité (défense, renseignement, brevet) où le risque "harvest now, decrypt later" mérite une attention spécifique.

Niveau 5 — Hardening transverse : MTA, web, well-known, reputation

Le niveau 5 sort du strict périmètre DNS pour couvrir les contrôles transverses qui dépendent du DNS (PTR, FCrDNS) ou qui le complètent (HSTS preload, security.txt, reputation IP). Cette section est volontairement plus rapide en passant en revue les contrôles : pour un approfondissement par composant nous renvoyons à nos articles spécialisés.

Hardening MTA et SMTP

Au-delà de SPF, DKIM, DMARC, MTA-STS, l'audit MTA couvre le banner SMTP minimaliste sans version logicielle, la désactivation de VRFY et EXPN qui permettaient un info-leak utilisateurs, le test open relay (un MAIL FROM externe plus RCPT TO externe doit être rejeté en 5xx), l'activation STARTTLS sur les ports 25, 587, 465, le support TLS 1.3 recommandé avec TLS 1.2 minimum, l'élimination des cipher suites RC4, 3DES, EXPORT, NULL et anonymes, la cohérence FCrDNS (PTR matche HELO plus roundtrip A), le HELO/EHLO en FQDN — pas en IP literal, le greylisting anti-spam basique, les ports submission 587 et 465 avec AUTH SASL, et IMAPS 993 plus POP3S 995 sans IMAP/POP3 clair.

Hardening web : HSTS preload, CSP, COOP/COEP

Les headers HTTP de sécurité obligatoires en 2026 :

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-...';
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), camera=(), microphone=()
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Resource-Policy: same-origin
Cross-Origin-Opener-Policy: same-origin

HSTS preload exige trois conditions : header HSTS sur le site avec max-age supérieur ou égal à 31 536 000 plus includeSubDomains plus preload ; tous les sous-domaines en HTTPS uniquement ; soumission sur hstspreload.org. Attention : preload est irréversible à l'échelle du navigateur (cache 1+ an minimum). Avant soumission, l'auditeur doit vérifier la couverture HTTPS de tous les sous-domaines, y compris les sous-domaines internes — un sous-domaine dev en HTTP cassera après preload.

Fichiers /.well-known/

RFC 9116 standardise security.txt comme canal de divulgation responsable des vulnérabilités. Format :

Contact: mailto:security@example.fr
Contact: https://example.fr/.well-known/security
Expires: 2027-05-08T00:00:00.000Z
Encryption: https://example.fr/pgp-key.txt
Acknowledgments: https://example.fr/security/hall-of-fame
Preferred-Languages: fr, en
Canonical: https://example.fr/.well-known/security.txt
Policy: https://example.fr/security/policy

À signer PGP, la clé publique étant hébergée sur le même site et publiée en OPENPGPKEY DNS (RFC 7929). Autres fichiers /.well-known/ couverts : /.well-known/change-password (RFC 8615, UX security pour password managers), /.well-known/openpgpkey/ (Web Key Directory), /.well-known/jwks.json (si OIDC provider), /apple-app-site-association et /.well-known/assetlinks.json (si apps mobiles).

Reputation, threat intel et typosquatting

L'hygiène de réputation IP couvre la vérification des IPs émettrices clean sur Spamhaus ZEN (SBL plus CSS plus PBL via Datafeed Query Service), SpamCop, Barracuda, SORBS, UCEPROTECT et CBL/abuseat. Les domaines doivent être clean sur Spamhaus DBL, SURBL, URIBL, Cisco Talos. Le monitoring CT-log via crt.sh API doit alerter sur tout cert non prévu pour *.<domaine>. Microsoft SNDS donne la réputation IP côté Outlook/Hotmail, Google Postmaster Tools côté Gmail, Yahoo Sender Hub côté Yahoo. PhishTank et OpenPhish complètent le monitoring de marque.

Le typosquatting et le brand monitoring exigent un scan dnstwist mensuel (typos, bit-flip, IDN homograph), une pré-emption défensive des typosquats critiques (environ 250 euros par an pour 10 domaines pour les variantes proches), une évaluation TLD-squatting sur .com, .io, .app, .eu, et un monitoring CT-log brand pour alerter sur tout cert pour une variante. La procédure UDRP ou SYRELI doit être documentée pour les recours à froid, et un trademark déposé (INPI, EUIPO, USPTO) active les recours juridiques en cas de cybersquatting massif.

Six kill chains MITRE ATT&CK exploitant les défauts DNS

Cette section opérationnalise la lecture défensive en présentant six kill chains génériques que tout auditeur évalue systématiquement contre la configuration observée. Chaque kill chain combine plusieurs findings d'audit, est mappée à des identifiants MITRE ATT&CK précis, et a sa contre-mesure technique principale.

Kill chain 1 — CEO Fraud / BEC (T1583.001 + T1566.002 + T1657)

Scénario : un attaquant envoie un email forgé au nom du PDG de l'entreprise victime, vers un partenaire ou fournisseur. Le partenaire, croyant à un email légitime, transfère des fonds sur un IBAN attaquant. Findings DNS exploités : DMARC absent ou p=none ; DKIM absent ou non aligné ; typosquat enregistré par l'attaquant comme victim-supplier.fr ; pas de monitoring CT-logs côté victime. Séquence : reconnaissance OSINT pour identifier le PDG et ses partenaires fournisseurs (LinkedIn, communiqués de presse, leak email *@victim.com sur HIBP) ; acquisition d'un typosquat ou usage direct du domaine victim ; setup MTA attaquant (Postfix sur VPS, MAIL FROM externe) ; forge email avec From: "CEO Name" <ceo@victim.com>; Reply-To: ceo@victim-airbus.fr; Subject: URGENT - Changement IBAN fournisseur ; envoi vers comptable@partenaire.com ; sans DMARC reject l'email passe les filtres ; transfert frauduleux. MITRE ATT&CK : T1583.001 Acquire Infrastructure Domains, T1585.002 Establish Accounts Email, T1566.002 Phishing Spearphishing Link Service, T1657 Financial Theft. Mitigation primaire : DMARC p=reject plus monitoring RUA plus pré-emption typosquats critiques.

Kill chain 2 — Subdomain takeover (T1584.001 + T1583.001 + T1566.002)

Scénario : un sous-domaine pointe via CNAME vers un service tiers désactivé. L'attaquant reprend le service tiers et héberge une page de phishing avec certificat HTTPS valide (Let's Encrypt en une minute). Findings exploités : CNAME orphan vers S3 bucket libéré ; pas de monitoring DNS automatique ; pas de CAA strict avec accounturi=. Séquence : énumération sous-domaines (Subfinder, crt.sh, passive DNS) ; test CNAME externes pour détecter le S3 bucket ou Heroku app inexistants ; reprise du service en créant un nouveau bucket avec le même nom ; hébergement de la page de phishing ; obtention d'un certificat Let's Encrypt par challenge HTTP-01 sur le sous-domaine ; diffusion du lien (email phishing, forum, SEO, ads). MITRE ATT&CK : T1584.001 Compromise Infrastructure Domains, T1583.001 Acquire Infrastructure, T1566.002 Phishing Spearphishing Link. Mitigation : audit CNAME mensuel plus alerte CT-log plus CAA accounturi= plus suppression CNAME orphans systématique post-désactivation service tiers.

Kill chain 3 — Domain redemption hijack (T1583.001 + T1584.001)

Scénario : un domaine de l'entreprise victime expire (paiement non passé, oubli de renouvellement, départ du gestionnaire). Après 30 jours de redemption period plus 5 jours de pending delete, il est dropped et acheté par un attaquant. Findings exploités : auto-renew défaillant ; pas de Registry Lock ; pas de monitoring expiration domaine ; domaine présent dans CT-logs et passive DNS pour services historiques. Séquence : veille des expirations sur ICANN drop-catching services (Snapnames, Dropcatch) ; backorder du domaine ; si drop, acquisition immédiate (environ 10 dollars plus frais drop-catch) ; setup DNS pointant vers infrastructure attaquant ; obtention de certificats Let's Encrypt automatiques ; hébergement du portail phishing identique à l'original (le rebrand du site original se fait à partir des archives wayback). MITRE ATT&CK : T1583.001 Acquire Infrastructure, T1584.001 Compromise Infrastructure réacquisition. Mitigation : Registry Lock plus auto-renew avec carte valide vérifiée trimestriellement plus alerte 90/60/30 jours expiration.

Kill chain 4 — STARTTLS downgrade (T1557.002 + T1090.003 + T1040)

Scénario : MITM actif (compromission ISP, hotspot WiFi, BGP hijack court) entre le MX victime et le MX destinataire. L'attaquant strip STARTTLS dans le handshake SMTP et capture les emails en clair. Findings exploités : MTA-STS absent (pas de policy enforce) ; TLS-RPT absent (pas de détection) ; DANE TLSA absent (pas de pinning DNSSEC). Séquence : position MITM acquise (BGP hijack court, ISP compromis, exit node Tor adversaire) ; interception SMTP avec strip STARTTLS dans la réponse 250 ; capture des emails en clair (devis, contrats, IBAN, brevets) ; ré-injection des emails vers le destinataire réel (relay transparent) ; pas d'alerte côté victime puisque TLS-RPT absent. MITRE ATT&CK : T1557.002 Adversary-in-the-Middle, T1090.003 Proxy Multi-hop, T1040 Network Sniffing, T1114.003 Email Forwarding Rule. Mitigation : MTA-STS enforce plus TLS-RPT plus DANE (avec DNSSEC).

Kill chain 5 — Mis-issuance certificat / MITM HTTPS (T1583.003 + T1588.005 + T1557)

Scénario : sans CAA, n'importe quelle AC peut émettre un cert pour victim.com. L'attaquant exploite une mauvaise validation côté AC, ou un BGP hijack court, pour obtenir un certificat sur sa propre infrastructure. Findings exploités : CAA absent ; pas de monitoring CT-logs ; DNSSEC absent (DANE-EE non opposable). Séquence : hijack BGP court (environ 5 minutes) du préfixe contenant l'IP du serveur web victime ; demande cert ACME (Let's Encrypt) pour mail.victim.com ; HTTP-01 challenge dirigé vers attaquant via BGP ; cert obtenu signé valide ; position MITM sur la victime (ISP compromis, WiFi hotspot, exit node) ; interception sessions OWA / ownCloud / portail interne. MITRE ATT&CK : T1583.003 Acquire Infrastructure VPS, T1588.005 Obtain Capabilities Code Signing Certs, T1557 Adversary-in-the-Middle, T1539 Steal Web Session Cookie. Mitigation : CAA strict plus accounturi= plus monitoring CT-log plus HSTS preload.

Kill chain 6 — DNS hijack au registrar (T1078 + T1556.006 + T1584.002)

Scénario : compromission du compte registrar (phishing employé, SIM-swap, leaked password). L'attaquant change les NS authoritatifs vers les siens et héberge un MX qui capture les emails entrants — déclenchant alors un reset de tous les comptes critiques par "forgot password". Findings exploités : pas de 2FA registrar ; pas de Registry Lock ; pas d'alertes sur changement de zone ; trail d'audit registrar inférieur à un an. Séquence : phishing un employé ayant accès registrar (LinkedIn → email pretexting "alerte sécurité OVH") ; capture credentials → accès registrar ; changement NS authoritatifs vers attaquant (24-48h propagation TTL) ; setup MX attaquant → tous les emails entrants capturés ; reset des comptes critiques (M365, banque, GitHub, AWS) via "Forgot password" → réception du token chez l'attaquant ; compromission complète. MITRE ATT&CK : T1078 Valid Accounts, T1556.006 Modify Authentication MFA Bypass, T1584.002 Compromise Infrastructure DNS Server, T1098.005 Account Manipulation Device Registration. Mitigation : 2FA FIDO2 registrar (pas SMS) plus Registry Lock plus alerting changements zone plus 4-eyes principle pour modifications critiques.

Synthèse comparée des six kill chains DNS

Kill chain	MITRE primaire	Findings prérequis	Contre-mesure
1. CEO Fraud / BEC	T1583.001 + T1566.002 + T1657	DMARC absent / p=none	DMARC p=reject + RUA
2. Subdomain takeover	T1584.001 + T1583.001	CNAME orphan	Audit CNAME mensuel
3. Redemption hijack	T1583.001 + T1584.001	Auto-renew défaillant	Registry Lock + alertes
4. STARTTLS downgrade	T1557.002 + T1040	MTA-STS absent	MTA-STS enforce + TLS-RPT
5. Mis-issuance cert	T1583.003 + T1588.005	CAA absent	CAA strict + CT monitoring
6. Registrar hijack	T1078 + T1584.002	2FA faible	FIDO2 + Registry Lock

Dans une mission d'audit, l'auditeur produit pour chaque kill chain un verdict structuré : exploitable (tous les findings prérequis sont présents), partiellement mitigée (un seul finding manque), ou bloquée (la contre-mesure est en place et opérationnelle). Ce verdict est le cœur de la synthèse exécutive — il transforme une liste technique en un récit défensif intelligible par la direction. Pour aller plus loin sur le framework MITRE et son utilisation en defense, nous renvoyons à notre article complet sur MITRE ATT&CK et les TTPs 2026.

Compliance : NIS2, RGPD, ANSSI, Part-IS

L'audit DNS s'inscrit en 2026 dans un cadre réglementaire de plus en plus contraignant qui définit non plus seulement de bonnes pratiques mais des obligations juridiquement opposables. Quatre référentiels structurent ce cadre pour les organisations françaises et européennes.

NIS2 Directive UE 2022/2555

Transposée en France par la loi du 24 octobre 2024, la directive NIS2 s'applique à environ 160 000 entreprises européennes classées entités essentielles ou entités importantes. Les entités essentielles (énergie, finance, santé, transport, eau potable, infrastructures numériques critiques) doivent une sécurité informatique au plus haut niveau, un reporting d'incident sous 24 heures (early warning) puis 72 heures (rapport détaillé), un audit de conformité régulier, et s'exposent à des sanctions pouvant atteindre 10 millions d'euros ou 2 % du chiffre d'affaires global. Les entités importantes (industrie manufacturière, sous-traitance critique, services numériques) ont un niveau de sécurité proportionné, un reporting 72 heures, et des sanctions jusqu'à 7 millions d'euros ou 1,4 % du chiffre d'affaires.

Les implications DNS de NIS2 sont explicitées par les guides ANSSI 2024-2025 : DMARC est obligatoire (anti-phishing), DNSSEC est fortement recommandé (intégrité), monitoring 24/7 est attendu, plan de continuité DNS documenté est exigé. Pour une exploration approfondie de NIS2 et de ses implications opérationnelles, nous renvoyons à notre article dédié à la directive NIS2 et la cybersécurité qui détaille les annexes techniques, les organismes désignés en France et les calendriers de mise en conformité.

RGPD et DMARC RUA

Les rapports XML aggregates DMARC contiennent des métadonnées identifiables (IP source, count emails, dates, sélecteurs DKIM utilisés). RGPD article 28 impose un DPA (Data Processing Agreement) avec tout sous-traitant. Recommandations pratiques : privilégier services UE-base (URIports Pays-Bas, EasyDMARC EU) ; signer un DPA explicite ; envisager auto-hosting parsedmarc plus PostgreSQL pour les contraintes ITAR ou défense ; anonymiser ruf= (forensic) si données sensibles ; conservation rapports inférieure ou égale à 13 mois (durée RGPD standard). Le finding "RUA hébergé hors-UE sans DPA Schrems II compatible" est devenu de plus en plus fréquent en mission, et de plus en plus pénalisant lors d'audits de conformité.

ANSSI et OIV

L'ANSSI publie depuis 2024 un Guide DNS complet recommandant DNSSEC algo 13 ou 15, DKIM RSA 2048+ ou Ed25519 avec rotation annuelle, DMARC p=reject après phase de monitoring, MTA-STS enforce avec TLS-RPT, hébergement DNS sous SecNumCloud pour les OIV. Les OIV (Opérateurs d'Importance Vitale, environ 250 entreprises en France) doivent passer un audit PASSI avec scope DNS si applicable. Les recommandations RGS s'imposent pour les administrations.

DGAC et Part-IS aviation civile

Le règlement UE 2023/203 applicable depuis février 2026 pour les ATO (Approved Training Organisation), AOC (Air Operator Certificate) et organismes Part-IS impose un ISMS (Information Security Management System) conforme, un reporting incidents sous 72 heures, un email auth et DNSSEC documentés, un audit annuel. Concerne les compagnies aériennes, les ATO formation, et les prestataires Part-IS en sous-traitance maintenance ou navigation. Le scope DNS y est explicite — la cyber-résilience aviation civile sort en 2026 du domaine de la recommandation pour entrer dans le domaine de la certification opérationnelle.

ITAR/EAR et industries réglementées

Pour les exports défense vers ou via USA, ITAR/EAR exige un hébergement DNS hors-USA si données ITAR, des clés DKIM hors-USA, un cloud souverain (SecNumCloud, Bleu, Sens). PCI DSS 4.0 §A2.1.x impose la protection contre le phishing (DMARC reject) pour les commerçants. HIPAA Privacy Rule (santé US) exige un audit DNS et email pour les Business Associates Agreements. ISO 27001:2022 §A.5.10 impose un inventaire actifs incluant les domaines, §A.8.20 la protection réseaux DNS hardening, §A.5.21 la gestion supply chain.

Plan d'action recommandé : remédiation en 28 jours

Le plan de remédiation type que nous appliquons en mission se découpe en quatre phases successives sur 28 jours pour un domaine apex moyennement complexe (1 à 5 émetteurs SaaS, M365 ou Google Workspace, un site web principal). Le calendrier est dimensionnant : phase 0 d'urgence sous 48 heures, phase 1 d'authentification email J+1 à J+7, phase 2 de transport TLS J+8 à J+14, phase 3 d'intégrité et SOTA J+15 à J+28. BIMI vient en option à J+45+ après l'achat éventuel du VMC ou CMC.

Phase	Durée	Thèmes	Effort homme	Coût licence
0 — Urgence	< 48 heures	Domaine en redemption, Registry Lock, comptes registrar 2FA	2 heures	50 €/an Registry Lock
1 — Email auth	J+1 à J+7	DMARC monitor, DKIM, SPF durci, NULL MX	2 jours	0 € (services M365/Google inclus)
2 — Transport	J+8 à J+14	MTA-STS, TLS-RPT, CAA, HSTS preload	2 jours	0 €
3 — Intégrité + SOTA	J+15 à J+28	DNSSEC, DANE, BIMI prep, HTTPS RR, SSHFP, NS secondaire	3 jours	0 € (HE.net gratuit)
BIMI optionnel	J+45+	Logo SVG + VMC/CMC	1 jour	300 € CMC ou 1 500 € VMC/an

Phase 0 — Urgence sous 48 heures

Cette phase couvre les actions vitales qui ne peuvent attendre la phase 1. Sauvetage d'un domaine en redemption period : sur le panel registrar (OVH Manager → Domaines → Renouveler), payer les frais ICANN d'environ 80 à 100 dollars HT, vérifier sous 24-48 heures que whois retire clientHold, réactiver l'auto-renouvellement. Activation Registry Lock plus 2FA : panel sécurité du registrar, activer 2FA TOTP minimum (FIDO2 idéal), demander Registry Lock payant (~50 euros/an) si domaine critique, définir alertes 90/60/30 jours. NULL MX et DMARC reject sur domaines non émetteurs :

example-redirect.com. IN MX 0 .
example-redirect.com. IN TXT "v=spf1 -all"
_dmarc.example-redirect.com. IN TXT "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc-rua@example.com"

Phase 1 — Email authentication J+1 à J+7

Provisionner les boîtes RUA et TLS-RPT (boîte partagée M365 ou Google Workspace, ou service tiers RGPD-friendly URIports / EasyDMARC EU). Déployer DMARC p=none à J+1 :

_dmarc.example.com. IN TXT "v=DMARC1; p=none; pct=100; adkim=r; aspf=r; rua=mailto:dmarc-rua@example.com; fo=1"

Activer DKIM par plateforme. Microsoft 365 :

Connect-ExchangeOnline
New-DkimSigningConfig -DomainName example.com -KeySize 2048 -Enabled $false
Get-DkimSigningConfig -Identity example.com | Select Selector1CNAME, Selector2CNAME
# Publier les CNAME dans la zone DNS
Set-DkimSigningConfig -Identity example.com -Enabled $true

Google Workspace : Admin Console → Apps → Google Workspace → Gmail → Authenticate email → Generate new record (sélecteur google) → publier la clé publique en TXT → Start authentication. OVH Mail : panel OVH → Emails → DKIM activated (sélecteur ovh). Exchange on-prem : installer DKIM Signer (open-source), générer clé 2048 bits, configurer le sélecteur, publier en TXT.

Durcir SPF : retirer les include: non utilisés, éliminer le mécanisme ptr, passer ~all en -all, vérifier inférieur à 10 lookups via spf-record.com. DKIM hardening anti-replay : c=relaxed/relaxed, t= timestamp présent, x= expiration ~7 jours, h= oversigning From/Subject/Date/To/Reply-To/Message-ID, pas de l=. Progression DMARC : J+14 quarantine pct=10, J+21 quarantine pct=100, J+28 reject sp=reject np=reject adkim=s aspf=s pct=100 fo=1:d:s.

Phase 2 — Transport TLS J+8 à J+14

MTA-STS : créer sous-domaine mta-sts.example.com A → serveur web HTTPS, déposer fichier https://mta-sts.example.com/.well-known/mta-sts.txt en mode testing initial, publier TXT _mta-sts.example.com avec v=STSv1; id=<datetime>Z, après 14 jours en testing basculer en enforce. TLS-RPT :

_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-rua@example.com"

CAA enrichi :

example.com. IN CAA 0 issue     "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/; validationmethods=dns-01"
example.com. IN CAA 0 issue     "sectigo.com"
example.com. IN CAA 0 issuewild ";"
example.com. IN CAA 0 iodef     "mailto:security@example.com"
example.com. IN CAA 0 contactemail "security@example.com"

HSTS preload : header Strict-Transport-Security: max-age=63072000; includeSubDomains; preload, soumission sur https://hstspreload.org/. TLS 1.3 plus cipher hardening : activer TLS 1.3 côté Exchange/Apache/Nginx, désactiver TLS 1.0/1.1 et SSLv2/v3, cipher suites ECDHE plus AEAD (GCM ou ChaCha20), éliminer RC4/3DES/EXPORT/NULL/anon/MD5.

Phase 3 — Intégrité et SOTA J+15 à J+28

DNSSEC : OVH Manager → Domaine → DNSSEC → Activer (algo 13 ECDSA P-256). DS publié automatiquement dans .fr sous 24-48 heures. Vérification :

dig +dnssec example.com SOA | grep "ad "    # AD-flag présent
dig example.com DS +short                    # algo 13 digest 2

CDS / CDNSKEY auto-rollover : OVH les publie automatiquement post-DNSSEC. DANE TLSA pour SMTP : calculer le hash SPKI (commande openssl ci-dessus en niveau 3), publier les TLSA pour 25, 587, 465. SSHFP pour serveurs SSH :

ssh-keyscan -p 22 -D 

host. IN SSHFP 1 2 
host. IN SSHFP 4 2 

Documentation utilisateur : ajouter VerifyHostKeyDNS yes au ~/.ssh/config client. HTTPS RR / SVCB : example.com. IN HTTPS 1 . alpn="h2,h3" port=443 ipv4hint=..., prérequis HTTP/3 actif sur le serveur web. NS secondaire externe : ajouter HE.net gratuit ou Cloudflare Secondary, créer slave zone, master IP = NS principal OVH, autoriser AXFR egress chez OVH vers les IPs HE.net, mettre à jour la délégation registrar (4 NS au lieu de 2). BIMI optionnel J+45+ : logo SVG Tiny PS valide, hosting https://example.com/bimi/logo.svg, achat VMC ou CMC, hosting https://example.com/bimi/vmc.pem, TXT BIMI publié.

Outillage 2026 : la boîte à outils complète

Un audit DNS productif s'appuie sur une combinaison d'outils ligne de commande FOSS et de services en ligne. Le tableau ci-dessous synthétise notre boîte à outils 2026, dont la maîtrise est requise pour conduire les missions efficacement.

Outil	Catégorie	Usage principal
dig (BIND)	CLI résolution	Référence universelle, multi-résolveur, DNSSEC trace
kdig (Knot)	CLI résolution	DoT, DoQ, DoH côté résolveur authoritative
dnsx (ProjectDiscovery)	CLI bulk	Bulk lookups en parallèle, énumération sous-domaines
dnstwist	CLI typosquat	Détection typos, bit-flip, IDN homograph
dnsrecon	CLI énumération	std/brt/axfr en un seul outil
subzy + nuclei takeovers	CLI takeover	Détection automatique CNAME orphans
swaks	SMTP test	Envoi email arbitraire pour test SPF/DKIM/DMARC
testssl.sh	TLS audit	Audit TLS profond, ciphers, certs
openssl s_client	TLS handshake	STARTTLS SMTP, OCSP stapling, DANE TLSA validation
mxtoolbox.com	Web service	DMARC/SPF/DKIM/MTA-STS lookup rapide
internet.nl	Web service	Score complet 2026, référentiel NLnetLabs
hardenize.com	Web service	Score TLS+DNS+Email continu
dnsviz.net	Web service	Visualisation graphique chaîne DNSSEC
crt.sh	Web service	Recherche CT-logs historique
OctoDNS / DNSControl	DNS-as-Code	Multi-provider, versioning Git, peer review
parsedmarc	Self-host	Parser RUA Python, intégration PostgreSQL
Wazuh	SIEM	Corrélation logs DNS, alerting changements zone

L'orchestration en DNS-as-Code via Terraform OVH provider, OctoDNS ou DNSControl est ce qui distingue une équipe DNS mature d'une équipe artisanale : versioning Git, peer review obligatoire sur chaque PR, CI/CD avec validation named-checkzone avant déploiement, rollback en un commit. Sans cette discipline, la zone DNS dérive lentement et les écarts ne sont détectés qu'à la prochaine mission d'audit. Pour les organisations à forte criticité, le couplage avec un SIEM type Wazuh ou Microsoft Defender XDR permet d'alerter en temps réel sur tout changement de zone non planifié — un signal très précieux contre la kill chain 6 (registrar hijack).

FAQ — questions fréquentes en mission d'audit DNS

Pourquoi DMARC p=none est-il dangereux à long terme ?

DMARC p=none est l'étape transitoire qui permet de collecter les rapports RUA pour identifier les émetteurs légitimes oubliés avant de durcir la politique. Maintenu indéfiniment, il offre exactement aucune protection : un attaquant peut spoofer le domaine sans aucune conséquence côté récepteur. Pire, l'organisation publie publiquement p=none ce qui signale aux attaquants qu'elle ne fait pas appliquer DMARC — un facilitateur explicite de campagnes BEC. La règle d'or : p=none dure entre 14 et 30 jours maximum, jamais plus. Si l'organisation n'arrive pas à passer en quarantine après 30 jours, c'est qu'il y a un problème opérationnel à creuser (émetteur SaaS non identifié, configuration M365 cassée), pas une excuse pour rester en p=none indéfiniment.

DNSSEC casse-t-il quelque chose côté client ?

Non, à condition que la zone soit correctement signée et que le rollover de clés soit géré (manuellement ou automatiquement via CDS/CDNSKEY). Les incidents DNSSEC publics (par exemple SiriusXM en 2019, plusieurs banques européennes en 2020-2022) sont systématiquement liés à des erreurs opérationnelles : signature expirée, KSK non rotée, DS désynchronisé entre parent et enfant, NSEC3 mal configuré. La maintenance DNSSEC est environ deux fois plus exigeante que la maintenance DNS classique — mais pour une zone gérée par un fournisseur compétent (OVH, Cloudflare, AWS Route 53, AFNIC), le risque opérationnel est mitigé. Côté client, aucun navigateur ni resolver ne casse sur DNSSEC mal configuré — la pénalité est juste le retour SERVFAIL pour les résolveurs validants (1.1.1.1 valide, 8.8.8.8 valide, Quad9 valide).

MTA-STS ou DANE — que choisir ?

Les deux. Ils sont complémentaires, pas alternatifs. MTA-STS protège contre STARTTLS strip sans nécessiter DNSSEC — adoption rapide, déploiement en deux jours. DANE TLSA protège contre la mis-issuance certificat ET STARTTLS strip, mais nécessite DNSSEC. Sur la roadmap remédiation 28 jours, on déploie MTA-STS en phase 2 (sans prérequis DNSSEC), puis DANE en phase 3 (post-DNSSEC). Si le contexte ne permet pas DNSSEC (cas rare en 2026 mais existant — par exemple une zone déléguée sur un registrar legacy sans support DNSSEC), MTA-STS seul couvre 80 % du risque STARTTLS downgrade.

Comment migrer un SPF qui dépasse 10 lookups ?

Trois options. Premièrement, le nettoyage : supprimer les include: historiques d'émetteurs SaaS qui ne sont plus utilisés (Mailchimp d'il y a 5 ans, SendGrid abandonné, ancien CRM). Souvent on récupère 3 à 5 lookups en revue inventaire. Deuxièmement, le flattening manuel avec script cron : un script Python interroge les include: SPF, résout les ranges IP, republie un SPF flatten en ip4:. À recompiler quotidiennement. Troisièmement, le service tiers : Valimail Enforce, EasyDMARC, Easy365Manager facturent 50 à 200 euros par mois et maintiennent le SPF flatten automatiquement avec dynamic resolution. Pour les organisations à faible volume, l'option 1 plus 2 reste préférable. Pour les organisations à forte complexité (10+ émetteurs SaaS), l'option 3 amortit son coût en réduisant le risque de panne email.

Le DNS sur HTTPS (DoH) est-il vraiment privé ?

Partiellement. DoH (RFC 8484) chiffre les requêtes DNS entre le client et le résolveur, ce qui empêche l'ISP ou un observateur réseau de voir les noms de domaines consultés. Mais le résolveur lui-même (Cloudflare, Google, Quad9) voit toujours toutes les requêtes — la confidentialité est déplacée, pas supprimée. Pour une vraie confidentialité DNS, il faut combiner DoH plus Oblivious DoH (RFC 9230) plus ECH au niveau TLS. En pratique, pour un usage entreprise, le bénéfice DoH est de bypasser un ISP hostile (FAI peu fiable, hotspot WiFi public, censure régionale) — pas d'obtenir une confidentialité absolue. Et côté entreprise, DoH rend plus difficile le filtrage DNS interne (proxy DNS d'entreprise pour bloquer phishing/malware) — d'où la tendance récente à déployer Encrypted DNS interne avec son propre résolveur DoH/DoT.

Combien coûte un audit DNS professionnel ?

Pour une PME française avec 1 à 5 domaines apex et un parc M365 ou Google Workspace standard, un audit DNS plus le rapport plus la restitution se situe entre 4 500 et 9 000 euros HT, soit 5 à 12 jours-homme selon la complexité. Pour une ETI avec 10 à 30 domaines, plusieurs SaaS émetteurs, hybrides M365/Exchange, le budget est de 12 000 à 25 000 euros HT. Pour un grand groupe avec 100+ domaines, infrastructure DNS interne, et exigences NIS2 ou Part-IS, le budget est dans la fourchette 40 000 à 100 000 euros HT — mais sur ces structures l'audit DNS s'inscrit généralement dans une mission plus large d'audit infrastructure. Le ROI est très favorable : un seul incident BEC évité (perte type 50 000 à 500 000 euros) couvre largement le coût de l'audit. Pour explorer notre offre d'audit infrastructure ou notre service de RSSI externalisé, vous pouvez nous contacter via le formulaire dédié.

ZONEMD remplace-t-il DNSSEC ?

Non — ZONEMD complète DNSSEC. Là où DNSSEC signe individuellement chaque RRset (avec RRSIG), ZONEMD ajoute un hash global de la zone entière, lui-même signé par DNSSEC. Cela permet de détecter une corruption ou un transfert pirate qui modifierait des records sans casser une RRSIG individuelle (par exemple un transfert AXFR détourné qui réinjecterait des records altérés). En 2026 ZONEMD est encore peu déployé (moins de 1 % des domaines signés) et reste optionnel — l'auditeur le mentionne comme bonus de maturité, pas comme finding obligatoire.

Quels signaux indiquent une compromission DNS en cours ?

Cinq signaux majeurs à monitorer : (1) un changement de NS authoritatif non planifié dans whois ou dig NS — souvent le premier signe d'un hijack registrar ; (2) un SOA serial qui recule ou diverge entre primary et secondary — soit une erreur de réplication soit une attaque ; (3) une augmentation soudaine des rapports DMARC RUA en provenance d'IPs inconnues — symptôme de campagne de spoofing en cours ; (4) une vague de starttls.not.supported en TLS-RPT depuis un partenaire habituel — symptôme de MITM STARTTLS strip ; (5) une émission de certificat non prévue détectée en CT-log monitoring (crt.sh) — symptôme de mis-issuance ou de subdomain takeover. Tous ces signaux doivent déclencher une alerte SOC immédiate vers le RSSI et idéalement vers une équipe de réponse incident. Pour une approche structurée du SOC et de la détection, nous renvoyons à notre article sur la suite Microsoft Defender XDR et à notre article sur Wazuh comme plateforme XDR SIEM open source.

Conclusion : du score 30/100 au score 85/100 en 28 jours

L'audit DNS en 2026 est un exercice complexe et riche, qui couvre cinq niveaux (résolution, authentification email, intégrité cryptographique, état de l'art, hardening transverse) et fait référence à plus de trente-cinq RFC actives. Sa criticité est rehaussée par les exigences Yahoo et Gmail de 2024 sur DMARC et DKIM, par la transposition NIS2 d'octobre 2024 qui touche 160 000 entreprises européennes, par les standards SOTA finalisés en 2023-2024 (HTTPS RR, ASPA, DoQ, ML-KEM/ML-DSA), et par les incidents BEC, subdomain takeover et DKIM replay qui ont défrayé l'actualité depuis 18 mois. Un audit professionnel suit une méthodologie en six phases — cadrage, collecte, analyse, rédaction, restitution, suivi — et utilise une boîte à outils combinant FOSS (dig, kdig, openssl, testssl.sh, dnstwist, swaks) et services en ligne (mxtoolbox, internet.nl, hardenize, dnsviz, crt.sh).

Le livrable type comprend la synthèse exécutive (top findings, scoring sur 100), le détail par domaine, l'analyse transverse (NS hardening, MTA, web, /.well-known/), les six kill chains MITRE évaluées, le plan de remédiation 28 jours, les modes opératoires step-by-step, la checklist de contrôle de 280 items. Le plan de remédiation se décline en phase 0 d'urgence (Registry Lock plus 2FA), phase 1 d'authentification email (DMARC, DKIM, SPF), phase 2 de transport TLS (MTA-STS, CAA, HSTS preload, TLS 1.3), phase 3 d'intégrité et SOTA (DNSSEC, DANE, BIMI, NS secondaire). L'objectif final mesurable est de passer d'un score de 30/100 typique observé en début de mission à un score de 85/100 ou plus sur internet.nl, conforme aux standards 2026 et résilient face aux six kill chains documentées.

Le DNS, longtemps considéré comme un détail technique invisible, est devenu un domaine de bataille majeur entre attaquants et défenseurs. Un audit DNS rigoureux suivi d'un plan de remédiation soutenu est aujourd'hui un investissement rentable face aux risques de phishing, BEC, subdomain takeover, mis-issuance certificat et indisponibilité opérationnelle. La prochaine génération de standards — DKIM2 en draft IETF, ECH en déploiement Cloudflare et Google, ML-DSA pour DNSSEC à l'horizon 2027-2030 — appelle à une veille active que tout RSSI doit intégrer dans son programme de sécurité. Si vous souhaitez approfondir l'évaluation de votre exposition DNS et engager une mission d'audit avec restitution, plan de remédiation et accompagnement opérationnel, vous pouvez consulter notre offre d'audit infrastructure ou notre service de RSSI externalisé qui inclut le suivi mensuel des rapports DMARC/TLS-RPT et l'alerting CT-log. Pour les organisations en démarche NIS2 ou Part-IS aviation civile, nous proposons des missions cadrées sur les exigences réglementaires spécifiques. La cybersécurité du DNS n'est plus un sujet pour spécialistes : c'est désormais un actif stratégique au cœur de la résilience numérique de toute organisation moderne.