Checklist d'Audit DNS SOTA 2026

Checklist d'Audit DNS — SOTA 2026

Référentiel : NIST SP 800-177 · M3AAWG · RFC 9989 (DMARCbis, mai 2026) · NIS2 · ISO 27001
Légende criticité : 🔴 Critique · 🟠 Majeure · 🟡 Modérée · 🟢 Bonne pratique

---

1. Authentification Email

1.1 SPF

• [ ] 🔴 Un seul enregistrement v=spf1 par domaine (pas de doublon → permerror)
• [ ] 🔴 Nombre de lookups DNS imbriqués ≤ 10 (include/a/mx/ptr/exists)
• [ ] 🔴 Mécanisme final -all (strict) — proscrire ?all, transitionner ~all
• [ ] 🟠 Suppression des include obsolètes (anciens prestataires SaaS/ESP)
• [ ] 🟠 Pas de mécanisme ptr (déprécié, coûteux)
• [ ] 🔴 Domaines/sous-domaines parkés (non-émetteurs) : v=spf1 -all systématique (norme M3AAWG)
• [ ] 🟢 Void lookup count < 2 (protection contre DoS SPF)

Vérif : dig TXT domaine.tld +short · outils : spf-tools, mxtoolbox

1.2 DKIM

• [ ] 🔴 Taille de clé ≥ 2048 bits (1024 = plancher obsolète)
• [ ] 🟠 Algorithme RSA-SHA256 minimum ; envisager double signature Ed25519
• [ ] 🟠 Rotation des clés tous les 6 mois avec chevauchement de sélecteurs
• [ ] 🟢 Sélecteurs distincts par tiers/vendeur (révocation ciblée)
• [ ] 🔴 Suppression des sélecteurs orphelins/expirés encore publiés
• [ ] 🟡 Politique t=y (test) désactivée en production

Vérif : dig TXT selector._domainkey.domaine.tld +short

1.3 DMARC

• [ ] 🔴 Enregistrement _dmarc.domaine.tld présent et syntaxiquement valide
• [ ] 🔴 Politique cible p=reject (progression documentée depuis p=none)
• [ ] 🔴 sp=reject explicite pour les sous-domaines (faille de spoofing classique si omis)
• [ ] 🟠 pct=100 en régime stabilisé
• [ ] 🟡 Alignment adkim=s / aspf=s (strict) vs relaxed selon maturité
• [ ] 🔴 rua= configuré ET rapports agrégés effectivement analysés (pas juste présence du champ)
• [ ] 🟠 ruf= + fo=1 pour rapports forensiques
• [ ] 🆕 🟠 Conformité DMARCbis (RFC 9989, mai 2026) — nouvelle structure d'enregistrement à valider

Vérif : dig TXT _dmarc.domaine.tld +short

1.4 ARC

