Checklist Sécurité DNS 2026
À quoi sert cette checklist ?
Cette checklist vous permet d'auditer méthodiquement la sécurité de votre environnement DNS Audit en vérifiant point par point chaque contrôle de sécurité critique. Utilisez-la pour identifier les failles de configuration, prioriser les remédiations et documenter votre posture de sécurité — que ce soit dans le cadre d'un audit interne, d'une mise en conformité (ISO 27001, NIS2, HDS) ou d'un durcissement préventif.
Audit DNS complet : SPF, DKIM, DMARC, DNSSEC, DANE, MTA-STS, BIMI, CAA, ZONEMD. 391 contrôles, 38 sections, kill chains MITRE.
Checklist d'audit DNS la plus complète : 391 contrôles couvrant 38 sections — hygiène DNS de base (SOA, NS, glue), email authentication (SPF/DKIM/DMARC/ARC/MTA-STS/BIMI), intégrité DNS (DNSSEC/DANE/CAA/ZONEMD), SOTA 2026 (HTTPS RR, DoT/DoH/DoQ, RPKI, post-quantum), hardening transverse, kill chains MITRE ATT&CK, compliance NIS2 et ANSSI.
Cette checklist a été conçue par les experts Ayi NEDJIMI Consultants à partir de retours d'expérience terrain, des référentiels CIS Benchmarks, des recommandations ANSSI et des bonnes pratiques observées lors de nos missions d'audit. Chaque point de contrôle inclut la commande de vérification, le seuil de conformité et la procédure de remédiation associée. Disponible en PDF et Excel — téléchargement gratuit, aucune inscription requise.
CHECKLIST SÉCURITÉ DNS 2026
🛡️ AYI NEDJIMI CONSULTANTS (ANC)
Version : 1.0
Date : 2026-05-10
Classification : CONFIDENTIEL
Auteur : ANC Security Team
📋 Légende d’Évaluation
| Symbole | Statut | Description |
|---|---|---|
| ✅ | Conforme | Le contrôle est correctement implémenté |
| ❌ | Non-Conforme | Le contrôle n’est pas implémenté ou défaillant |
| ⚠️ | Partiel | Le contrôle est partiellement implémenté |
| N/A | Non Applicable | Le contrôle ne s’applique pas à cet environnement |
Niveaux de Criticité
| Niveau | Icône | Description | Priorité |
|---|---|---|---|
| Critique | 🔴 | Risque immédiat de compromission totale | P0 - Immédiat |
| Élevé | 🟠 | Risque élevé d’élévation de privilèges | P1 - < 7 jours |
| Moyen | 🟡 | Risque modéré d’exposition | P2 - < 30 jours |
| Faible | 🟢 | Bonnes pratiques et hardening | P3 - < 90 jours |
Pré-requis outillage
| Outil | Version mini | Source |
|---|---|---|
dig |
9.18+ | apt install dnsutils |
kdig |
3.x (Knot) | apt install knot-dnsutils |
whois |
5.5+ | apt install whois |
openssl |
3.0+ | apt install openssl |
curl |
8.0+ | apt install curl |
swaks |
20240103+ | apt install swaks |
dnstwist |
20240612+ | pip install dnstwist |
dnsrecon |
1.x | pip install dnsrecon |
subzy |
2.x | go install github.com/PentestPad/subzy@latest |
subfinder |
2.6+ | go install github.com/projectdiscovery/subfinder/v2/cmd/subfinder@latest |
testssl.sh |
3.2+ | git clone https://github.com/drwetter/testssl.sh |
nmap |
7.94+ | apt install nmap |
parsedmarc |
8.x | pip install parsedmarc |
dnscontrol |
4.x | github.com/StackExchange/dnscontrol |
Résolveurs publics de référence
| IP | Opérateur | Notes |
|---|---|---|
| 1.1.1.1 / 2606:4700:4700::1111 | Cloudflare | DNSSEC validation |
| 8.8.8.8 / 2001:4860:4860::8888 | DNSSEC validation | |
| 9.9.9.9 / 2620:fe::fe | Quad9 | DNSSEC + threat intel |
| 208.67.222.222 | OpenDNS / Cisco | DNSSEC validation |
⚡ Mode Découverte Rapide — 15 Questions Clés
Évaluation rapide des risques DNS critiques en 15 minutes
Q1. SOA et serveurs de noms autoritatifs
dig <domaine> SOA NS +short
for NS in $(dig <domaine> NS +short); do dig @$NS <domaine> SOA +short; done
Critères de validation :
- ✅ SOA présent et conforme RFC 1035, ≥ 2 NS authoritatifs sur AS distincts, sérials cohérents
- ❌ < 2 NS, sérials divergents, mono-fournisseur DNS (SPOF)
Seuil critique : Mono-fournisseur DNS sans secondaire externe (incident type Dyn 2016)
Évaluation : ✅ ❌ ⚠️ N/A
Q2. Politique DMARC effective
dig _dmarc.<domaine> TXT +short
Critères de validation :
- ✅
v=DMARC1; p=reject; sp=reject; rua=mailto:... - ❌ Absence de record,
p=noneau-delà de 90 jours, ou record absent
Seuil critique : p=none ou record absent en 2026
Évaluation : ✅ ❌ ⚠️ N/A
Q3. Conformité SPF
dig <domaine> TXT +short | grep "v=spf1"
Critères de validation :
- ✅ SPF unique, ≤ 10 lookups, qualifier
-all(ou~alldocumenté) - ❌ Records multiples, lookups > 10,
+all, ou absent
Seuil critique : +all ou absence
Évaluation : ✅ ❌ ⚠️ N/A
Q4. DNSSEC actif et chaîne valide
dig +dnssec <domaine> SOA | grep -E "ad |RRSIG"
dig <domaine> DNSKEY DS +multiline
Critères de validation :
- ✅ Flag
adretourné, DS publié au TLD, algo 13/15 - ❌ Pas de DS, algo 5/7 (RSA-SHA1), chaîne brisée
Seuil critique : DNSSEC absent sur entité essentielle NIS2
Évaluation : ✅ ❌ ⚠️ N/A
Q5. CAA publiés
dig <domaine> CAA +short
Critères de validation :
- ✅ CAA
issuerestreint +iodef+accounturi(RFC 8657) - ❌ Aucun CAA = toute AC peut émettre
Seuil critique : Absence de CAA sur domaine producteur de certificats
Évaluation : ✅ ❌ ⚠️ N/A
Q6. MTA-STS en mode enforce
dig _mta-sts.<domaine> TXT +short
curl -sk https://mta-sts.<domaine>/.well-known/mta-sts.txt
Critères de validation :
- ✅ Record TXT + policy HTTPS
mode: enforce - ❌ Mode
testingpermanent, ou absent
Seuil critique : Domaine email sans MTA-STS enforce en 2026
Évaluation : ✅ ❌ ⚠️ N/A
Q7. DKIM clés et longueur
dig <selector>._domainkey.<domaine> TXT +short
Critères de validation :
- ✅ Au moins 1 sélecteur avec clé RSA-2048+ ou Ed25519,
t=yabsent - ❌ Clé RSA-1024, sélecteurs orphelins,
t=yen production
Seuil critique : RSA-1024 (proscrit ANSSI 2024)
Évaluation : ✅ ❌ ⚠️ N/A
Q8. Statuts EPP du domaine
whois <domaine> | grep -iE "status|expir|registrar"
Critères de validation :
- ✅
clientTransferProhibited+clientUpdateProhibited+clientDeleteProhibited, expire > 90j - ❌ Aucun lock EPP, ou statut
pendingDelete/redemptionPeriod
Seuil critique : Aucun lock EPP sur domaine de production
Évaluation : ✅ ❌ ⚠️ N/A
Q9. Subdomain takeover risk
subzy run --targets sous-domaines.txt
dig <subdomain> CNAME +short
Critères de validation :
- ✅ Aucun CNAME orphelin (pointage S3, Heroku, GitHub Pages, Azure, Fastly désactivé)
- ❌ Au moins un CNAME dangling actif
Seuil critique : ≥ 1 CNAME exploitable détecté
Évaluation : ✅ ❌ ⚠️ N/A
Q10. Reverse DNS et FCrDNS pour MTA
IP=$(dig <domaine> A +short | head -1)
PTR=$(dig -x $IP +short)
dig $PTR A +short
Critères de validation :
- ✅ A → PTR → A (FCrDNS RFC 1912 §2.1), HELO matches PTR
- ❌ Pas de PTR, PTR générique opérateur, mismatch HELO
Seuil critique : Échec Gmail/Yahoo Bulk Sender 2024+
Évaluation : ✅ ❌ ⚠️ N/A
Q11. AXFR et leaks DNS
for NS in $(dig <domaine> NS +short); do dig @$NS <domaine> AXFR; done
dig @<ns> version.bind TXT CHAOS
Critères de validation :
- ✅ AXFR refusé (REFUSED ou Transfer failed), version.bind silencieux
- ❌ Zone transfert public, fingerprint BIND/Knot lisible
Seuil critique : AXFR ouvert au public
Évaluation : ✅ ❌ ⚠️ N/A
Q12. TLS-RPT actif
dig _smtp._tls.<domaine> TXT +short
Critères de validation :
- ✅
v=TLSRPTv1; rua=mailto:...ou endpoint HTTPS - ❌ Absence (pas de visibilité downgrade STARTTLS)
Seuil critique : Absent quand MTA-STS actif
Évaluation : ✅ ❌ ⚠️ N/A
Q13. Wildcard DNS exposé
for i in $(shuf -i 10000-99999 -n 20); do dig random${i}.<domaine> A +short; done
Critères de validation :
- ✅ NXDOMAIN sur 20 sous-domaines aléatoires
- ❌ Wildcard A/CNAME non documenté
Seuil critique : Wildcard non maîtrisé (risque phishing)
Évaluation : ✅ ❌ ⚠️ N/A
Q14. Conformité headers HTTP de sécurité
curl -skI https://<domaine> | grep -iE "strict-transport|content-security|x-frame|x-content-type|referrer-policy"
Critères de validation :
- ✅ HSTS preload + CSP + X-Content-Type + X-Frame + Referrer-Policy + Permissions-Policy
- ❌ Headers manquants ou
Server:divulguant version
Seuil critique : Score Mozilla Observatory < B
Évaluation : ✅ ❌ ⚠️ N/A
Q15. Score internet.nl global
https://internet.nl/test-mail/<domaine>
https://internet.nl/test-site/<domaine>
Critères de validation :
- ✅ Score ≥ 95 % web et mail
- ❌ Score < 70 % (posture insuffisante)
Seuil critique : Score < 70 %
Évaluation : ✅ ❌ ⚠️ N/A
📊 Informations Domaine Audité
| Champ | Valeur | Notes |
|---|---|---|
| Organisation | [À compléter] | Raison sociale |
| Domaine apex audité | [À compléter] | FQDN principal |
| Sous-domaines critiques | [À compléter] | Liste exhaustive |
| Registrar | [À compléter] | OVH / Gandi / Cloudflare / Namecheap |
| Hébergeur DNS auth. | [À compléter] | OVH / Cloudflare / Route53 / Azure |
| Émetteurs email tiers | [À compléter] | M365, Mailchimp, SendGrid, Zendesk, etc. |
| AS / IPs publiques | [À compléter] | Pour ROA RPKI |
| Score initial internet.nl | [À compléter] | 0-100 web + 0-100 mail |
| Posture NIS2 | [À compléter] | Essentielle / Importante / Hors-scope |
🛡️ SECTION 1 — HYGIÈNE DNS DE BASE (RFC 1034/1035/1912)
1.1.1 — SOA présent et conforme RFC 1035
Niveau : 🟠
Référence : RFC 1035 §3.3.13 / RFC 1912 §2.2
MITRE ATT&CK : T1590.002
Description : Le record SOA (Start Of Authority) est obligatoire sur toute zone autoritative. Son absence ou un format incorrect indique une zone mal provisionnée. Le serial sert de référence aux NS secondaires.
Vérification :
dig <domaine> SOA +short
dig <domaine> SOA +noall +answer
Critères de validation :
- ✅ SOA présent, MNAME = NS primaire, RNAME = email avec
.séparateur - ❌ Absent, MNAME pointant vers IP ou NS inexistant
Remédiation : Régénérer la zone via le panneau DNS du registrar / API Cloudflare / OVH.
Valeur par défaut : Variable selon hébergeur
1.1.2 — Au moins 2 NS authoritatifs
Niveau : 🔴
Référence : RFC 1034 §4.1
MITRE ATT&CK : T1498 (DDoS), T1583.002
Description : Un seul NS = SPOF. La RFC 1034 et le BCP DNS exigent au minimum 2 NS authoritatifs pour assurer la résilience. L’incident Dyn 2016 a montré qu’un mono-fournisseur peut isoler des marques entières.
Vérification :
dig <domaine> NS +short | wc -l
Critères de validation :
- ✅ ≥ 2 NS retournés
- ❌ 1 seul NS
Remédiation : Ajouter un NS secondaire, idéalement chez un fournisseur distinct (Hurricane Electric ns.he.net gratuit, NS1, Cloudflare).
1.1.3 — NS sur AS distincts (anti-incident Dyn)
Niveau : 🔴
Référence : RFC 2182 / BCP 16
MITRE ATT&CK : T1498
Description : Tous les NS chez le même hébergeur = SPOF mutualisé (incident Dyn 2016 ayant impacté Twitter, Spotify, GitHub). Diversifier les AS protège contre les pannes massives et les DDoS ciblés.
Vérification :
for NS in $(dig <domaine> NS +short); do
IP=$(dig $NS A +short | head -1)
whois $IP | grep -iE "origin|netname|aut-num"
done
Critères de validation :
- ✅ ≥ 2 AS différents pour les NS
- ❌ Tous les NS sur le même AS / hébergeur
Remédiation : Configurer un secondaire externe (HE.net, NS1, Cloudflare DNS Secondary).
1.1.4 — Cohérence sérials SOA inter-NS
Niveau : 🟠
Référence : RFC 1912 §2.2
MITRE ATT&CK : T1565.002
Description : Tous les NS authoritatifs d’une zone doivent retourner le même serial SOA. Une divergence indique une réplication cassée ou une compromission partielle.
Vérification :
for NS in $(dig <domaine> NS +short); do
printf "%-30s %s\n" "$NS" "$(dig @$NS <domaine> SOA +short | awk '{print $3}')"
done
Critères de validation :
- ✅ Tous les NS retournent le même serial
- ❌ ≥ 1 NS avec serial différent (réplication cassée)
Remédiation : Forcer un AXFR/IXFR et auditer les logs de réplication.
1.1.5 — Cohérence NS parent vs enfant
Niveau : 🟠
Référence : RFC 1912 §2.8
MITRE ATT&CK : T1583.002
Description : Les NS publiés par le TLD parent (.fr/.com) doivent correspondre aux NS publiés dans la zone enfant. Une divergence ouvre des fenêtres d’attaque (lame delegation, takeover).
Vérification :
TLD=$(echo <domaine> | awk -F. '{print $NF}')
dig +trace <domaine> NS | grep -A2 "<domaine>"
Critères de validation :
- ✅ NS parent = NS enfant
- ❌ Ensembles divergents
Remédiation : Mettre à jour les NS chez le registrar pour qu’ils matchent la zone enfant.
1.1.6 — Glue records publiés
Niveau : 🟡
Référence : RFC 1034 §4.2.1
MITRE ATT&CK : T1565.002
Description : Si les NS sont sous le domaine lui-même (ns1.example.com), des glue records (A/AAAA) doivent être publiés au TLD pour résoudre la dépendance circulaire.
Vérification :
dig +norec @<tld-ns> <domaine> NS | grep -iE "ADDITIONAL|glue"
Critères de validation :
- ✅ Glue records IPv4 + IPv6 publiés au parent
- ❌ Pas de glue alors que NS in-bailiwick
Remédiation : Déclarer les glue records via l’interface registrar (rubrique “Host Object” / “Glue”).
1.1.7 — PTR (reverse DNS) configurés
Niveau : 🟠
Référence : RFC 1912 §2.1 / RFC 1035 §3.5
MITRE ATT&CK : T1071.004
Description : Les enregistrements PTR (reverse DNS) sont indispensables pour les MTA (anti-spam) et pour les bonnes pratiques opérationnelles. Gmail/Yahoo 2024 exigent des PTR cohérents pour les expéditeurs en volume.
Vérification :
for IP in $(dig <domaine> A AAAA +short); do
dig -x $IP +short
done
Critères de validation :
- ✅ PTR présent pour toute IP publique critique
- ❌ Absent ou PTR générique (
vps-xx.host.com)
Remédiation : Configurer le PTR dans le panneau de l’hébergeur (OVH Manager, AWS EC2 Reverse DNS, Azure Reverse DNS).
1.1.8 — FCrDNS (Forward-Confirmed Reverse DNS)
Niveau : 🟠
Référence : RFC 1912 §2.1
MITRE ATT&CK : T1071.004
Description : FCrDNS = A → PTR → A doit retourner la même IP. Ce contrôle valide la cohérence DNS bidirectionnelle. Yahoo, Gmail et la majorité des grands MTA refusent les expéditeurs sans FCrDNS valide.
Vérification :
IP=$(dig <domaine> A +short | head -1)
PTR=$(dig -x $IP +short | sed 's/\.$//')
dig $PTR A +short | grep -q "^$IP$" && echo OK FCrDNS || echo FAIL FCrDNS
Critères de validation :
- ✅ A → PTR → A boucle propre
- ❌ Mismatch ou PTR vide
Remédiation : Aligner PTR sur le FQDN HELO du serveur, vérifier zone forward.
1.1.9 — PTR IPv6 si AAAA publié
Niveau : 🟡
Référence : RFC 3596 / RFC 6177
MITRE ATT&CK : T1071.004
Description : Si la zone publie des AAAA (IPv6), un PTR IPv6 est requis dans ip6.arpa. Beaucoup d’opérateurs négligent ce point, créant des erreurs de delivery email.
Vérification :
for IP6 in $(dig <domaine> AAAA +short); do
dig -x $IP6 +short
done
Critères de validation :
- ✅ PTR IPv6 = FQDN, FCrDNS aligné
- ❌ AAAA présent sans PTR IPv6 correspondant
Remédiation : Configurer la zone reverse IPv6 chez l’hébergeur.
1.1.10 — Cohérence A/AAAA inter-résolveurs
Niveau : 🟡
Référence : RFC 1034 §4.3.4
MITRE ATT&CK : T1071.004
Description : Les 4 résolveurs publics (1.1.1.1, 8.8.8.8, 9.9.9.9, 208.67.222.222) doivent retourner les mêmes A/AAAA. Une divergence peut indiquer un cache poisoning, un GeoDNS mal configuré ou une réplication cassée.
Vérification :
for R in 1.1.1.1 8.8.8.8 9.9.9.9 208.67.222.222; do
printf "%-15s %s\n" "$R" "$(dig @$R <domaine> A +short | tr '\n' ' ')"
done
Critères de validation :
- ✅ Réponses identiques (modulo round-robin maîtrisé)
- ❌ Sets divergents non documentés
Remédiation : Investiguer GeoDNS, vérifier TTL, capturer pcap.
1.1.11 — TTL apex raisonnable
Niveau : 🟢
Référence : RFC 1912 §2.2
MITRE ATT&CK : T1498
Description : TTL apex trop bas (< 300s) augmente la charge des résolveurs et le risque DDoS amplification. Trop élevé (> 86400) ralentit les changements d’urgence.
Vérification :
dig <domaine> A +noall +answer | awk '{print $2}'
Critères de validation :
- ✅ TTL entre 300 et 86400 s
- ❌ < 300 ou > 86400 sans justification
Remédiation : Ajuster TTL via panel DNS.
1.1.12 — Pas de CNAME au sommet de zone (apex)
Niveau : 🟡
Référence : RFC 1034 §3.6.2 / RFC 2181
MITRE ATT&CK : T1583.002
Description : Un CNAME à l’apex casse les autres records (MX, NS, SOA). Utiliser ALIAS, ANAME ou flattening (Cloudflare) pour le pointage CDN.
Vérification :
dig <domaine> CNAME +short
Critères de validation :
- ✅ Aucun CNAME à l’apex
- ❌ CNAME publié à l’apex
Remédiation : Utiliser ALIAS / CNAME flattening (Cloudflare, Route53).
1.1.13 — Aucun record HINFO non sollicité
Niveau : 🟢
Référence : RFC 8482
MITRE ATT&CK : T1592.004
Description : Les HINFO permettent de divulguer des infos système. Cloudflare retourne RFC8482 sur ANY pour limiter l’amplification — vérifier cohérence.
Vérification :
dig <domaine> HINFO +short
dig <domaine> ANY +short
Critères de validation :
- ✅ Pas de HINFO révélateur
- ❌ HINFO type “Linux x86_64…”
Remédiation : Supprimer HINFO ou les rendre génériques.
1.1.14 — Délégation NS résolue
Niveau : 🟠
Référence : RFC 1034 §4.2
MITRE ATT&CK : T1583.002
Description : Tout NS déclaré doit résoudre en A et AAAA (lame delegation = NS injoignable).
Vérification :
for NS in $(dig <domaine> NS +short); do
printf "%-30s %s\n" "$NS" "$(dig $NS A +short | tr '\n' ' ')"
done
Critères de validation :
- ✅ Tous les NS résolvent en A
- ❌ ≥ 1 NS sans A (lame)
Remédiation : Corriger ou retirer le NS non résolvable.
1.1.15 — TTL NS cohérent parent/enfant
Niveau : 🟢
Référence : RFC 1912 §2.6
MITRE ATT&CK : T1565.002
Description : Un TTL NS trop bas dans la zone enfant peut entraîner des résolutions parent qui durent plus longtemps que prévu (visible 7-14 jours en cas de migration).
Vérification :
dig +noall +authority +answer <domaine> NS
Critères de validation :
- ✅ TTL NS ≥ 3600 s, cohérent
- ❌ TTL anormalement bas/haut
Remédiation : Aligner TTL NS à 86400 s.
🌐 SECTION 2 — HYGIÈNE SERVEURS DE NOMS AUTHORITATIFS
2.1.1 — AXFR refusé aux clients non autorisés
Niveau : 🔴
Référence : RFC 5936 / RFC 1995
MITRE ATT&CK : T1018, T1592
Description : Un AXFR ouvert expose toute la zone (sous-domaines, dev, staging, ressources internes). Cas historique : zonefiles d’opérateurs telco fuités via AXFR.
Vérification :
for NS in $(dig <domaine> NS +short); do
echo "=== $NS ==="
dig @$NS <domaine> AXFR | head -5
done
Critères de validation :
- ✅ Tous les NS refusent (REFUSED ou Transfer failed)
- ❌ Au moins un NS accorde le transfert
Remédiation : Configurer ACL allow-transfer { trusted; }; sur BIND/Knot/PowerDNS.
2.1.2 — Open recursion désactivée sur NS auth
Niveau : 🔴
Référence : RFC 5358 / BCP 140
MITRE ATT&CK : T1498.002
Description : Un NS authoritatif servant de résolveur récursif ouvert peut être abusé pour DNS amplification (attaques de type Pseudo-Spoofed).
Vérification :
for NS in $(dig <domaine> NS +short); do
IP=$(dig $NS A +short | head -1)
dig @$IP google.com +noall +comments | grep -i "ra"
done
Critères de validation :
- ✅ Pas de flag
ra(recursion available) - ❌ Flag
raprésent → résolveur ouvert
Remédiation : recursion no; sur BIND, désactiver récursion sur Knot/PowerDNS.
2.1.3 — Pas de leak version.bind / hostname.bind
Niveau : 🟡
Référence : RFC 4892 / BCP 76
MITRE ATT&CK : T1592.004
Description : Les requêtes version.bind, hostname.bind, id.server en classe CHAOS peuvent divulguer la version logicielle (BIND 9.16.x, Knot 3.x, PowerDNS 4.x), facilitant le ciblage CVE.
Vérification :
for NS in $(dig <domaine> NS +short); do
IP=$(dig $NS A +short | head -1)
dig @$IP version.bind TXT CHAOS +short
dig @$IP hostname.bind TXT CHAOS +short
dig @$IP id.server TXT CHAOS +short
done
Critères de validation :
- ✅ Réponses vides ou génériques (
server,nope) - ❌ Version logicielle précise divulguée
Remédiation : version "none"; BIND ou server.version: "none" PowerDNS.
2.1.4 — EDNS0 supporté (RFC 6891)
Niveau : 🟠
Référence : RFC 6891 / DNS Flag Day 2020
MITRE ATT&CK : T1565.002
Description : Sans EDNS0, les NS ne peuvent pas servir DNSSEC, IPv6, COOKIE. Le DNS Flag Day 2020 a poussé tous les opérateurs à retirer le support des NS non-EDNS-compliant.
Vérification :
dig +bufsize=1232 +dnssec <domaine> SOA
# Outil : https://ednscomp.isc.org/
Critères de validation :
- ✅ EDNS0 supporté avec bufsize ≥ 1232
- ❌ Réponses tronquées ou erreurs
Remédiation : Activer EDNS0 sur tous les NS, vérifier MTU 1232.
2.1.5 — Conformité DNS Flag Day 2020
Niveau : 🟠
Référence : dnsflagday.net
MITRE ATT&CK : T1565.002
Description : Le DNS Flag Day 2020 a interdit la fragmentation IP UDP. Les serveurs doivent négocier MTU via EDNS0 ou basculer en TCP.
Vérification : https://ednscomp.isc.org/ednscomp/
Critères de validation :
- ✅ Score
CompliantouMostly compliant - ❌
Severe Violations
Remédiation : Mettre à jour BIND/Knot/PowerDNS, désactiver fragmentation UDP.
2.1.6 — IPv6 actif sur tous les NS
Niveau : 🟡
Référence : RFC 3901 / NIS2
MITRE ATT&CK : T1498
Description : Sans IPv6 sur les NS, les utilisateurs IPv6-only ne résolvent pas le domaine. Aussi, IPv4-only = SPOF protocolaire.
Vérification :
for NS in $(dig <domaine> NS +short); do
printf "%-30s A=%s AAAA=%s\n" "$NS" "$(dig $NS A +short | tr '\n' ' ')" "$(dig $NS AAAA +short | tr '\n' ' ')"
done
Critères de validation :
- ✅ Tous les NS ont AAAA + A
- ❌ ≥ 1 NS IPv4-only
Remédiation : Ajouter AAAA aux NS via panel hébergeur.
2.1.7 — Anycast configuré (résilience DDoS)
Niveau : 🟢
Référence : RFC 4786 / BCP 126
MITRE ATT&CK : T1498
Description : Anycast permet à plusieurs sites physiques de servir la même IP, atténuant les DDoS volumétriques et améliorant la latence.
Vérification :
# Test latence depuis plusieurs régions ou via 'dig +server' avec différents looking glass
mtr -n -c 5 ns1.<provider>.com
Critères de validation :
- ✅ Au moins 3 sites Anycast
- ❌ Mono-site
Remédiation : Migrer vers fournisseur DNS Anycast (Cloudflare, Route53, NS1, OVH Anycast).
2.1.8 — RRL (Response Rate Limiting) actif
Niveau : 🟢
Référence : RFC 5358 / draft-vixie-isc-dns-rrl
MITRE ATT&CK : T1498.002
Description : RRL limite les réponses identiques par seconde, mitigant l’amplification DNS pour amplifier des DDoS spoofés.
Vérification :
# Test : envoyer 1000 requêtes / s et observer les réponses TC=1 ou drop
nmap -sU -p 53 --script dns-recursion <ns_ip>
Critères de validation :
- ✅ RRL
rate-limit { responses-per-second 5; };configuré BIND - ❌ Pas de limite
Remédiation : Activer RRL sur BIND/Knot/PowerDNS.
2.1.9 — Source-port randomization
Niveau : 🟠
Référence : RFC 5452 / Kaminsky 2008
MITRE ATT&CK : T1565.002
Description : Sans randomisation des ports source, le cache poisoning (Kaminsky 2008) reste possible. Les implémentations DNS modernes randomisent automatiquement.
Vérification :
# Vérifier port source via tcpdump sur le NS
sudo tcpdump -nn -i any 'port 53' | head -10
Critères de validation :
- ✅ Ports source > 1024, distribution aléatoire
- ❌ Port source fixe ou plage limitée
Remédiation : Mise à jour BIND/Knot/PowerDNS, ne pas restreindre les ports source.
2.1.10 — Logs DNS conservés ≥ 90 jours
Niveau : 🟢
Référence : NIS2 §21 / ANSSI Guide DNS 2024
MITRE ATT&CK : T1562.008
Description : Les logs DNS (queries, zone transfers, signing events) doivent être conservés pour investigation forensique. NIS2 impose 90 jours minimum pour entités essentielles.
Vérification : Audit configuration logging du fournisseur DNS.
Critères de validation :
- ✅ Logs centralisés, retention ≥ 90 j
- ❌ Pas de log ou retention < 30 j
Remédiation : Activer query logs, exporter vers SIEM (Splunk, Elastic, Graylog).
⏱️ SECTION 3 — HYGIÈNE SOA / TTL
3.1.1 — Format serial SOA YYYYMMDDnn
Niveau : 🟢
Référence : RFC 1912 §2.2
MITRE ATT&CK : N/A
Description : Le format YYYYMMDDnn est standard, lisible et auto-incrémentable. Utiliser un epoch Unix est valide mais moins lisible.
Vérification :
dig <domaine> SOA +short | awk '{print $3}'
Critères de validation :
- ✅ Format YYYYMMDDnn ou epoch raisonné
- ❌ Format aléatoire / incrément aléatoire
3.1.2 — SOA refresh raisonnable
Niveau : 🟢
Référence : RFC 1912 §2.2
Description : Refresh entre 3600 (1h) et 86400 (24h). Trop bas = charge réplication, trop haut = retard propagation.
Vérification :
dig <domaine> SOA +short
Critères de validation :
- ✅ 3600 ≤ refresh ≤ 86400
- ❌ < 3600 ou > 86400
3.1.3 — SOA retry cohérent
Niveau : 🟢
Référence : RFC 1912 §2.2
Description : Retry doit être au moins refresh / 10 (souvent 600-7200 s).
Critères de validation :
- ✅ retry ≥ refresh/10
- ❌ retry > refresh
3.1.4 — SOA expire ≥ 7 jours
Niveau : 🟠
Référence : RFC 1912 §2.2
Description : Expire (en secondes) = combien de temps un secondaire continue à servir si le primaire est indisponible. Recommandé : 604800 (7j) à 2419200 (28j).
Critères de validation :
- ✅ 604800 ≤ expire ≤ 2419200
- ❌ < 604800
3.1.5 — SOA minimum/negTTL
Niveau : 🟢
Référence : RFC 2308
Description : Le 5e champ SOA est le TTL négatif (NXDOMAIN cache). Recommandé : 300-3600 s.
Critères de validation :
- ✅ 300 ≤ minimum ≤ 3600
- ❌ Hors plage
3.1.6 — TTL apex ≥ 300 s
Niveau : 🟢
Référence : RFC 1912
Description : TTL trop bas → DDoS amplification, charge résolveurs.
Critères de validation :
- ✅ TTL apex ≥ 300 s
- ❌ < 300 s
3.1.7 — TTL apex ≤ 86400 s
Niveau : 🟢
Description : TTL > 24h ralentit les bascules d’urgence.
Critères de validation :
- ✅ TTL ≤ 86400 s
3.1.8 — Cohérence TTL records liés
Niveau : 🟢
Description : Les TTL d’un MX et de ses A doivent être cohérents (sinon résolution incomplète possible).
Critères de validation :
- ✅ TTL alignés
- ❌ Diff > 50 %
3.1.9 — Pas de TTL aberrant
Niveau : 🟡
Description : TTL négatif, > 1 mois ou nul = bug.
Critères de validation :
- ✅ Tous TTL dans [60, 2592000]
- ❌ Valeurs aberrantes
3.1.10 — Bump du serial à chaque modification
Niveau : 🟢
Description : Le serial doit être incrémenté à chaque mise à jour de la zone, sinon les secondaires ignorent la modification.
Critères de validation :
- ✅ Serial incrémenté à chaque commit
- ❌ Serial figé
🔐 SECTION 4 — DOMAIN STATUS & REGISTRAR LOCKS
4.1.1 — Domaine non-expiré (Expiry > 90 jours)
Niveau : 🔴
Référence : ICANN ERRP / RFC 8056
MITRE ATT&CK : T1583.001
Description : Un domaine en redemption ou pending delete peut être racheté par un attaquant. Veille J-90 obligatoire.
Vérification :
whois <domaine> | grep -iE "expir"
curl -s "https://rdap.org/domain/<domaine>" | jq '.events[] | select(.eventAction=="expiration")'
Critères de validation :
- ✅ Expiry > 90 j
- ❌ < 90 j ou en redemptionPeriod
Remédiation : Renouveler immédiatement, activer auto-renew.
4.1.2 — Auto-renouvellement actif
Niveau : 🔴
Référence : ICANN policy
MITRE ATT&CK : T1583.001
Description : Auto-renew + carte valide protège contre l’oubli administratif (incident type Foursquare 2010, Sorenson 2024).
Vérification : Console registrar.
Critères de validation :
- ✅ Auto-renew actif, paiement valide
- ❌ Désactivé
Remédiation : Activer auto-renew, multiplier les contacts billing.
4.1.3 — EPP clientTransferProhibited
Niveau : 🔴
Référence : RFC 5731 §3.4
MITRE ATT&CK : T1583.001 (Domain hijack)
Description : Bloque tout transfert sortant non-autorisé. Quasi-gratuit chez tout registrar moderne.
Vérification :
whois <domaine> | grep -i "clientTransferProhibited"
Critères de validation :
- ✅ Statut présent
- ❌ Absent
Remédiation : Activer dans le panel registrar.
4.1.4 — EPP clientUpdateProhibited
Niveau : 🟠
Référence : RFC 5731 §3.4
Description : Bloque toute modification (NS, contacts) sans levée explicite. Recommandé pour domaines critiques.
Critères de validation :
- ✅ Statut présent
- ❌ Absent
4.1.5 — EPP clientDeleteProhibited
Niveau : 🟠
Référence : RFC 5731 §3.4
Description : Bloque toute suppression accidentelle/malicieuse.
Critères de validation :
- ✅ Statut présent
- ❌ Absent
4.1.6 — Pas de statuts d’urgence
Niveau : 🔴
Référence : RFC 8056
MITRE ATT&CK : T1583.001
Description : clientHold, serverHold, redemptionPeriod, pendingDelete indiquent un domaine compromis ou en perdition.
Vérification :
whois <domaine> | grep -iE "Hold|redemption|pendingDelete|pendingTransfer"
Critères de validation :
- ✅ Aucun statut d’urgence
- ❌ Présent
Remédiation : Action immédiate registrar.
4.1.7 — Registry Lock (server-level)
Niveau : 🟠
Référence : ICANN serverUpdateProhibited
MITRE ATT&CK : T1583.001
Description : Registry Lock (~50-300 €/an selon registry) ajoute une couche TLD-level demandant double-validation manuelle. Recommandé pour grandes marques (incident Twitter Hack 2020 type).
Vérification :
whois <domaine> | grep -i "serverUpdateProhibited"
Critères de validation :
- ✅
serverUpdateProhibitedactif - ❌ Absent sur domaines critiques
Remédiation : Souscription Registry Lock chez registrar (Gandi VLP, OVH HSD, Markmonitor).
4.1.8 — 2FA registrar (TOTP / FIDO2)
Niveau : 🔴
Référence : ANSSI / NIS2
MITRE ATT&CK : T1078.004
Description : Compte registrar = clé du royaume DNS. 2FA TOTP minimum, FIDO2 recommandé.
Critères de validation :
- ✅ FIDO2/WebAuthn actif
- ⚠️ TOTP uniquement
- ❌ Mot de passe seul
Remédiation : Activer YubiKey ou TOTP via app authenticator.
4.1.9 — Inventaire credentials registrar
Niveau : 🟢
Référence : ISO 27001:2022 §A.5.10
Description : Tous les credentials registrar (login, API keys) doivent être inventoriés dans un vault (Bitwarden/HashiCorp Vault), avec rotation 6 mois.
Critères de validation :
- ✅ Vault + rotation
- ❌ Stockage sauvage (mail, post-it)
4.1.10 — Contacts WHOIS valides
Niveau : 🟡
Référence : ICANN WDRP
Description : Contacts WHOIS doivent être valides (email accessible, téléphone joignable).
Vérification :
whois <domaine> | grep -iE "Email|Phone"
Critères de validation :
- ✅ Contacts à jour
- ❌ Email orphan ou invalide
4.1.11 — RDAP migration (ICANN obligatoire 2025)
Niveau : 🟡
Référence : RFC 9082-9083 / ICANN policy 2025
Description : WHOIS est progressivement remplacé par RDAP (JSON, REST, authentification). Connaître les endpoints RDAP du TLD est utile.
Vérification :
curl -s "https://rdap.org/domain/<domaine>" | jq '.'
Critères de validation :
- ✅ RDAP retourne données complètes
- ❌ Erreur 404/redirect WHOIS-only
4.1.12 — Privacy/Proxy WHOIS évalué
Niveau : 🟢
Référence : RGPD / ICANN
Description : Privacy proxy peut masquer l’identité du titulaire. À évaluer en fonction du business (B2B vs grand public).
Critères de validation :
- ✅ Politique privacy/proxy documentée
- ❌ Aucune position
4.1.13 — Multi-registrar pour domaines critiques
Niveau : 🟢
Référence : ENISA Best Practices
Description : Pour grandes marques, doubler la présence chez 2 registrars distincts (sur 2 TLD différents) limite le risque de compromission registrar (incident GoDaddy 2023).
Critères de validation :
- ✅ Domaines critiques chez ≥ 2 registrars
- ❌ Mono-registrar
🪤 SECTION 5 — SUBDOMAIN TAKEOVER & DANGLING RECORDS
5.1.1 — Aucun CNAME orphelin vers service tiers libéré
Niveau : 🔴
Référence : can-i-take-over-xyz / OWASP
MITRE ATT&CK : T1584.001
Description : Un CNAME pointant vers un bucket S3 libéré, app Heroku/GitHub Pages/Azure désactivée permet à un attaquant de re-créer la ressource et de capturer le sous-domaine. Cas Microsoft Bing 2021, multiples Fortune 500.
Vérification :
subzy run --targets sous-domaines.txt
# ou : python3 takeover-py/takeover.py -d <domaine>
Critères de validation :
- ✅ Aucun takeover détecté
- ❌ ≥ 1 CNAME exploitable
Remédiation : Supprimer le CNAME ou re-claim la ressource tierce.
5.1.2 — Test systématique CNAME externes
Niveau : 🟠
MITRE ATT&CK : T1584.001
Description : Tous les CNAME pointant hors apex doivent être testés contre la liste can-i-take-over-xyz.
Vérification :
dig <subdomain> CNAME +short
# Cross-référencer avec https://github.com/EdOverflow/can-i-take-over-xyz
Critères de validation :
- ✅ Audit mensuel automatisé
- ❌ Aucun audit
5.1.3 — Pas de CNAME loop (chaîne > 8)
Niveau : 🟡
Référence : RFC 1034 §3.6.2
Description : Chaîne CNAME > 8 niveaux = bug + DoS résolveur potentiel.
Critères de validation :
- ✅ Chaîne ≤ 8 niveaux
- ❌ Loop ou chaîne longue
5.1.4 — Pas de A record vers IP non-contrôlée
Niveau : 🔴
MITRE ATT&CK : T1584.001
Description : Un A record pointant vers une IP cloud libérée peut être réservé par un attaquant.
Critères de validation :
- ✅ Toutes IPs publiées sont contrôlées
- ❌ ≥ 1 A “fantôme”
5.1.5 — Pas de NS record délégable
Niveau : 🔴
MITRE ATT&CK : T1584.001
Description : Sous-domaine délégué à un NS dont le domaine n’est plus enregistré → takeover NS.
Vérification :
dig <subdomain> NS +short
for NS in $(dig <subdomain> NS +short); do
whois $(echo $NS | awk -F. '{print $(NF-1)"."$NF}') | grep -i "Domain Status"
done
Critères de validation :
- ✅ NS toujours enregistrés et contrôlés
- ❌ Domaine NS expiré → takeover possible
5.1.6 — Inventaire CT-log vs résolution actuelle
Niveau : 🟡
MITRE ATT&CK : T1584.001
Description : Sous-domaines visibles dans crt.sh mais NXDOMAIN aujourd’hui = anciens services candidats au takeover du service.
Vérification :
curl -s "https://crt.sh/?q=%25.<domaine>&output=json" | jq -r '.[].name_value' | sort -u
Critères de validation :
- ✅ Audit trimestriel CT-log
- ❌ Pas de monitoring
🌟 SECTION 6 — WILDCARD DNS
6.1.1 — Test wildcard A
Niveau : 🟡
Référence : RFC 1034 §4.3.3
MITRE ATT&CK : T1583.002
Description : Un wildcard A non-documenté peut piéger des sous-domaines aléatoires en pages de phishing.
Vérification :
for i in $(shuf -i 10000-99999 -n 20); do
dig random${i}.<domaine> A +short
done
Critères de validation :
- ✅ NXDOMAIN sur 20 tirages
- ❌ Wildcard répond
Remédiation : Supprimer wildcard ou documenter le scope business.
6.1.2 — Test wildcard AAAA / CNAME / TXT / MX
Niveau : 🟡
Description : Vérifier également les types AAAA, CNAME, TXT, MX.
Vérification :
for T in AAAA CNAME TXT MX; do
dig random12345.<domaine> $T +short
done
Critères de validation :
- ✅ Pas de wildcard non-documenté
- ❌ Wildcard caché
6.1.3 — Wildcard justifié business
Niveau : 🟢
Description : Si wildcard nécessaire (multi-tenant SaaS), documenter le scope et associer SPF/DKIM/DMARC adaptés.
Critères de validation :
- ✅ Wildcard documenté + DMARC
sp=reject - ❌ Wildcard non documenté
📧 SECTION 7 — SPF (RFC 7208)
7.1.1 — Record SPF unique à l’apex
Niveau : 🔴
Référence : RFC 7208 §3.2
MITRE ATT&CK : T1566.001
Description : RFC 7208 §3.2 : un seul record SPF par domaine. Multiples records = SPF invalide → permerror.
Vérification :
dig <domaine> TXT +short | grep -c "v=spf1"
Critères de validation :
- ✅ Exactement 1 record
v=spf1 - ❌ 0 ou ≥ 2
Remédiation : Fusionner les records via include:.
7.1.2 — ≤ 10 lookups DNS au total
Niveau : 🔴
Référence : RFC 7208 §4.6.4
Description : Limite stricte de 10 lookups (include, a, mx, ptr, redirect, exists). Au-delà = permerror → DMARC fail.
Vérification : https://dmarcian.com/spf-survey/
Critères de validation :
- ✅ ≤ 10 lookups
- ❌ > 10
Remédiation : Flatten SPF (résoudre includes en IPs), utiliser ip4:/ip6:.
7.1.3 — ≤ 2 void lookups
Niveau : 🟠
Référence : RFC 7208 §4.6.4
Description : Un void lookup = include vers un domaine qui ne retourne rien. Plus de 2 = permerror.
Critères de validation :
- ✅ ≤ 2 void
- ❌ > 2
7.1.4 — Mécanisme all présent
Niveau : 🔴
Référence : RFC 7208 §5.1
Description : Sans all, le SPF est neutre par défaut → tout passe.
Vérification :
dig <domaine> TXT +short | grep "v=spf1" | grep -E " (-|~|\?|\+)all"
Critères de validation :
- ✅
-allou~all - ❌
?allou absent
7.1.5 — Qualifier -all strict
Niveau : 🟠
Description : Pour domaines critiques, -all (hard fail) est préférable à ~all (soft fail).
Critères de validation :
- ✅
-all(cible) - ⚠️
~all(transition) - ❌
?allou+all
7.1.6 — Pas de mécanisme +all
Niveau : 🔴
Référence : RFC 7208 §10.1
Description : +all = whitelist mondiale → spoofing trivial. Faute critique.
Critères de validation :
- ✅ Pas de
+all - ❌
+allprésent
Remédiation : Réécrire le SPF immédiatement.
7.1.7 — Pas de mécanisme ptr
Niveau : 🟡
Référence : RFC 7208 §5.5
Description : ptr est déprécié (lent, peu fiable). Préférer ip4:/ip6:.
Critères de validation :
- ✅ Pas de
ptr - ❌ Présent
7.1.8 — Tous les émetteurs légitimes inclus
Niveau : 🟠
Description : Inventorier tous les MTAs émetteurs (M365, OVH, Mailchimp, Zendesk, SendGrid, Salesforce, ServiceNow, marketing tool) et inclure leurs SPF.
Critères de validation :
- ✅ Inventaire complet inclus
- ❌ Émetteur manquant
7.1.9 — Pas d’IP wildcard
Niveau : 🔴
Description : ip4:0.0.0.0/0 ou plages trop larges = whitelist mondiale.
Critères de validation :
- ✅ Aucune plage > /16
- ❌ Plage trop large
7.1.10 — IPv6 inclus si émetteurs IPv6
Niveau : 🟢
Référence : RFC 7208 §5.6
Critères de validation :
- ✅
ip6:présent - ❌ Émetteur IPv6 sans
ip6:
7.1.11 — Domaines non-émetteurs : v=spf1 -all
Niveau : 🟠
Référence : RFC 7208 / M3AAWG
Description : Tout domaine n’émettant pas d’email DOIT publier v=spf1 -all pour bloquer l’usurpation (parking domains).
Critères de validation :
- ✅
v=spf1 -allstrict - ❌ Absent
7.1.12 — Pas de SPF type 99 legacy
Niveau : 🟢
Référence : RFC 7208 §3.1
Description : Le record SPF type 99 (RFC 4408) est déprécié. Utiliser uniquement TXT.
Critères de validation :
- ✅ Pas de type 99
- ❌ Présent (legacy)
7.1.13 — Propagation < 5 min sur 4 résolveurs
Niveau : 🟢
Description : Après modification SPF, la nouvelle valeur doit se propager < 5 min (TTL respecté).
Critères de validation :
- ✅ Propagation OK
- ❌ Cache ancien
7.1.14 — Pas de macros SPF non justifiées
Niveau : 🟡
Référence : RFC 7208 §7
Description : Macros (%{i}, %{s}, %{l}) sont puissantes mais peuvent casser les limites de lookup.
Critères de validation :
- ✅ Pas de macros ou usage justifié
- ❌ Macros non maîtrisées
7.1.15 — Espaces et syntaxe valides
Niveau : 🟢
Description : Vérifier l’absence de fautes de syntaxe (double espaces, mécanismes mal écrits).
Critères de validation :
- ✅ Validation
dig+ outil online - ❌ Erreur permerror
7.1.16 — SPF ne se termine pas par redirect+all
Niveau : 🟡
Description : redirect= se substitue, ne pas le combiner avec all.
Critères de validation :
- ✅
redirect=SANSall - ❌ Mix incompatible
🚫 SECTION 8 — NULL MX (RFC 7505)
8.1.1 — Domaines non-émetteurs : MX 0 . publié
Niveau : 🟠
Référence : RFC 7505
MITRE ATT&CK : T1566
Description : RFC 7505 spécifie MX 0 . pour signaler “ce domaine ne reçoit pas d’email”, évitant les bounces et le spoofing.
Vérification :
dig <domaine> MX +short
Critères de validation :
- ✅
0 .retourné - ❌ Pas de MX ou MX inopérant
8.1.2 — Combiner avec v=spf1 -all + DMARC p=reject
Niveau : 🟠
Description : Le triplet NULL MX + SPF strict + DMARC reject est la posture maximale pour domaines parking.
Critères de validation :
- ✅ Triplet présent
- ❌ Manque
8.1.3 — Vérification dig MX retourne 0 .
Niveau : 🟢
Critères de validation :
- ✅ Réponse exacte
0 . - ❌ Autre
🔑 SECTION 9 — DKIM (RFC 6376)
9.1.1 — Au moins 1 sélecteur DKIM par émetteur
Niveau : 🔴
Référence : RFC 6376
MITRE ATT&CK : T1566.001
Description : Chaque émetteur (M365, Mailchimp, SendGrid) doit avoir son propre sélecteur publié à _domainkey.<domaine>.
Vérification :
for S in selector1 selector2 default mail dkim ovh google k1 mandrill sendgrid mxvault s1 s2; do
R=$(dig ${S}._domainkey.<domaine> TXT +short)
[ -n "$R" ] && echo "FOUND $S"
done
Critères de validation :
- ✅ ≥ 1 sélecteur par émetteur
- ❌ Aucun sélecteur
9.1.2 — Clé RSA ≥ 2048 bits OU Ed25519
Niveau : 🔴
Référence : RFC 8463 (Ed25519) / ANSSI 2024
Description : RSA-1024 est cassable par État-nation, proscrit par ANSSI 2024. Migration RSA-2048 ou Ed25519.
Vérification :
dig <selector>._domainkey.<domaine> TXT +short \
| grep -oP 'p=\K[^"; ]+' | base64 -d 2>/dev/null \
| openssl rsa -text -noout -pubin
Critères de validation :
- ✅ RSA ≥ 2048 ou Ed25519
- ❌ RSA-1024
9.1.3 — Pas d’algo rsa-sha1
Niveau : 🔴
Référence : RFC 8301
Description : SHA-1 est compromis (collisions Shattered 2017). Utiliser rsa-sha256 ou ed25519-sha256.
Critères de validation :
- ✅
a=rsa-sha256oua=ed25519-sha256 - ❌
a=rsa-sha1
9.1.4 — Tag v=DKIM1 présent
Niveau : 🟢
Référence : RFC 6376 §3.6.1
Critères de validation :
- ✅ Présent
- ❌ Absent (record invalide)
9.1.5 — Tag p= non-vide
Niveau : 🔴
Description : p= vide signale une révocation de clé. Tout email signé avec cette clé sera rejeté.
Critères de validation :
- ✅ Clé publique présente
- ❌ Vide ou absente
9.1.6 — Tag t=y ABSENT en production
Niveau : 🟠
Référence : RFC 6376 §3.6.1
Description : t=y (testing) demande aux receveurs de ne pas pénaliser les fails. À retirer après validation.
Critères de validation :
- ✅ Pas de
t=y - ❌
t=yen prod
9.1.7 — Tag t=s strict alignement
Niveau : 🟢
Description : t=s = sélecteur ne peut signer que pour le domaine exact (pas de sous-domaine).
Critères de validation :
- ✅
t=srecommandé - ⚠️ Absent (par défaut tolérant)
9.1.8 — Sélecteur unique par émetteur tiers
Niveau : 🟠
Description : Ne pas partager une clé entre prestataires (compromission isolée).
Critères de validation :
- ✅ 1 sélecteur dédié par émetteur
- ❌ Mutualisation de clé
9.1.9 — Rotation DKIM annuelle
Niveau : 🟡
Référence : M3AAWG / NIST SP 800-177
Description : Rotation annuelle minimum, semestrielle pour domaines sensibles.
Critères de validation :
- ✅ Rotation ≤ 12 mois
- ❌ Clé > 12 mois
9.1.10 — Calendrier rotation documenté
Niveau : 🟢
Critères de validation :
- ✅ Runbook + dates planifiées
- ❌ Pas de processus
9.1.11 — Anciens sélecteurs maintenus 30 j post-rotation
Niveau : 🟢
Description : Double-publication 30 j permet la validation des emails encore en transit/cache.
Critères de validation :
- ✅ Double publication maintenue
- ❌ Suppression immédiate
9.1.12 — Tag l= ABSENT (anti-replay)
Niveau : 🟠
Référence : Incident DKIM Replay 2024-2026
Description : Le tag l= (longueur signée) autorise l’ajout de contenu après signature. Vecteur d’attaque DKIM Replay (Mailgun outage, abus 2024+).
Critères de validation :
- ✅ Pas de
l= - ❌ Présent
9.1.13 — Tag x= (expiration) ~7 jours
Niveau : 🟡
Référence : RFC 6376 §3.5
Description : Limite la fenêtre de replay possible.
Critères de validation :
- ✅
x=< 7 j aprèst= - ❌ Absent ou trop long
9.1.14 — Tag t= (timestamp) présent
Niveau : 🟢
Critères de validation :
- ✅ Timestamp signé
- ❌ Absent
9.1.15 — Oversigning des en-têtes critiques
Niveau : 🟠
Description : Inclure deux fois From:From; Subject:Subject; Date:Date pour détecter ajout ultérieur (anti-replay).
Critères de validation :
- ✅ Oversigning From/Subject/Date/To/Reply-To
- ❌ Signature simple
9.1.16 — Message-ID, MIME-Version, Content-Type dans h=
Niveau : 🟢
Critères de validation :
- ✅ Headers inclus dans
h= - ❌ Absents
9.1.17 — Headers List-* signés si mailing list
Niveau : 🟢
Critères de validation :
- ✅
List-Unsubscribe,List-ID, etc. - ❌ Absents
9.1.18 — Canonicalization relaxed/relaxed
Niveau : 🟢
Description : Plus tolérant aux modifications mineures (whitespace, casse). simple/simple casse facilement.
Critères de validation :
- ✅
c=relaxed/relaxed - ⚠️
simple/simple
🛡️ SECTION 10 — DMARC (RFC 7489 / RFC 9091)
10.1.1 — Record _dmarc présent
Niveau : 🔴
Référence : RFC 7489
MITRE ATT&CK : T1566.001
Description : Sans DMARC, aucun reporting ni politique d’application. Gmail/Yahoo Bulk Sender 2024 exigent DMARC pour > 5 000 emails/j.
Vérification :
dig _dmarc.<domaine> TXT +short
Critères de validation :
- ✅ Record présent
- ❌ Absent
10.1.2 — Tag v=DMARC1 en premier
Niveau : 🟢
Référence : RFC 7489 §6.3
Critères de validation :
- ✅
v=DMARC1premier tag - ❌ Mauvais ordre
10.1.3 — Politique p=reject cible
Niveau : 🔴
Description : Roadmap : p=none (audit) → p=quarantine (transition 30-90 j) → p=reject (cible). Reject = mitigation BEC effective.
Critères de validation :
- ✅
p=reject - ⚠️
p=quarantine - ❌
p=nonedurable
10.1.4 — Tag sp= (sous-domaines) strict
Niveau : 🟠
Référence : RFC 7489 §6.3
Description : sp= doit être au moins aussi strict que p=.
Critères de validation :
- ✅
sp=reject - ❌
sp=noneou absent
10.1.5 — Tag np=reject (RFC 9091)
Niveau : 🟠
Référence : RFC 9091
Description : np= (non-existent subdomains policy) protège contre l’usurpation de sous-domaines inexistants.
Critères de validation :
- ✅
np=reject - ❌ Absent (sous-domaines fantômes spoofables)
10.1.6 — pct=100 en production
Niveau : 🟠
Description : pct= < 100 = échantillonnage, utile en transition uniquement.
Critères de validation :
- ✅
pct=100 - ⚠️ Transition documentée
- ❌
pctfaible permanent
10.1.7 — adkim=s strict
Niveau : 🟠
Description : Strict alignment DKIM = From: doit matcher exactement le domaine signé.
Critères de validation :
- ✅
adkim=s - ⚠️
adkim=r(relaxed, par défaut)
10.1.8 — aspf=s strict
Niveau : 🟠
Critères de validation :
- ✅
aspf=s - ⚠️
aspf=r
10.1.9 — Tag rua= valide
Niveau : 🟠
Description : RUA = aggregate reports (XML quotidien). Indispensable pour visibilité.
Vérification :
dig _dmarc.<domaine> TXT +short | grep -oP 'rua=\K[^;]+'
Critères de validation :
- ✅
rua=mailto:dmarc-rua@... - ❌ Absent
10.1.10 — Tag ruf= (forensic) optionnel
Niveau : 🟢
Description : RUF = échantillons d’emails frauduleux. Attention RGPD : peut contenir des données personnelles.
Critères de validation :
- ✅ Présent + DPA RGPD signé
- N/A si non utilisé
10.1.11 — Tag fo=1:d:s complet
Niveau : 🟢
Description : fo=1 = report dès qu’un test échoue, fo=d = DKIM, fo=s = SPF.
Critères de validation :
- ✅
fo=1 - ❌ Absent
10.1.12 — Boîte RUA monitorée
Niveau : 🟠
Description : Boîte RUA doit parser le XML quotidien (parsedmarc, DMARCian, EasyDMARC).
Critères de validation :
- ✅ Parser actif + alertes
- ❌ Boîte morte
10.1.13 — Cross-domain RUA autorisé
Niveau : 🟢
Référence : RFC 7489 §7.1
Description : Si rua pointe vers domaine externe, ce dernier doit publier <destdomain>._report._dmarc.<src> TXT autorisant.
Vérification :
dig <destdomain>._report._dmarc.<src> TXT +short
Critères de validation :
- ✅ Authorization présente
- ❌ Absente → reports rejetés
10.1.14 — Service tiers RUA conforme RGPD
Niveau : 🟡
Référence : RGPD / DPA
Description : Si RUA hébergé hors UE (DMARCian US, Valimail US), DPA RGPD requis.
Critères de validation :
- ✅ DPA signé ou hébergement UE
- ❌ Aucun DPA
10.1.15 — Tags dans l’ordre RFC
Niveau : 🟢
Description : Ordre standard : v;p;sp;np;adkim;aspf;pct;fo;ri;rua;ruf;rf.
10.1.16 — Pas de tag inconnu
Niveau : 🟢
Description : Tags non-RFC sont ignorés mais peuvent indiquer une typo.
🔄 SECTION 11 — ARC (RFC 8617)
11.1.1 — ARC implémenté sur forwarders
Niveau : 🟢
Référence : RFC 8617
Description : ARC (Authenticated Received Chain) préserve la chaîne d’authentification après forwarding (mailing lists internes).
Critères de validation :
- ✅ MTA forwarder produit ARC-Seal
- N/A si pas de forwarding
11.1.2 — En-tête ARC-Authentication-Results présent
Niveau : 🟢
11.1.3 — En-tête ARC-Message-Signature présent
Niveau : 🟢
11.1.4 — En-tête ARC-Seal présent
Niveau : 🟢
11.1.5 — Clés ARC publiées comme DKIM
Niveau : 🟢
Critères de validation :
- ✅ Sélecteurs
_domainkeyARC - ❌ Pas de clé
11.1.6 — Chain validation cv=pass
Niveau : 🟢
🔒 SECTION 12 — MTA-STS (RFC 8461)
12.1.1 — Sous-domaine mta-sts.<domaine> résout
Niveau : 🟠
Référence : RFC 8461
MITRE ATT&CK : T1557 (downgrade)
Description : MTA-STS empêche les downgrades STARTTLS en publiant une politique HTTPS.
Vérification :
dig mta-sts.<domaine> A +short
Critères de validation :
- ✅ A/CNAME résout
- ❌ Pas de host
12.1.2 — Fichier mta-sts.txt accessible
Niveau : 🟠
Vérification :
curl -sk https://mta-sts.<domaine>/.well-known/mta-sts.txt
Critères de validation :
- ✅ HTTP 200, contenu valide
- ❌ 404 ou erreur TLS
12.1.3 — Certificat HTTPS publiquement trust
Niveau : 🟠
Description : Self-signed = MTA-STS inopérant.
Critères de validation :
- ✅ AC publique (Let’s Encrypt OK)
- ❌ Self-signed
12.1.4 — TXT _mta-sts.<domaine> publié
Niveau : 🟠
Vérification :
dig _mta-sts.<domaine> TXT +short
Critères de validation :
- ✅
v=STSv1; id=... - ❌ Absent
12.1.5 — Tag id unique à chaque modification
Niveau : 🟢
Description : L’ID change à chaque update de policy pour invalider les caches MTA.
12.1.6 — version: STSv1
Niveau : 🟢
12.1.7 — mode: enforce cible
Niveau : 🔴
Description : Roadmap : testing (14 j) → enforce (cible). Mode testing permanent = aucune protection.
Critères de validation :
- ✅
mode: enforce - ⚠️
mode: testing< 14 j - ❌
mode: none
12.1.8 — mx: cohérent avec record MX DNS
Niveau : 🟠
Description : Tous les MX listés dans la policy doivent matcher les MX DNS, sinon MTA-STS bloque le mail.
Critères de validation :
- ✅ Match exact
- ❌ Divergence
12.1.9 — max_age: raisonnable
Niveau : 🟢
Description : Recommandé 86400 (24h) à 31557600 (1 an). Trop court = pas de cache, trop long = update lent.
Critères de validation :
- ✅ 86400 ≤ max_age ≤ 31557600
- ❌ Hors plage
12.1.10 — MX wildcard si multi-tenant
Niveau : 🟢
Description : Pour M365 (*.mail.protection.outlook.com), supporter le wildcard.
12.1.11 — mta-sts.txt cacheable (no cookie)
Niveau : 🟢
Description : Pas de header Set-Cookie, sinon les CDNs peuvent ne pas cacher correctement.
📊 SECTION 13 — TLS-RPT (RFC 8460)
13.1.1 — TXT _smtp._tls.<domaine> publié
Niveau : 🟠
Référence : RFC 8460
Description : TLS-RPT donne la visibilité sur les échecs TLS / downgrades détectés par les MTAs distants.
Vérification :
dig _smtp._tls.<domaine> TXT +short
Critères de validation :
- ✅ Record présent
- ❌ Absent
13.1.2 — Tag v=TLSRPTv1 en premier
Niveau : 🟢
13.1.3 — rua=mailto: ou https://
Niveau : 🟠
Critères de validation :
- ✅ Endpoint valide
- ❌ Absent
13.1.4 — Service de réception RUA opérationnel
Niveau : 🟢
13.1.5 — Parsing automatique XML / JSON
Niveau : 🟢
Description : parsedmarc TLS-RPT, URIports, EasyDMARC.
13.1.6 — Alertes sur échecs TLS
Niveau : 🟢
🎨 SECTION 14 — BIMI (Brand Indicators for Message Identification)
14.1.1 — Pré-requis : DMARC p=quarantine ou p=reject
Niveau : 🟠
Référence : BIMI Group v1.0
Description : BIMI exige DMARC enforcement strict avant d’autoriser l’affichage du logo.
Critères de validation :
- ✅
p=quarantineoup=reject - ❌
p=none
14.1.2 — TXT default._bimi.<domaine> publié
Niveau : 🟢
Vérification :
dig default._bimi.<domaine> TXT +short
14.1.3 — Tag v=BIMI1
Niveau : 🟢
14.1.4 — Tag l=https:// URL logo SVG
Niveau : 🟢
Description : SVG hosted en HTTPS only.
14.1.5 — Tag a=https:// certificat VMC ou CMC
Niveau : 🟢
Description : VMC = Verified Mark Certificate (TM déposé), CMC = Common Mark Certificate (12+ mois usage).
14.1.6 — Logo SVG conforme SVG Tiny PS
Niveau : 🟢
Référence : bimigroup.org/check-svg-logo-validity
Description : Profile Tiny + Portable Subset, sans scripts ni animations.
14.1.7 — SVG sans scripts/animations/links externes
Niveau : 🟢
14.1.8 — Format square 1:1, ≥ 96x96px
Niveau : 🟢
14.1.9 — VMC ou CMC valide
Niveau : 🟢
Description : VMC ~1500 €/an (TM déposé), CMC ~300 €/an (12+ mois).
14.1.10 — Test rendu Gmail / Apple Mail / Yahoo
Niveau : 🟢
14.1.11 — Test sur boîte La Poste Mail (FR)
Niveau : 🟢
📬 SECTION 15 — LIST-UNSUBSCRIBE (RFC 9261 / Gmail-Yahoo 2024)
15.1.1 — Header List-Unsubscribe présent
Niveau : 🟠
Référence : RFC 2369
MITRE ATT&CK : N/A
Description : Obligatoire Gmail/Yahoo Bulk Sender 2024 pour > 5 000 emails/j.
Critères de validation :
- ✅ Présent sur emails marketing
- ❌ Absent
15.1.2 — Header List-Unsubscribe-Post: List-Unsubscribe=One-Click
Niveau : 🟠
Référence : RFC 9261
Description : Obligatoire Gmail/Yahoo 2024.
15.1.3 — URLs mailto: ET https://
Niveau : 🟢
15.1.4 — Spam rate Postmaster Tools < 0.3 %
Niveau : 🟠
Référence : Google Postmaster Tools
15.1.5 — Sender domain cohérent avec From:
Niveau : 🟠
🧬 SECTION 16 — DKIM ATPS / DMARC PSD
16.1.1 — DKIM ATPS pour signataires tiers (RFC 6541)
Niveau : 🟢
Description : Si un tiers signe avec son propre domaine pour le compte du client, ATPS autorise nominativement.
16.1.2 — Format v=ATPS1; d=<tiers>
Niveau : 🟢
16.1.3 — DMARC PSD pour TLD/PSL (RFC 9091)
Niveau : 🟢
Description : Pertinent uniquement pour registries (gov.fr, ac.uk).
🛡️ SECTION 17 — DNSSEC (RFC 4033-4035)
17.1.1 — Zone signée : DNSKEY publiés
Niveau : 🔴
Référence : RFC 4033/4034/4035 / NIS2
MITRE ATT&CK : T1565.001
Description : DNSSEC garantit l’intégrité et l’authenticité des réponses DNS via signatures cryptographiques. Recommandation NIS2 forte pour entités essentielles.
Vérification :
dig <domaine> DNSKEY +multiline
Critères de validation :
- ✅ KSK + ZSK publiés
- ❌ Aucune DNSKEY
17.1.2 — DS records publiés au TLD parent
Niveau : 🔴
Référence : RFC 4035 §2.4
Description : Sans DS au TLD, la chaîne de confiance est brisée.
Vérification :
dig <domaine> DS +multiline
Critères de validation :
- ✅ DS publié au TLD
- ❌ Absent
17.1.3 — Algorithme 13 (ECDSA P-256) ou 15 (Ed25519)
Niveau : 🟠
Référence : RFC 8624 / ANSSI 2024
Description : Algorithmes recommandés. RSA-SHA256 (8) toléré mais à migrer.
Critères de validation :
- ✅ Algo 13 ou 15
- ⚠️ Algo 8 (RSA-SHA256)
- ❌ Algo 5 ou 7 (RSA-SHA1)
17.1.4 — PAS d’algorithme 5 ou 7 (RSA-SHA1)
Niveau : 🔴
Référence : RFC 8624 §3.1
Critères de validation :
- ✅ Pas d’algo 5/7
- ❌ Présent
17.1.5 — Digest type 2 (SHA-256) pour DS
Niveau : 🟠
Référence : RFC 8624 §3.3
Critères de validation :
- ✅ Digest 2
- ❌ Digest 1 (SHA-1)
17.1.6 — KSK ≥ 2048 bits si RSA, 256 bits ECDSA
Niveau : 🟠
Critères de validation :
- ✅ Tailles conformes
- ❌ KSK 1024 bits
17.1.7 — ZSK ≥ 1024 bits si RSA
Niveau : 🟢
17.1.8 — Rollover KSK annuel ou biennal
Niveau : 🟢
Référence : RFC 7583
17.1.9 — Rollover ZSK trimestriel à annuel
Niveau : 🟢
17.1.10 — NSEC3 avec iterations ≤ 100
Niveau : 🟢
Référence : RFC 9276
Description : NSEC3 anti-zone-walking, mais iterations excessives = DoS résolveur.
Critères de validation :
- ✅ iterations ≤ 100
- ❌ > 100
17.1.11 — NSEC3 (pas NSEC) sur zones publiques
Niveau : 🟢
Description : NSEC permet le zone-walking (énumération complète).
Critères de validation :
- ✅ NSEC3
- ⚠️ NSEC (zone publique)
17.1.12 — NSEC3 salt rotates avec ZSK
Niveau : 🟢
17.1.13 — RRSIG validity 1-2 semaines
Niveau : 🟢
Description : Trop court = re-signing fréquent, trop long = exposition compromise.
17.1.14 — RRSIG inception non future
Niveau : 🟠
17.1.15 — RRSIG expiration non passée
Niveau : 🔴
Description : Une signature expirée = SERVFAIL côté résolveur validant. Catastrophique (incident SLAAC, .gov, .com périodiquement).
17.1.16 — Validation chaîne via dnsviz.net
Niveau : 🟠
Vérification : https://dnsviz.net/d/
Critères de validation :
- ✅ Tout vert
- ❌ Erreurs
17.1.17 — Flag ad retourné
Niveau : 🟠
dig +dnssec <domaine> SOA | grep " ad "
17.1.18 — Test SERVFAIL si signature corrompue
Niveau : 🟢
Description : Validation effective des résolveurs.
17.1.19 — Multi-Signer DNSSEC (RFC 8901)
Niveau : 🟢
Référence : RFC 8901
Description : Si NS secondaire externe avec DNSSEC, schéma Multi-Signer Model 1 ou 2.
17.1.20 — CDS / CDNSKEY publiés (RFC 7344)
Niveau : 🟢
Référence : RFC 7344 / RFC 8078
Description : Permet rollover automatique du DS via CDS scan du parent.
Vérification :
dig <domaine> CDS CDNSKEY +short
Critères de validation :
- ✅ Publiés et cohérents
- ❌ Absents
17.1.21 — Registrar supporte CDS rollover automatique
Niveau : 🟢
Description : OVH, Cloudflare, Gandi supportent. Vérifier au cas par cas.
17.1.22 — Test removal CDS = 0 0 0
Niveau : 🟢
Référence : RFC 8078
🔐 SECTION 18 — DANE / TLSA (RFC 6698 / 7672)
18.1.1 — Pré-requis : DNSSEC actif et validant
Niveau : 🟠
Description : TLSA repose sur DNSSEC : sans, aucune confiance.
18.1.2 — TLSA SMTP _25._tcp.<mx-host>
Niveau : 🟠
Référence : RFC 7672
Vérification :
dig _25._tcp.mail.<domaine> TLSA +short
Critères de validation :
- ✅ Record présent et hash valide
- ❌ Absent
18.1.3 — TLSA submission 587 / 465 si supportés
Niveau : 🟢
18.1.4 — TLSA HTTPS _443._tcp.<host> (optionnel)
Niveau : 🟢
18.1.5 — Usage = 3 (DANE-EE) recommandé pour SMTP
Niveau : 🟠
Référence : RFC 7672 §3.1.3
18.1.6 — Selector = 1 (SPKI) recommandé
Niveau : 🟢
18.1.7 — Matching = 1 (SHA-256)
Niveau : 🟢
18.1.8 — Hash matche la clé publique active
Niveau : 🔴
Description : Mismatch = SMTP rejected par MTA DANE-aware.
18.1.9 — Rollover : 2 TLSA records lors du renouvellement
Niveau : 🟠
Description : Publier le nouveau TLSA ≥ TTL avant la rotation effective.
18.1.10 — TLSA pour chaque MX preference
Niveau : 🟢
18.1.11 — STARTTLS obligatoire sur serveurs TLSA
Niveau : 🟠
✉️ SECTION 19 — SMIMEA (RFC 8162) / OPENPGPKEY (RFC 7929)
19.1.1 — SMIMEA records publiés
Niveau : 🟢
Référence : RFC 8162
Description : Distribution des certificats S/MIME via DNS (avec DNSSEC).
Vérification :
HASH=$(echo -n "user" | sha256sum | head -c56)
dig ${HASH}._smimecert.<domaine> SMIMEA +short
19.1.2 — Hash localpart sha256 56 premiers chars
Niveau : 🟢
19.1.3 — Usage 3 (DANE-EE) recommandé
Niveau : 🟢
19.1.4 — Selector 0 (full cert) ou 1 (SPKI)
Niveau : 🟢
19.1.5 — OPENPGPKEY records publiés
Niveau : 🟢
Référence : RFC 7929
19.1.6 — Alternative WKD (Web Key Directory)
Niveau : 🟢
Description : /.well-known/openpgpkey/... URL publique HTTPS.
🔏 SECTION 20 — CAA (RFC 8659 / 8657)
20.1.1 — Records CAA publiés à l’apex
Niveau : 🟠
Référence : RFC 8659 / CA/B Forum
MITRE ATT&CK : T1583.004 (mis-issuance)
Description : CAA restreint quelles AC peuvent émettre des certificats. CA/B Forum impose la vérification CAA.
Vérification :
dig <domaine> CAA +short
Critères de validation :
- ✅ ≥ 1 record CAA
- ❌ Absent (toute AC peut émettre)
20.1.2 — Tag issue restreint
Niveau : 🟠
Description : 0 issue "letsencrypt.org" autorise uniquement Let’s Encrypt.
20.1.3 — Tag issuewild ";" interdit wildcards
Niveau : 🟢
Description : Si pas besoin de wildcard, bloquer pour limiter abus.
20.1.4 — Tag iodef
Niveau : 🟡
Référence : RFC 8659 §4.1.2
Description : Reception des reports d’incidents (mailto: ou https://).
20.1.5 — Tag accounturi (RFC 8657)
Niveau : 🟠
Référence : RFC 8657
Description : Binding au compte ACME, limite à 1 compte précis.
20.1.6 — Tag validationmethods
Niveau : 🟠
Référence : RFC 8657
Description : Restreint aux méthodes ACME dns-01 (anti-HTTP-01 hijack).
Critères de validation :
- ✅
validationmethods=dns-01 - ❌ Absent
20.1.7 — Tag contactemail (RFC 8659 §4.1.3)
Niveau : 🟢
20.1.8 — Tag contactphone
Niveau : 🟢
20.1.9 — CAA tree-walking sous-domaines
Niveau : 🟢
Description : Si sous-domaine utilise une AC différente, CAA spécifique sur le sous-domaine.
20.1.10 — Vérification crt.sh anti mis-issuance
Niveau : 🟠
Vérification :
curl -s "https://crt.sh/?q=%25.<domaine>&output=json" | jq '.[].issuer_name' | sort -u
Critères de validation :
- ✅ Tous les certificats émis par AC autorisées
- ❌ AC non-listées dans CAA
🍪 SECTION 21 — DNS COOKIE (RFC 7873)
21.1.1 — NS authoritatifs supportent DNS COOKIE
Niveau : 🟢
Référence : RFC 7873
Description : DNS COOKIE mitige off-path spoofing (Kaminsky-like).
Vérification :
dig +cookie <domaine> SOA | grep COOKIE
Critères de validation :
- ✅
COOKIE: ... (good) - ❌ Pas de cookie
21.1.2 — Réponse (good) côté dig +cookie
Niveau : 🟢
21.1.3 — Résolveurs valident server cookie
Niveau : 🟢
🏷️ SECTION 22 — EXTENDED DNS ERRORS (EDE, RFC 8914)
22.1.1 — NS retournent codes EDE sur erreurs DNSSEC
Niveau : 🟢
Référence : RFC 8914
Description : Codes EDE (3=stale, 6=Bogus, 7=Signature Expired, 9=Unknown DS) facilitent diagnostic.
22.1.2 — Codes EDE documentés en runbook
Niveau : 🟢
22.1.3 — Diagnostic post-incident basé sur EDE
Niveau : 🟢
📦 SECTION 23 — ZONEMD (RFC 8976)
23.1.1 — Record ZONEMD publié à l’apex (optionnel)
Niveau : 🟢
Référence : RFC 8976
Description : Hash cryptographique de la zone, validation post-AXFR.
Vérification :
dig <domaine> ZONEMD +short
23.1.2 — Algorithme SHA-384 ou SHA-512
Niveau : 🟢
23.1.3 — Validation named-checkzone -i full
Niveau : 🟢
🔐 SECTION 24 — SSHFP (RFC 4255)
24.1.1 — Pré-requis : DNSSEC actif
Niveau : 🟠
Description : Sans DNSSEC, SSHFP est trivialement falsifiable.
24.1.2 — SSHFP records publiés par hôte SSH
Niveau : 🟢
Référence : RFC 4255
Vérification :
dig <ssh-host> SSHFP +short
24.1.3 — Algorithme RSA (1) + Ed25519 (4)
Niveau : 🟢
Description : Pas DSA (2), ECDSA (3) seul.
24.1.4 — Hash type 2 (SHA-256)
Niveau : 🟢
Description : Pas type 1 (SHA-1).
24.1.5 — Documentation utilisateur VerifyHostKeyDNS yes
Niveau : 🟢
24.1.6 — Rotation SSHFP avec rotation host keys
Niveau : 🟢
🌐 SECTION 25 — HTTPS RR / SVCB (RFC 9460)
25.1.1 — Records HTTPS publiés à l’apex et www
Niveau : 🟡
Référence : RFC 9460
Description : SVCB/HTTPS RR publie alpn (h2/h3), port, ipv4/v6 hints, ECH config en un seul lookup.
Vérification :
dig <domaine> HTTPS +short
Critères de validation :
- ✅ Record HTTPS publié
- ❌ Absent (HTTP/3 non négociable côté DNS)
25.1.2 — Tag alpn=h2,h3
Niveau : 🟢
25.1.3 — Tag port= si != 443
Niveau : 🟢
25.1.4 — Tags ipv4hint= / ipv6hint= (optionnel 0-RTT)
Niveau : 🟢
25.1.5 — Tag ech= (Encrypted Client Hello)
Niveau : 🟢
Référence : RFC 9180
Description : ECH chiffre le SNI (anti-censure, anti-fingerprinting).
Vérification : https://defo.ie/ech-check.php
25.1.6 — Serveur web supporte HTTP/3 (QUIC)
Niveau : 🟢
25.1.7 — Test Chrome HTTP/3 négocié
Niveau : 🟢
25.1.8 — ECH config valide
Niveau : 🟢
🛣️ SECTION 26 — RPKI / Route Origin Validation (RFC 6480)
26.1.1 — ROA publié pour chaque préfixe
Niveau : 🟠
Référence : RFC 6480 / RFC 6482
MITRE ATT&CK : T1584.005
Description : ROA (Route Origin Authorization) signe l’autorisation pour un AS d’annoncer un préfixe. Mitige BGP hijack (incident KlaySwap 2022, AWS Route53 2018).
Vérification :
# Lookup via origin.asn.cymru.com
dig <reverse_ip>.origin.asn.cymru.com TXT +short
# Ou stat.ripe.net
curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS<asn>&prefix=<prefix>"
Critères de validation :
- ✅ ROA publié et
valid - ❌
unknownouinvalid
26.1.2 — maxLength configuré
Niveau : 🟠
Description : Sans maxLength, sub-prefixes hijackable.
26.1.3 — ROA cohérent avec annonces BGP réelles
Niveau : 🟠
26.1.4 — IRR object cohérent (RIPE/ARIN/APNIC)
Niveau : 🟢
26.1.5 — AS publié = AS dans ROA
Niveau : 🟢
26.1.6 — Veille ASPA (RFC 9774)
Niveau : 🟢
Référence : RFC 9774
Description : Successeur RPKI 2024 pour validation de chemin (path) AS.
🔒 SECTION 27 — DoT / DoH / DoQ sur NS authoritatifs
27.1.1 — Port 853/TCP (DoT) ouvert sur NS auth
Niveau : 🟢
Référence : RFC 9230
27.1.2 — Port 443/TCP (DoH)
Niveau : 🟢
27.1.3 — Port 853/UDP (DoQ)
Niveau : 🟢
Référence : RFC 9250
27.1.4 — Certificat DoT/DoH valide
Niveau : 🟠
27.1.5 — Test kdig @<ns> +tls
Niveau : 🟢
kdig @<ns> +tls <domaine> SOA
27.1.6 — Configuration enterprise DoH côté client
Niveau : 🟢
27.1.7 — Résolveurs DoH approuvés
Niveau : 🟢
Description : 1.1.1.1, 8.8.8.8, ou résolveur interne.
27.1.8 — Bypass DoH navigateur (force enterprise)
Niveau : 🟢
🧬 SECTION 28 — Post-Quantum readiness
28.1.1 — Veille TLS hybrid KEM (X25519MLKEM768)
Niveau : 🟢
Référence : draft-ietf-tls-hybrid-design
Description : Cloudflare/Google déploient X25519MLKEM768 depuis 2024 pour anti “harvest now decrypt later”.
28.1.2 — Veille FIPS 203 (ML-KEM)
Niveau : 🟢
Référence : NIST FIPS 203, août 2024
28.1.3 — Veille FIPS 204 (ML-DSA) signatures
Niveau : 🟢
Référence : NIST FIPS 204
28.1.4 — Veille FIPS 205 (SLH-DSA / SPHINCS+)
Niveau : 🟢
Référence : NIST FIPS 205
28.1.5 — Inventaire certificats long-terme (>5 ans)
Niveau : 🟢
Description : Candidats migration PQ.
28.1.6 — Veille DNSSEC PQ (draft-ietf-dnsop-pqc)
Niveau : 🟢
Description : ML-DSA pour DNSSEC est en draft IETF, déploiement attendu 2027+.
📨 SECTION 29 — HARDENING MTA / SMTP
29.1.1 — Banner SMTP minimaliste
Niveau : 🟡
Référence : RFC 5321 §4.2
MITRE ATT&CK : T1592.004
Description : Pas de version logicielle dans le banner.
Vérification :
swaks --to test@<domaine> --quit-after BANNER
29.1.2 — VRFY désactivé
Niveau : 🟠
Référence : RFC 5321 §7.3
Description : VRFY énumère les utilisateurs valides.
29.1.3 — EXPN désactivé
Niveau : 🟠
Description : EXPN énumère les mailing lists.
29.1.4 — ETRN désactivé sauf usage justifié
Niveau : 🟢
29.1.5 — Open relay test
Niveau : 🔴
Référence : RFC 5321 §3.5
Description : Test MAIL FROM externe + RCPT TO externe doit retourner 5xx.
Vérification :
swaks --server <mx> --from [email protected] --to [email protected]
29.1.6 — STARTTLS active sur 25/587/465
Niveau : 🟠
29.1.7 — TLS 1.2 minimum (TLS 1.3 recommandé)
Niveau : 🟠
29.1.8 — Cipher suites sans RC4/3DES/EXPORT/NULL
Niveau : 🟠
29.1.9 — Certificat MTA valide
Niveau : 🟠
29.1.10 — FCrDNS cohérent (PTR = HELO)
Niveau : 🟠
29.1.11 — HELO/EHLO = FQDN du serveur
Niveau : 🟢
29.1.12 — Greylisting actif
Niveau : 🟢
29.1.13 — SMTP submission 587 + AUTH SASL
Niveau : 🟢
29.1.14 — SMTPS 465 (TLS implicite, RFC 8314)
Niveau : 🟢
29.1.15 — IMAPS 993 / POP3S 995 (pas en clair)
Niveau : 🟠
29.1.16 — REQUIRETLS (RFC 8689) si supporté
Niveau : 🟢
29.1.17 — SMTPUTF8 / EAI (RFC 6530)
Niveau : 🟢
29.1.18 — Rate limiting connexions
Niveau : 🟢
29.1.19 — Tarpit / RBL pre-DATA filter
Niveau : 🟢
29.1.20 — DSN RFC 3461 actif si pertinent
Niveau : 🟢
🌍 SECTION 30 — HARDENING WEB (TLS / Headers)
30.1.1 — Header Strict-Transport-Security HSTS
Niveau : 🟠
Référence : RFC 6797
Description : max-age=63072000; includeSubDomains; preload.
Vérification :
curl -skI https://<domaine> | grep -i "strict-transport-security"
30.1.2 — Header Content-Security-Policy CSP
Niveau : 🟠
Description : default-src 'self'; ...
30.1.3 — Header X-Content-Type-Options: nosniff
Niveau : 🟢
30.1.4 — Header X-Frame-Options: DENY
Niveau : 🟢
Description : Ou via CSP frame-ancestors.
30.1.5 — Header Referrer-Policy: strict-origin-when-cross-origin
Niveau : 🟢
30.1.6 — Header Permissions-Policy
Niveau : 🟢
30.1.7 — Headers Cross-Origin-* (COEP/CORP/COOP)
Niveau : 🟢
30.1.8 — HSTS preload list submission
Niveau : 🟢
Référence : hstspreload.org
30.1.9 — Pas de leak Server: / X-Powered-By:
Niveau : 🟢
30.1.10 — TLS 1.3 active, TLS 1.2 acceptable
Niveau : 🟠
30.1.11 — Pas de SSLv2/v3, TLS 1.0/1.1
Niveau : 🟠
30.1.12 — Cipher suites ECDHE + AEAD
Niveau : 🟠
30.1.13 — Pas de RC4/3DES/EXPORT/NULL/MD5
Niveau : 🟠
30.1.14 — TLS session ticket key rotation
Niveau : 🟢
30.1.15 — TLS 1.3 0-RTT désactivé si non idempotent
Niveau : 🟢
30.1.16 — OCSP stapling actif
Niveau : 🟢
30.1.17 — Score testssl.sh A+ minimum
Niveau : 🟢
30.1.18 — Score Mozilla Observatory A+
Niveau : 🟢
30.1.19 — Cert chain sans expiré
Niveau : 🟠
30.1.20 — CT log ≥ 2 SCTs
Niveau : 🟢
📁 SECTION 31 — /.well-known/ files (RFC 9116 / RFC 8615)
31.1.1 — /.well-known/security.txt présent
Niveau : 🟡
Référence : RFC 9116
Vérification :
curl -sI https://<domaine>/.well-known/security.txt
31.1.2 — Contact: mailto valide
Niveau : 🟡
31.1.3 — Expires: ISO 8601 max 1 an
Niveau : 🟢
31.1.4 — Encryption: (PGP key URL)
Niveau : 🟢
31.1.5 — Acknowledgments / Hall-of-fame
Niveau : 🟢
31.1.6 — Preferred-Languages
Niveau : 🟢
31.1.7 — Canonical: self URL
Niveau : 🟢
31.1.8 — Policy: vulnerability disclosure
Niveau : 🟢
31.1.9 — Signature PGP security.txt.sig
Niveau : 🟢
31.1.10 — /.well-known/change-password (RFC 8615)
Niveau : 🟢
31.1.11 — /.well-known/openpgpkey/ (WKD)
Niveau : 🟢
31.1.12 — /apple-app-site-association
Niveau : 🟢
31.1.13 — /.well-known/assetlinks.json (Android)
Niveau : 🟢
31.1.14 — /.well-known/jwks.json (OIDC)
Niveau : 🟢
🌐 SECTION 32 — REVERSE DNS / IP HYGIENE
32.1.1 — PTR cohérent A→PTR→A pour toutes IPs émettrices
Niveau : 🟠
32.1.2 — PTR IPv6 si AAAA actif
Niveau : 🟡
32.1.3 — PTR FQDN = HELO MTA (Yahoo/Gmail)
Niveau : 🟠
32.1.4 — BCP 38 anti-spoofing côté ISP
Niveau : 🟢
Référence : RFC 2827 / BCP 38
32.1.5 — RPKI ROA maxLength configuré
Niveau : 🟠
32.1.6 — IRR object cohérent avec ROA
Niveau : 🟢
32.1.7 — ASPA si supporté (RFC 9774)
Niveau : 🟢
32.1.8 — IP non partagée avec service spammant
Niveau : 🟠
🛡️ SECTION 33 — REPUTATION / THREAT INTELLIGENCE
33.1.1 — IPs clean Spamhaus ZEN/SBL/CSS/PBL
Niveau : 🟠
Vérification :
for IP in <ips>; do
REV=$(echo $IP | awk -F. '{print $4"."$3"."$2"."$1}')
dig ${REV}.zen.spamhaus.org A +short
done
33.1.2 — IPs clean SpamCop / Barracuda / SORBS / UCEPROTECT
Niveau : 🟠
33.1.3 — Domaine clean Spamhaus DBL / SURBL / URIBL / Talos
Niveau : 🟠
33.1.4 — Microsoft SNDS actif
Niveau : 🟢
33.1.5 — Google Postmaster Tools actif
Niveau : 🟠
33.1.6 — Yahoo Sender Hub actif
Niveau : 🟢
33.1.7 — HIBP / DeHashed monitoring leak credentials
Niveau : 🟢
33.1.8 — Passive DNS monitoring (DNSDB / SecurityTrails)
Niveau : 🟢
33.1.9 — CT-log monitoring (alerte certificats)
Niveau : 🟠
# crt.sh API ou certstream
33.1.10 — Phishtank / OpenPhish monitoring marque
Niveau : 🟢
🪞 SECTION 34 — TYPOSQUATTING / BRAND MONITORING
34.1.1 — Scan dnstwist mensuel
Niveau : 🟡
dnstwist --registered <domaine>
34.1.2 — Pré-emption typosquats critiques (~10 domaines)
Niveau : 🟢
Description : ~250 €/an, ROI immédiat vs phishing.
34.1.3 — Punycode xn-- variants surveillés
Niveau : 🟡
Description : IDN homograph (cas Apple aplle.com 2017).
34.1.4 — Combosquats <marque>-<partenaire>.<TLD> pré-emptés
Niveau : 🟢
34.1.5 — TLD-squatting .com/.io/.app/.aero/.eu évalué
Niveau : 🟢
34.1.6 — CT-log brand monitoring *<marque>*
Niveau : 🟡
34.1.7 — Procédure UDRP / SYRELI documentée
Niveau : 🟢
34.1.8 — Trademark déposé (INPI/EUIPO/USPTO)
Niveau : 🟢
📋 SECTION 35 — COMPLIANCE NIS2
35.1.1 — Statut entité essentielle / importante évalué
Niveau : 🟠
Référence : Directive UE 2022/2555
35.1.2 — Capacité reporting incident 24h/72h
Niveau : 🟠
35.1.3 — Email auth obligatoire entités essentielles
Niveau : 🟠
35.1.4 — DNSSEC fortement recommandé
Niveau : 🟠
35.1.5 — Monitoring 24/7 disponible
Niveau : 🟠
35.1.6 — Plan de réponse aux incidents (PRI)
Niveau : 🟠
35.1.7 — Test PRI annuel documenté
Niveau : 🟢
35.1.8 — Sanction NIS2 jusqu’à 10 M€ ou 2 % CA
Niveau : 🔴
Description : Référence pour cadrage management buy-in.
🇫🇷 SECTION 36 — CONFORMITÉ ANSSI
36.1.1 — PASSI portée Audit DNS si OIV
Niveau : 🟠
Référence : ANSSI / SGDSN
36.1.2 — SecNumCloud pour hébergement DNS critique
Niveau : 🟢
36.1.3 — Guide ANSSI DNS 2024 appliqué
Niveau : 🟠
36.1.4 — Algorithmes ANSSI (DNSSEC 13/15, DKIM RSA-2048+/Ed25519)
Niveau : 🟠
36.1.5 — RGS v2.0 si service public
Niveau : 🟠
36.1.6 — Chiffrement homologué pour clés critiques
Niveau : 🟢
36.1.7 — Veille CERT-FR
Niveau : 🟢
🎯 SECTION 37 — KILL CHAINS MITRE ATT&CK
37.1.1 — Kill chain : Email spoofing → BEC / CEO Fraud
Niveau : 🔴
Référence : MITRE T1566.002 / T1534
Description : Test : envoi email forgé From=<ceo>@<domaine> depuis IP externe. Vérifier réception côté partenaire (acceptation = vulnérable).
Mitigation effective : DMARC p=reject + DKIM aligné strict + SPF -all.
37.1.2 — Kill chain : Subdomain takeover
Niveau : 🔴
Référence : MITRE T1584.001
Description : Énumérer CNAMEs externes, tester rachat target si dangling. Mitigation : suppression CNAME orphan.
37.1.3 — Kill chain : Domain expiration / Redemption hijack
Niveau : 🔴
Référence : MITRE T1583.001
Description : Veille whois 90j avant expiration + auto-renew + Registry Lock.
37.1.4 — Kill chain : STARTTLS downgrade
Niveau : 🟠
Référence : MITRE T1557
Description : Test downgrade STARTTLS via swaks + STRIP-STARTTLS proxy. Mitigation : MTA-STS enforce + DANE TLSA + TLS-RPT.
37.1.5 — Kill chain : Mis-issuance certificat / MITM HTTPS
Niveau : 🔴
Référence : MITRE T1583.004
Description : Compromission AC ou hijack HTTP-01. Mitigation : CAA + accounturi + validationmethods=dns-01 + CT-log monitoring + HSTS preload.
37.1.6 — Kill chain : Cache poisoning (Kaminsky-like)
Niveau : 🟠
Référence : MITRE T1565.001
Description : Mitigations : DNSSEC validation, source-port randomization, DNS COOKIE, 0x20 case randomization.
37.1.7 — Kill chain : DNS hijack via registrar compromise
Niveau : 🔴
Référence : MITRE T1583.001
Description : Cas Sea Turtle 2019, OctoPus 2024. Mitigation : 2FA FIDO2 + Registry Lock + 4-eyes principle.
37.1.8 — Kill chain : NTLM Relay via DNS info-leak (Exchange)
Niveau : 🟠
Référence : MITRE T1187 / CVE-2024-21410
Description : SRV _autodiscover._tcp exposant FQDN interne + NTLM relay. Mitigation : EPA active, pas de SRV publics inutiles.
37.1.9 — Kill chain : DDoS DNS amplification
Niveau : 🟠
Référence : MITRE T1498.002
Description : Mitigation : RRL, pas de récursion ouverte, BCP 38 chez ISP, Anycast.
37.1.10 — Kill chain : DKIM Replay (incident 2024-2026)
Niveau : 🟠
Référence : Mailgun outage 2024 / Cofense reports
Description : Réutilisation d’un email DKIM-signé légitime pour diffusion massive. Mitigation : x= expiration courte, oversigning, pas de l=.
🛠️ SECTION 38 — GOUVERNANCE OPÉRATIONNELLE
38.1.1 — DNS-as-Code (Terraform / OctoDNS / DNSControl)
Niveau : 🟢
Référence : ENISA / NIS2
38.1.2 — Repository Git versionné
Niveau : 🟢
38.1.3 — CI/CD valide la zone (named-checkzone)
Niveau : 🟢
38.1.4 — Tests automatisés post-déploiement
Niveau : 🟢
38.1.5 — Procédure rollback documentée
Niveau : 🟠
38.1.6 — 4-eyes principle pour modifs zone
Niveau : 🟠
38.1.7 — API keys registrar inventoriées + rotation 6 mois
Niveau : 🟠
38.1.8 — Audit trail conservé ≥ 1 an
Niveau : 🟢
38.1.9 — Comptes service distincts des comptes utilisateur
Niveau : 🟠
38.1.10 — Export quotidien zone (AXFR signé)
Niveau : 🟠
38.1.11 — Retention backup 90j minimum
Niveau : 🟠
38.1.12 — Test restauration trimestriel
Niveau : 🟢
38.1.13 — NS secondaire externe (HE.net / Cloudflare / NS1)
Niveau : 🟠
38.1.14 — RPO < 1h, RTO < 4h
Niveau : 🟢
38.1.15 — Disponibilité NS uptime > 99.99%
Niveau : 🟠
38.1.16 — Cohérence SOA serial entre NS (monitoring)
Niveau : 🟢
38.1.17 — Validation DNSSEC chaîne (dnsviz hebdo)
Niveau : 🟠
38.1.18 — Score internet.nl / hardenize automatisé
Niveau : 🟢
38.1.19 — CT-log monitoring (crt.sh API)
Niveau : 🟠
38.1.20 — DMARC RUA parsing + alerting (parsedmarc + Grafana)
Niveau : 🟠
38.1.21 — TLS-RPT parsing
Niveau : 🟢
38.1.22 — CMDB des domaines (apex + sous-domaines)
Niveau : 🟢
38.1.23 — Owner business documenté
Niveau : 🟢
38.1.24 — Owner technique documenté
Niveau : 🟢
38.1.25 — Inventaire clés DKIM / DNSSEC + dates rotation
Niveau : 🟢
38.1.26 — Inventaire certificats + monitoring expiration
Niveau : 🟠
38.1.27 — Émetteurs email tiers documentés + leur SPF include
Niveau : 🟢
📊 Synthèse de l’Audit
Tableau de scoring (sur 100)
| Catégorie | Pondération | Score obtenu | % |
|---|---|---|---|
| Hygiène DNS de base (S1-S6) | 15 | / 15 | |
| Email authentication (S7-S16) | 30 | / 30 | |
| Intégrité DNS / DANE (S17-S23) | 20 | / 20 | |
| SOTA 2026 (S24-S28) | 15 | / 15 | |
| Hardening transverse (S29-S34) | 10 | / 10 | |
| Compliance & Gouvernance (S35-S38) | 10 | / 10 | |
| TOTAL | 100 | / 100 |
Grille d’interprétation
| Score | Niveau | Interprétation | Recommandation |
|---|---|---|---|
| 0-30 | F | Posture critique | Plan d’urgence P0 |
| 31-50 | D | Insuffisant | Plan urgence < 30j |
| 51-70 | C | Niveau base atteint | Roadmap SOTA |
| 71-85 | B | Conforme 2024 | Marges progrès SOTA |
| 86-95 | A | Excellent | Veille continue |
| 96-100 | A+ | Référence mondiale | Communication / certification |
Verdict global
| Champ | Valeur |
|---|---|
| Score global | / 100 |
| Niveau | (F/D/C/B/A/A+) |
| Date de l’audit | YYYY-MM-DD |
| Prochain audit recommandé | YYYY-MM-DD (+90j) |
| Top 3 risques critiques | 1. … / 2. … / 3. … |
| Top 3 quick wins | 1. … / 2. … / 3. … |
Plan de remédiation 4 phases (28 jours)
| Phase | Durée | Objet | Livrables |
|---|---|---|---|
| Phase 0 — Urgence | J0 → J+3 | Domain locks EPP, 2FA registrar, suppression CNAMEs orphan | Confirmation locks, audit takeover |
| Phase 1 — Email auth | J+3 → J+10 | SPF strict, DKIM 2048, DMARC quarantine→reject, NULL MX, MTA-STS | Records publiés, tests internet.nl |
| Phase 2 — Transport / Intégrité | J+10 → J+20 | DNSSEC, DANE TLSA, CAA, TLS-RPT, BIMI | Chaîne DNSSEC verte (dnsviz) |
| Phase 3 — SOTA / Hardening | J+20 → J+28 | HTTPS RR + ECH, SSHFP, SMIMEA, RPKI ROA, headers HTTP, .well-known | Score internet.nl > 95 % |
🛠️ Commandes & Outils Recommandés
Commande d’audit unifiée
#!/bin/bash
# Audit DNS rapide ANC — usage : ./audit-dns-anc.sh <domaine>
DOM="${1:?Usage: $0 <domaine>}"
OUT="./audit-${DOM}-$(date +%Y%m%d)"
mkdir -p "$OUT"
# Niveau 1 — Hygiène
{
for T in SOA NS A AAAA MX TXT CAA HTTPS SVCB DNSKEY DS CDS CDNSKEY ZONEMD; do
dig @1.1.1.1 $DOM $T +noall +answer
done
whois $DOM | grep -iE "status|expir|registrar"
} > "$OUT/01-hygiene.txt"
# Niveau 2 — Email auth
{
echo "=== SPF ==="
dig @1.1.1.1 $DOM TXT +short | grep "v=spf1"
echo "=== DMARC ==="
dig @1.1.1.1 _dmarc.$DOM TXT +short
echo "=== DKIM (sélecteurs courants) ==="
for S in selector1 selector2 default mail dkim ovh google k1 mandrill sendgrid mxvault s1 s2 fm1 fm2 fm3 amazonses; do
R=$(dig @1.1.1.1 ${S}._domainkey.$DOM TXT +short)
[ -n "$R" ] && echo "FOUND $S: $R"
done
echo "=== MTA-STS / TLS-RPT / BIMI ==="
dig @1.1.1.1 _mta-sts.$DOM TXT +short
curl -sk --max-time 5 https://mta-sts.$DOM/.well-known/mta-sts.txt
dig @1.1.1.1 _smtp._tls.$DOM TXT +short
dig @1.1.1.1 default._bimi.$DOM TXT +short
} > "$OUT/02-email.txt"
# Niveau 3 — DNSSEC + DANE
{
dig @1.1.1.1 +dnssec $DOM SOA | grep -E "ad |RRSIG"
dig @1.1.1.1 $DOM DS DNSKEY +multiline
for HOST in mail.$DOM smtp.$DOM; do
for PORT in 25 465 587; do
dig @1.1.1.1 _${PORT}._tcp.${HOST} TLSA +short
done
done
} > "$OUT/03-dnssec-dane.txt"
# Niveau 4 — SOTA
{
dig @1.1.1.1 $DOM HTTPS +short
dig @1.1.1.1 $DOM SSHFP +short
} > "$OUT/04-sota.txt"
# Niveau 5 — Hardening
{
for NS in $(dig @1.1.1.1 $DOM NS +short); do
IP=$(dig @1.1.1.1 $NS A +short | head -1)
dig @$IP version.bind TXT CHAOS +short
done
IP=$(dig @1.1.1.1 $DOM A +short | head -1)
PTR=$(dig -x $IP +short)
echo "$IP -> $PTR"
curl -sI --max-time 5 https://$DOM/.well-known/security.txt | head -1
curl -skI --max-time 5 https://$DOM | grep -iE "strict-transport|content-security|x-frame|x-content-type|referrer-policy"
echo | timeout 6 openssl s_client -connect $DOM:443 -servername $DOM 2>&1 | grep -E "Protocol|Cipher" | head -3
} > "$OUT/05-hardening.txt"
echo "Audit terminé : $OUT/"
Liste des outils CLI
| Outil | Usage | Installation |
|---|---|---|
dig |
Lookups DNS, DNSSEC | apt install dnsutils |
kdig |
DNS over TLS / QUIC | apt install knot-dnsutils |
whois |
Registrar info | apt install whois |
swaks |
SMTP test | apt install swaks |
dnstwist |
Typosquatting | pip install dnstwist |
subzy |
Subdomain takeover | go install github.com/PentestPad/subzy@latest |
subfinder |
Énumération sous-domaines | go install github.com/projectdiscovery/subfinder/v2/cmd/subfinder@latest |
dnsrecon |
Énumération zone | pip install dnsrecon |
testssl.sh |
Audit TLS | git clone https://github.com/drwetter/testssl.sh |
parsedmarc |
Parser DMARC RUA | pip install parsedmarc |
dnscontrol |
DNS-as-Code | github.com/StackExchange/dnscontrol |
Outils en ligne
| Service | URL | Usage |
|---|---|---|
| MXToolbox | mxtoolbox.com | Lookup DMARC/SPF/DKIM/MTA-STS |
| internet.nl | internet.nl/test-mail/ | Score complet 2026 |
| Hardenize | hardenize.com | Score TLS + DNS + Email |
| DMARCian | dmarcian.com/dmarc-inspector | DMARC live |
| dnsviz | dnsviz.net | Vérification DNSSEC |
| crt.sh | crt.sh | Liste certificats CT-logs |
| BIMI Group | bimigroup.org/check-svg-logo-validity | Validateur SVG Tiny PS |
| HSTS Preload | hstspreload.org | Soumission HSTS |
| MTA-STS Validator | aykira.com/mta-sts-validator | Policy MTA-STS |
| DANE checker | dane.sys4.de | Validation TLSA |
| Mozilla Observatory | observatory.mozilla.org | Headers HTTP |
| Caatest | caatest.co.uk | Validation CAA |
| EDNS Compliance | ednscomp.isc.org | DNS Flag Day |
| RIPE Stat | stat.ripe.net | RPKI / BGP |
| Defo ECH check | defo.ie/ech-check.php | ECH (RFC 9180) |
| RDAP.org | rdap.org | RDAP queries |
📚 Références
RFC Email
- RFC 5321 — Simple Mail Transfer Protocol
- RFC 5322 — Internet Message Format
- RFC 7208 — SPF v1
- RFC 6376 — DKIM Signatures
- RFC 7489 — DMARC
- RFC 9091 — DMARC PSD / np tag
- RFC 8617 — ARC (Authenticated Received Chain)
- RFC 8460 — TLS-RPT
- RFC 8461 — MTA-STS
- RFC 7505 — NULL MX
- RFC 8689 — REQUIRETLS
- RFC 6541 — DKIM ATPS
- RFC 9261 — List-Unsubscribe-Post
- RFC 6530-6533 — SMTPUTF8 / EAI
- RFC 8463 — Ed25519 dans DKIM
- RFC 8301 — Cryptographic Algorithm and Key Usage Update to DKIM
- BIMI Group v1.0 — bimigroup.org
RFC DNS Security
- RFC 1034 / 1035 — DNS Concepts and Implementation
- RFC 1912 — Common DNS Operational and Configuration Errors
- RFC 4033 / 4034 / 4035 — DNSSEC
- RFC 8624 — DNSSEC Algorithm Implementation Requirements
- RFC 5155 — DNSSEC NSEC3
- RFC 9276 — NSEC3 Best Practices
- RFC 7344 — CDS / CDNSKEY
- RFC 8078 — CDS for Removal of DS
- RFC 6698 / 7671 / 7672 — DANE / TLSA / SMTP DANE
- RFC 8901 — Multi-Signer DNSSEC
- RFC 7477 — CSYNC
- RFC 7873 — DNS COOKIE
- RFC 8198 — Aggressive NSEC Caching
- RFC 8914 — Extended DNS Errors (EDE)
- RFC 8976 — ZONEMD
- RFC 9250 — DNS over QUIC
- RFC 9230 — DNS over TLS / HTTPS Authoritative
- RFC 5731 — EPP for Domain Name Mapping
- RFC 5358 — Preventing Use of Recursive Nameservers in Reflector Attacks
- RFC 5452 — Source-port randomization
- RFC 6891 — EDNS0
- RFC 4892 — Requirements for a Mechanism Identifying a Name Server Instance
RFC TLS / Web
- RFC 8446 — TLS 1.3
- RFC 8470 — TLS 1.3 0-RTT
- RFC 6797 — HSTS
- RFC 8659 — CAA
- RFC 8657 — CAA accounturi / validationmethods
- RFC 9460 — SVCB / HTTPS RR
- RFC 9180 — HPKE / ECH base
- RFC 9116 — security.txt
- RFC 8615 — .well-known
- CA/B Forum Baseline Requirements
RFC SSH / S/MIME / PGP
- RFC 4255 — SSHFP
- RFC 8162 — SMIMEA
- RFC 7929 — OPENPGPKEY
- RFC 8032 — Ed25519
RFC Réseau / BGP / Reverse DNS
- RFC 6480 — RPKI
- RFC 6482 — ROA Format
- RFC 9082-9083 — RDAP
- RFC 9774 — ASPA
- RFC 8482 — HINFO/ANY
- BCP 38 / RFC 2827 — Egress filtering
- BCP 16 / RFC 2182 — Selection of NS
Standards Post-Quantum
- NIST FIPS 203 — ML-KEM (août 2024)
- NIST FIPS 204 — ML-DSA (août 2024)
- NIST FIPS 205 — SLH-DSA / SPHINCS+ (août 2024)
- draft-ietf-tls-hybrid-design — TLS 1.3 hybrid KEM
Compliance
- Directive UE 2022/2555 — NIS2
- Règlement UE 2023/203 — DGAC / AESA Part-IS
- ANSSI Guide DNS 2024
- ANSSI RGS v2.0
- NIST SP 800-81-2 — Secure DNS
- NIST SP 800-177 — Trustworthy Email
- M3AAWG Email Authentication Best Practices
- ENISA Good Practices Domain Name Registry Resilience
- PCI DSS 4.0 §A2
- HIPAA Privacy Rule
- ISO 27001:2022 §A.5.10 / §A.8.20
Incidents et anecdotes 2016-2026
- 2016 — Dyn DDoS : Twitter, Spotify, GitHub indisponibles ; mono-fournisseur DNS = SPOF
- 2018 — AWS Route53 BGP hijack : MyEtherWallet, ~150 000 USD volés via cryptohijack
- 2019 — Sea Turtle : registrar compromise, hijack de TLDs nationaux
- 2020 — Twitter Hack : compromission interne admin tools, leçon 4-eyes
- 2020 — DNS Flag Day : retrait support EDNS non-compliant
- 2021 — Microsoft Bing subdomain takeover : CNAME orphelin
- 2022 — KlaySwap BGP hijack : ROA absent, ~1.9 M USD volés
- 2023 — GoDaddy registrar breach : compromission 6 mois non détectée
- 2024 — Mailgun DKIM Replay : abus de signatures légitimes
- 2024 — Gmail/Yahoo Bulk Sender : exigence DMARC / List-Unsubscribe-Post
- 2025 — ICANN RDAP obligatoire : fin du WHOIS legacy
📋 Annexe — Checklist condensée par phase
Phase 0 — Urgence (J0 → J+3) — P0
- EPP
clientTransferProhibitedactivé - EPP
clientUpdateProhibitedactivé - EPP
clientDeleteProhibitedactivé - 2FA registrar (FIDO2 ou TOTP)
- Vérification statuts d’urgence WHOIS (no Hold/Redemption)
- Inventaire CNAMEs externes + scan subzy
- AXFR refusé sur tous NS
Phase 1 — Email Authentication (J+3 → J+10) — P1
- SPF unique, ≤ 10 lookups,
-all - DKIM 2048+ ou Ed25519 par émetteur
- DMARC
p=quarantinepuisreject,sp=,np=,rua= - NULL MX
0 .sur domaines parking - MTA-STS
mode: enforce - TLS-RPT actif
- List-Unsubscribe-Post (Gmail/Yahoo 2024)
- PTR + FCrDNS validés
Phase 2 — Intégrité DNS / DANE (J+10 → J+20) — P2
- DNSSEC algorithme 13 ou 15
- Chaîne valide (dnsviz tout vert)
- CDS/CDNSKEY publiés
- DANE TLSA SMTP
- CAA enrichi (
accounturi,validationmethods,iodef) - DNS COOKIE supporté
- ZONEMD (optionnel)
- CSYNC si registrar supporte
Phase 3 — SOTA & Hardening (J+20 → J+28) — P3
- HTTPS RR avec
alpn=h2,h3+ ECH - SSHFP par hôte SSH
- SMIMEA / OPENPGPKEY
- DoT / DoH / DoQ sur NS
- RPKI ROA + maxLength
- Headers HTTP (HSTS preload, CSP, etc.)
- /.well-known/security.txt
- BIMI (post-DMARC reject)
Suivi continu (J+30, J+90)
- Re-audit Phase 1 à J+30
- Re-audit Phase 2 à J+30
- Re-audit Phase 3 à J+90
- Score internet.nl / hardenize comparé baseline
- Audit annuel complet
🔄 Changelog & Roadmap
Version 1.0 — 2026-05-10
- Release initiale, 38 sections, ~360 contrôles
- Couverture standards 2008 → 2026
- 10 kill chains MITRE ATT&CK documentées
- 4 phases de remédiation (28 jours)
- Compatible NIS2 / RGPD / ANSSI / ISO 27001:2022
Roadmap 2026-Q4
- Section dédiée DKIM2 (draft IETF)
- Templates Terraform / DNSControl pour ANC
- Intégration ECH dans tests automatisés
- Annexe Multi-Signer DNSSEC step-by-step
- Traduction EN
Checklist maintenue par AYI NEDJIMI CONSULTANTS (ANC) — Security Team
Contact : [email protected]
Classification : CONFIDENTIEL — Distribution limitée
Checklist d'audit DNS la plus complète : 391 contrôles couvrant 38 sections — hygiène DNS de base (SOA, NS, glue), email authentication (SPF/DKIM/DMARC/ARC/MTA-STS/BIMI), intégrité DNS (DNSSEC/DANE/CAA/ZONEMD), SOTA 2026 (HTTPS RR, DoT/DoH/DoQ, RPKI, post-quantum), hardening transverse, kill chains MITRE ATT&CK, compliance NIS2 et ANSSI.
Cette checklist s'adresse aux RSSI, administrateurs systèmes, auditeurs de sécurité et consultants souhaitant évaluer ou durcir un environnement DNS Audit. Chaque contrôle inclut les commandes de vérification et les seuils critiques.
Checklists associées
Besoin d'un audit basé sur cette checklist ?
Nos experts réalisent l'audit complet de votre environnement DNS Audit et livrent un rapport détaillé avec plan de remédiation.