• [ ] 🟡 Signature ARC active sur infrastructures de mailing-lists/forwarding (préserve l'auth lors des relais)

1.5 BIMI

• [ ] 🟢 Prérequis DMARC p=quarantine/p=reject respecté avant activation
• [ ] 🟢 Logo au format SVG Tiny PS conforme
• [ ] 🟢 VMC (Verified Mark Certificate) valide, chaîne de confiance vérifiée
• [ ] 🟢 Test de rendu réel (Gmail, Apple Mail)

---

2. Chiffrement du Transport SMTP

2.1 MTA-STS

• [ ] 🔴 Enregistrement DNS _mta-sts.domaine.tld présent
• [ ] 🔴 Fichier de policy HTTPS accessible et cohérent avec les MX réels
• [ ] 🔴 Certificat TLS valide sur les serveurs MX (⚠ 29,6% de mauvaise config observée — étude ACM IMC '25)
• [ ] 🟡 Mode enforce (pas resté en testing indéfiniment)

2.2 TLS-RPT

• [ ] 🟠 Enregistrement _smtp._tls.domaine.tld présent, reporting actif et supervisé

2.3 DANE / TLSA

• [ ] 🟡 Si DNSSEC déployé : enregistrements TLSA cohérents avec certificats MX
• [ ] 🟡 Usage type TLSA correct (3 1 1 recommandé)

---

3. DNSSEC

• [ ] 🔴 Chaîne de confiance complète (DS chez registrar ↔ DNSKEY en zone)
• [ ] 🟠 Algorithme ECDSA P-256 (algo 13) — migration hors RSA/SHA-1 legacy
• [ ] 🟠 Rotation ZSK/KSK planifiée, procédure de rollover documentée
• [ ] 🔴 Signatures RRSIG non expirées / expiration surveillée (alerting)
• [ ] 🟡 NSEC3 plutôt que NSEC (anti-énumération de zone)
• [ ] 🟢 Algorithm agility testée (double signature en transition)

Vérif : dig DNSKEY domaine.tld · delv domaine.tld

---

4. Hygiène DNS Générale

• [ ] 🔴 Détection CNAME pendants (dangling) → risque de subdomain takeover
• [ ] 🟠 Enregistrements CAA présents, CA autorisée limitée (issue), issuewild distinct pour les certificats wildcard, iodef configuré pour alerting
• [ ] 🟠 Cohérence NS entre registrar et zone effective (glue records inclus)
• [ ] 🟡 Nettoyage des TXT legacy (anciens sélecteurs, vérifications de domaine obsolètes — Google, Microsoft, etc.)
• [ ] 🔴 Transfert de zone AXFR restreint et authentifié par TSIG (pas de zone transfer public)
• [ ] 🟡 TTL cohérents : ANSSI recommande une fourchette de 1h (3600s) à 2 jours (172800s) selon l'arbitrage résilience/réactivité ; éviter les TTL longs sur enregistrements en transition/migration
• [ ] 🟢 Wildcard DNS justifié et documenté (sinon risque de résolution abusive)

4.1 Enregistrements de présence (hygiène de base)

• [ ] 🟡 A/AAAA : cohérence IPv4/IPv6, redondance, pas d'IP orpheline
• [ ] 🟡 MX : priorités cohérentes, redondance multi-serveurs, filtrage anti-spam en amont
• [ ] 🟡 CNAME : cibles valides, éviter les chaînes multiples (résolution en cascade)
• [ ] 🟢 PTR (reverse DNS) : correspondance stricte avec A/AAAA (impact direct sur réputation email)

4.2 Enregistrements spécialisés (souvent oubliés)

• [ ] 🟢 SRV : services annoncés (SIP, LDAP, autodiscover) — priorités/poids cohérents
• [ ] 🟢 SSHFP : empreintes de clés SSH publiées si accès SSH exposé
• [ ] 🟢 IPSECKEY : si tunnels IPsec dépendants de la résolution DNS
• [ ] 🟡 DoH/DoT/DoQ (RFC 9250) : configuration des résolveurs internes, validation de certificats côté client. DoQ supporté en 2026 par Cloudflare, Quad9, BIND 9.18+, Unbound 1.18+ — mêmes enjeux d'inspection du trafic chiffré que DoH

---

5. Sécurité Registrar / Domaine

• [ ] 🔴 Registry Lock activé (protection contre transfert/modification non autorisée)
• [ ] 🔴 2FA sur le compte registrar
• [ ] 🟠 WHOIS privacy activé (réduction de la surface OSINT)
• [ ] 🟡 Date d'expiration du domaine surveillée (renouvellement auto + alerting 30j avant)
• [ ] 🟢 Vérification anti-typosquatting (variantes proches du domaine principal)

---

6. Résilience & Architecture DNS (ANSSI-PA-105)

• [ ] 🔴 Response Rate Limiting (RRL) activé sur les serveurs faisant autorité — le facteur d'amplification des réponses DNS en fait un vecteur privilégié de DDoS via UDP non connecté
• [ ] 🔴 Architecture multi-hébergeur : primary/secondary DNS chez deux prestataires distincts (pas de SPOF sur un seul registrar/hébergeur)
• [ ] 🟠 Anycast déployé pour la répartition géographique de charge et la résistance aux DDoS volumétriques
• [ ] 🟠 Hidden master si architecture multi-secondaires (protection du serveur primaire)
• [ ] 🟠 Transfert des journaux d'événements DNS vers le SIEM/système de supervision de sécurité
• [ ] 🟡 Processus formalisé de maintien en condition de sécurité (MCS) documenté et appliqué — le niveau de criticité du DNS reste élevé malgré la maturation des plateformes
• [ ] 🟡 Séparation logique DNS interne (résolveur) / DNS externe (autoritaire) — split-horizon si pertinent

---

7. Détection de Tunneling DNS & Exfiltration

• [ ] 🔴 Détection de volumétrie anormale de requêtes TXT/NULL par domaine/sous-domaine
• [ ] 🟠 Analyse d'entropie des noms de sous-domaines (signature de tunneling/DGA)
• [ ] 🟠 Corrélation avec le trafic chiffré DoH/DoT/DoQ sortant non autorisé (contournement de filtrage)
• [ ] 🟡 Formalisation d'un processus de partage d'IoC avec le CERT-FR — recommandé par l'ANSSI pour les entités soumises à NIS2, bonne pratique pour les autres
• [ ] 🟢 Règles de détection dédiées dans le SIEM/EDR (Sigma, YARA-DNS) pour les outils de tunneling connus (iodine, dnscat2, DNSExfiltrator)

---

8. Portefeuille de Noms de Domaine (Aspects Juridiques — ANSSI 1.3)

• [ ] 🟠 Cohérence titulaire/mandataire sur l'ensemble du portefeuille (personne morale à jour, pas de nom d'ancien collaborateur)
• [ ] 🟠 Coordonnées de contact administratif/technique à jour chez le registrar
• [ ] 🟡 Centralisation du portefeuille chez un nombre restreint et maîtrisé de registrars (éviter la dispersion incontrôlée)
• [ ] 🟡 Cohérence entre marques déposées et noms de domaine détenus (anti-typosquatting proactif inclus)
• [ ] 🟢 Procédure documentée de gestion du cycle de vie (acquisition, renouvellement, cession, expiration volontaire)

---

9. Surface d'Attaque & Shadow IT

• [ ] 🔴 Monitoring Certificate Transparency (crt.sh, alertes CT) pour détecter des certificats/sous-domaines émis à l'insu de l'organisation
• [ ] 🔴 Scan périodique automatisé de subdomain takeover (pas seulement revue ponctuelle des CNAME pendants)
• [ ] 🟠 Passive DNS pour cartographier l'historique de résolution et détecter les changements suspects
• [ ] 🟡 Détection DGA (Domain Generation Algorithm) sur le trafic sortant — signe de compromission par malware
• [ ] 🟡 Inventaire des sous-domaines exposés vs inventaire déclaré (écarts = shadow IT)

---

10. Résilience & Threat Intel

• [ ] 🟠 Vérification blacklists (Spamhaus, SURBL, etc.) sur les IP émettrices
• [ ] 🟡 Score de réputation domaine/IP
• [ ] 🟢 Support DoH/DoT côté résolveurs internes (confidentialité des requêtes)
• [ ] 🟡 Cohérence IPv4/IPv6 (enregistrements AAAA alignés en sécurité avec A)

---

11. Conformité & Reporting

• [ ] 🟠 Cartographie NIS2 / ISO 27001 / RGPD selon secteur client
• [ ] 🟢 Score global d'audit documenté + comparatif trimestriel (baseline tracking)
• [ ] 🟢 Plan de remédiation priorisé par criticité (🔴 → 🟢)

---

12. Axes de veille 2026 (pas encore critères d'audit opérationnels)

• [ ] 🔵 DNSSEC post-quantique : RSASHA256/ECDSA-P256 restent vulnérables au quantique à terme ; l'IETF travaille sur une stratégie PQC pour DNSSEC (draft draft-sheth-pqc-dnssec-strategy, en cours mi-2026). Aucune signature PQC n'est encore standardisée — les résolveurs actuels ignorent ces signatures si présentes. À surveiller, pas à déployer.
• [ ] 🔵 Zero Trust DNS : intégration de la résolution DNS dans les politiques Zero Trust (filtrage par identité, pas seulement par IP)
• [ ] 🔵 Sécurisation des API DNS : durcissement des interfaces de gestion automatisée (rotation de tokens, scopes limités, audit des changements via API)
• [ ] 🔵 Cloud DNS natif : cohérence des politiques de sécurité cloud-native (Route53, Azure DNS, Cloud DNS) avec la politique groupe

---

Cadence recommandée

Période	Focus
Mensuel	Analyse rapports DMARC agrégés, veille blacklists, monitoring Certificate Transparency
Trimestriel	Audit complet des 12 sections, rotation DKIM si échéance, scan subdomain takeover
Semestriel	Rotation clés DKIM, revue CAA, test MTA-STS en profondeur, revue portefeuille domaines
Annuel	Revue DNSSEC (algo, rollover KSK), revue registrar/2FA, revue architecture/RRL/anycast

---

Checklist conçue pour audits SOTA 2026 — à adapter selon le périmètre client (TPE/PME vs grand compte) et le niveau de maturité email déjà atteint.

---

13. ENREGISTREMENTS SOA & NS AVANCÉ

13.1 Enregistrements SOA

• [ ] 🟠 Valeur refresh dans la plage recommandée : 3600-86400s (1h à 24h)
• [ ] 🟠 Valeur retry dans la plage recommandée : 900-7200s
• [ ] 🟠 Valeur expire dans la plage recommandée : 604800-2419200s (7j à 28j)
• [ ] 🟡 Valeur minimum / negative TTL : 300-3600s (RFC 2308)
• [ ] 🟠 Numéro de série au format YYYYMMDDNN (ou autre format incrémental documenté)
• [ ] 🟡 Serveur primaire (MNAME) cohérent avec les NS déclarés

Vérif : dig SOA domaine.tld +short

13.2 Enregistrements NS — Diversité & Résilience

• [ ] 🔴 Minimum 2 NS (requis RFC 1034), recommandé 3+ pour la résilience
• [ ] 🟠 Diversité d'AS (Autonomous System) — NS hébergés chez des FAI distincts
• [ ] 🟠 Diversité géographique (continents différents pour les grands périmètres)
• [ ] 🟠 Diversité de fournisseurs (pas deux NS chez le même hébergeur DNS)
• [ ] 🟠 Cohérence entre les glue records (enregistrements A/AAAA en zone parente) et les NS effectifs — désalignement = résolution partielle invisible
• [ ] 🟡 NS secondaires synchronisés (numéros de série cohérents entre primary/secondary)
• [ ] 🟡 Support NOTIFY (RFC 1996) pour propagation rapide après changements

Vérif : dig NS domaine.tld +short · dig +norec @ns1 SOA domaine.tld vs @ns2

---

14. DNSSEC — APPROFONDISSEMENT

14.1 Tailles de clés & Algorithmes

• [ ] 🟠 Taille clé ZSK ≥ 1024 bits (RSA) ou 256 bits (ECDSA P-256 algo 13) — ECDSA fortement recommandé
• [ ] 🟠 Taille clé KSK ≥ 2048 bits (RSA) ou 256 bits (ECDSA P-256)
• [ ] 🟡 Durée de validité des signatures RRSIG inférieure à la durée de zone (typiquement 14 jours, alerting 7j avant expiration)
• [ ] 🟡 Algorithm agility : double signature documentée pour les phases de transition

14.2 NSEC3 — Configuration Fine

• [ ] 🟠 NSEC3 configuré (et non NSEC simple) pour prévenir le zone walking
• [ ] 🟠 Itérations NSEC3 ≤ 1 (RFC 9276 recommande 0 pour les nouveaux déploiements — hachage itératif = vecteur de déni de service sur les validateurs)
• [ ] 🟡 NSEC3 opt-out uniquement pour les zones délégantes de très grande taille (documenté et justifié)

Vérif : dig NSEC3PARAM domaine.tld +short · dnsviz.net

---

15. ENREGISTREMENTS SPÉCIALISÉS COMPLÉMENTAIRES

• [ ] 🟢 OPENPGPKEY (_openpgpkey.utilisateur.domaine.tld) — publication des clés PGP via DNS pour validation hors-bande des échanges chiffrés (RFC 7929)
• [ ] 🟡 SSHFP : empreintes de clés SSH publiées pour tous les serveurs SSH exposés publiquement (vérification automatique par les clients SSH avec VerifyHostKeyDNS yes)
• [ ] 🟢 IPSECKEY : clés IPsec publiées si tunnels IPsec dépendants de la résolution DNS
• [ ] 🟡 Enregistrements SRV email : _submission._tcp (port 587/STARTTLS), _imaps._tcp (port 993), _autodiscover._tcp pour la configuration automatique des clients de messagerie
• [ ] 🟢 Enregistrements SRV annuaire/unification : _ldap._tcp, _kerberos._tcp, _caldav._tcp, _carddav._tcp (services annoncés = inventaire de surface d'attaque)

Vérif : dig TYPE61 _openpgpkey.user.domaine.tld +short

---

16. CLOUD & INFRASTRUCTURE DNS

16.1 Services Cloud & CDN

• [ ] 🔴 Pas d'enregistrement CNAME pointant vers un bucket/endpoint cloud non configuré (subdomain takeover via S3, Azure Blob, etc.)
• [ ] 🟠 Sous-domaines pointant vers des plateformes SaaS abandonnées vérifiés (Heroku, GitHub Pages, Shopify, Fastly…) — vecteur classique d'usurpation
• [ ] 🟠 Sous-domaines pointant vers des IPs non allouées ou reclassifiées vérifiés (passive DNS / Shodan)
• [ ] 🟡 Enregistrements de vérification propriétaire (Google Search Console, Microsoft 365, etc.) nettoyés si service décommissionné

16.2 Cloud Providers

• [ ] 🟡 AWS Route 53 : vérification que les Alias Records (A/AAAA vers CloudFront, ELB, S3) pointent vers des ressources actives
• [ ] 🟡 Azure DNS : cohérence des CNAME Azure Traffic Manager / Front Door avec les services déployés
• [ ] 🟡 GCP Cloud DNS : enregistrements vers Cloud Run / Load Balancer vérifiés actifs
• [ ] 🟡 Cloudflare : activation DNSSEC via dashboard, proxy mode vs DNS-only documenté par enregistrement

16.3 Gouvernance Cloud DNS

• [ ] 🟠 Inventaire centralisé des enregistrements DNS créés par des équipes Cloud/Dev (shadow DNS)
• [ ] 🟡 API DNS (Route53, Azure DNS, Cloudflare API) : tokens limités en scope, rotation annuelle, journalisation des appels d'API

---

17. GOUVERNANCE & PROCÉDURES DNS

17.1 Procédures de Changement

• [ ] 🟠 Procédure formalisée de gestion des changements DNS (validation, test en staging, fenêtre de maintenance, rollback)
• [ ] 🟠 Séparation des tâches : distinction entre les rôles lecture, modification et validation des enregistrements DNS (principe du moindre privilège)
• [ ] 🟠 Journalisation des modifications DNS (qui a changé quoi, quand — logs registrar + logs serveur autoritaire)
• [ ] 🟡 Politique de TTL décroissant avant les migrations (pré-abaissement à 300s, migration, remontée TTL)

17.2 Continuité & Reprise

• [ ] 🟠 Plan de Reprise d'Activité (PRA) DNS documenté : procédure de bascule si perte du DNS primaire
• [ ] 🟠 Plan de Continuité d'Activité (PCA) : le DNS est identifié comme service critique, SLA de disponibilité défini
• [ ] 🟡 Sauvegardes régulières des zones DNS (export AXFR interne chiffré, stockage hors-site)

17.3 Infrastructure as Code

• [ ] 🟡 Zones DNS gérées en IaC (Terraform/Pulumi/Ansible) avec peer review et pipeline CI/CD — évite les configurations manuelles non traçables
• [ ] 🟢 DNS observabilité : métriques de résolution intégrées (Prometheus, OpenTelemetry) pour détecter les dégradations avant impact client

---

18. TESTS & VALIDATION DNS

18.1 Tests Fonctionnels

• [ ] 🟠 Résolution A/AAAA : réponse correcte depuis plusieurs résolveurs (8.8.8.8, 1.1.1.1, 9.9.9.9)
• [ ] 🟠 Résolution PTR (reverse) : cohérence FCrDNS forward/reverse pour toutes les IPs publiques
• [ ] 🟡 Résolution MX : priorités cohérentes, tous les MX résolvent
• [ ] 🟡 Résolution NS : cohérence entre ce que retournent les différents NS (numéros de série)
• [ ] 🟡 Résolution CNAME : pas de chaînes supérieures à 5 sauts (RFC 1034)
• [ ] 🟡 Résolution SRV : poids et priorités cohérents, cibles actives
• [ ] 🟡 Résolution TXT : pas de doublons SPF, enregistrements obsolètes supprimés

18.2 Tests de Sécurité

• [ ] 🔴 Test de transfert de zone AXFR : refusé depuis l'extérieur (dig AXFR domaine.tld @ns1 doit échouer)
• [ ] 🟠 Test de subdomain takeover : scan automatisé (nuclei, subjack, dnsrecon) sur tous les CNAME
• [ ] 🟠 Test de zone walking : vérification que NSEC3 empêche l'énumération complète
• [ ] 🟡 Test DNS amplification : facteur d'amplification mesuré et RRL vérifié actif
• [ ] 🟡 Vérification DNSSEC : validation complète avec delv @8.8.8.8 domaine.tld DNSKEY +multiline

18.3 Tests de Performance

• [ ] 🟡 Temps de résolution médian < 50ms depuis les régions cibles (outil : dnsperf, namebench)
• [ ] 🟡 Temps de résolution P95 < 200ms
• [ ] 🟡 Temps de propagation mesuré après un changement (TTL effectif vs TTL théorique)
• [ ] 🟢 Comparaison avec les concurrents (benchmark DNS : dnsperf.com)

Outils recommandés : dig · delv · dnsviz.net · mxtoolbox.com · mail-tester.com · dmarcian.com · ssllabs.com/ssltest · securitytrails.com · crt.sh · nuclei · subjack

---

19. DOCUMENTATION & LIVRABLES DNS

19.1 Documentation Technique

• [ ] 🟠 Schéma de l'architecture DNS (serveurs autoritaires, résolveurs, zones, forwarders)
• [ ] 🟠 Inventaire exhaustif des enregistrements (format structuré : type, valeur, TTL, responsable, date dernière vérification)
• [ ] 🟡 Liste des sous-domaines actifs avec statut (actif/orphelin/archivé)
• [ ] 🟡 Cartographie des dépendances DNS (quels services dépendent de quels enregistrements)
• [ ] 🟡 Procédures d'exploitation documentées (changement, rollback, renouvellement domaines, rotation DKIM)

19.2 Rapport d'Audit

• [ ] 🟠 Synthèse exécutive (score global, top 5 risques, impact business)
• [ ] 🟠 Résultats détaillés par section avec preuve de vérification (dig output, captures)
• [ ] 🟠 Vulnérabilités classées par criticité (🔴/🟠/🟡/🟢) avec CVSS indicatif
• [ ] 🟡 Plan d'action priorisé avec responsables et délais (immédiat < 7j / court terme < 30j / moyen terme < 90j)

19.3 Indicateurs de Performance (KPIs)

• [ ] 🟡 Score de maturité DNS (0-100) calculé sur les contrôles 🔴 et 🟠
• [ ] 🟡 Taux de conformité par section (% de contrôles ✅)