DANE pour les e‑mails : quand ça vaut le coup (et pourquoi souvent non)

Ce que DANE apporte réellement aux e‑mails (et ce qu’il n’apporte pas)

DANE (DNS-based Authentication of Named Entities) pour SMTP a un seul objectif : rendre le TLS pour la messagerie
moins « opportuniste » et plus « vous devez utiliser cette identité cryptographique pour me livrer le courrier ».
Il le fait en publiant des enregistrements TLSA dans le DNS, protégés par DNSSEC.

Dans la livraison SMTP, le MTA émetteur regarde typiquement les enregistrements MX, se connecte, puis essaie STARTTLS.
Sans DANE (et sans autres politiques), un attaquant réseau peut tenter une rétrogradation—supprimer STARTTLS,
forcer le texte clair, ou rediriger vers une autre chaîne de certificats en espérant que l’émetteur continue sans broncher.
DANE transforme le « continuez sans y prêter attention » en « validez ou échouez », du moins pour les pairs qui l’implémentent.

La distinction clé : DANE valide via DNSSEC, pas via les AC publiques

Le TLS traditionnel repose sur le WebPKI public : autorités de certification, règles d’émission, intermédiaires,
et un énorme magasin de confiance. DANE permet à un domaine de dire : « Pour _25._tcp.mx.example, voici le certificat
(ou la clé publique) que vous devez attendre. » La racine de confiance est la chaîne de confiance DNSSEC jusqu’à la racine DNS.

C’est à la fois puissance de sécurité et responsabilité opérationnelle dans un seul paquet. Vous échangez « risque de l’écosystème CA »
contre « risque d’exactitude DNSSEC ». En termes de production : vous déplacez un mode de défaillance depuis une CA tierce
vers votre propre chaîne DNS. Cela peut être un bon compromis. Cela peut aussi être un programme de développement de carrière.

Ce que DANE ne fait pas

• Il n’authentifie pas l’expéditeur. C’est le domaine de SPF/DKIM/DMARC.
• Il ne chiffre pas de bout en bout. Le TLS SMTP protège le transport hop‑à‑hop, pas le contenu de la boîte contre l’infrastructure du destinataire.
• Il n’arrête pas le spam. Le spam est un problème humain déguisé en problème de protocole.
• Il ne corrige pas un cycle de vie de certificats défaillant. Il vous donne juste une nouvelle façon de le casser.

La vérité sèchement humoristique : DANE est une ceinture de sécurité qui exige aussi de reconstruire le système électrique de la voiture.
Parfois ça vaut le coup. Mais n’installez pas DANE parce que vous avez lu un billet alarmiste et que vous avez eu un coup de cœur.

Quand DANE en vaut le peine

DANE vaut le coup quand vous avez des flux de mails à haute valeur, des contreparties prévisibles,
et la maturité opérationnelle pour gérer DNSSEC sans le traiter comme une case à cocher ponctuelle.
Il vaut aussi le coup si vous pouvez tolérer un comportement « échouer fermé » pour certains trafics.

Bonnes situations

• Secteurs gouvernementaux, défense, régulés où les attaques par rétrogradation ne sont pas théoriques.
  Si vous vous défendez contre des attaquants réseau actifs, STARTTLS opportuniste n’est pas suffisant.
• B2B avec un ensemble de partenaires défini. Vous pouvez exiger DANE des partenaires, le tester et coordonner les changements.
  Pensez « banques envoyant des instructions de virement », pas « newsletter à des millions d’adresses ».
• Domaines qui exécutent déjà correctement DNSSEC (gestion des clés, processus de rollover, surveillance).
  Si DNSSEC est déjà ennuyeusement fiable chez vous, DANE devient moins effrayant.
• Cas où vous voulez éviter les AC publiques pour le SMTP. DANE peut publier un certificat auto‑signé ou épingler une clé.
  Utile si votre politique est « nous ne dépendrons pas de CA tierces pour le transport des e‑mails ».
• Organisations avec couverture SRE pour la messagerie et le DNS. Si la messagerie est « le travail à côté de quelqu’un », DANE n’est pas votre première amélioration.

Règle de décision que j’aime vraiment

Si une panne de messagerie pour votre domaine est un Sev‑1 et que les changements DNS sont déjà traités comme des déploiements de production avec rollback,
DANE peut être une étape rationnelle. Si les pannes de messagerie sont du « bruit de ticket » et que le DNS est mis à jour par copier‑coller dans l’interface du registraire,
DANE est un piège de fiabilité.

Pourquoi souvent non : le coût en fiabilité

L’adoption de DANE pour l’e‑mail est limitée non parce que c’est une mauvaise ingénierie, mais parce que c’est difficile à exploiter
et que les incitations ne s’alignent pas. La messagerie est fédérée, désordonnée, et pleine de vieux MTA qui pensent encore que SHA‑1 est « correct ».

DNSSEC n’est pas difficile. DNSSEC est impitoyable.

DNSSEC transforme une erreur DNS de « certains résolveurs ont mis en cache la mauvaise valeur » en « la validation échoue et votre domaine disparaît effectivement ».
Avec DANE, cette défaillance peut tuer sélectivement le courrier entrant depuis des émetteurs qui valident. Le pire type de panne est celle où
certains émetteurs peuvent vous atteindre et d’autres non, car vous avez le plaisir d’essuyer les deux incidents et le déni.

Réalités opérationnelles rendant DANE peu attrayant

• Soutien partiel de l’écosystème : beaucoup de récepteurs majeurs n’appliquent pas DANE pour la livraison SMTP comme les partisans le souhaiteraient.
  Cela réduit le retour sur investissement.
• Rollovers de clés + mises à jour TLSA : vous gérez à la fois les clés DNSSEC et les pins TLS.
  Les deux ont des modes d’échec « oups, maintenant rien ne valide ».
• Lacunes des outils : votre plateforme moyenne de gestion DNS d’entreprise est conçue pour des enregistrements A et des vanités marketing.
  DNSSEC y est traité comme un animal exotique.
• Charge d’astreinte : vous devez pouvoir répondre rapidement à « est‑ce que DNSSEC est cassé ? ».
  Si la seule personne qui le comprend est en vacances, vous créez un point unique de défaillance humain.

Une blague courte, comme promis : DNSSEC est comme un parachute—techniquement simple, mais vous voulez vraiment qu’il soit plié par quelqu’un qui s’en soucie.

Faits et contexte historique (version courte et concrète)

• Les racines DNSSEC ont été signées en 2010, rendant la validation globale possible sans « îlots de confiance ». C’était le préalable rendant DANE pratique.
• DANE est spécifié dans la RFC 6698 (2012), définissant les enregistrements TLSA et la manière d’apparier certificats ou clés via DNS protégé par DNSSEC.
• L’usage SMTP de DANE est défini dans la RFC 7672 (2015), clarifiant comment les MTA doivent utiliser TLSA pour SMTP over STARTTLS.
• STARTTLS pour SMTP existe depuis 2002 (RFC 3207), mais il a été conçu pour un chiffrement opportuniste et est vulnérable à la rétrogradation sans politique supplémentaire.
• L’attention publique sur le striping de STARTTLS a augmenté après les révélations de surveillance de masse (2013), poussant l’écosystème à envisager des garanties plus fortes.
• MTA-STS (RFC 8461, 2018) et TLS‑RPT (RFC 8460, 2018) ont émergé comme des alternatives « politique WebPKI + rapport » , échangeant la dépendance DNSSEC contre HTTPS et dépendance aux AC.
• DANE peut publier des pins auto‑signés en toute sécurité (car DNSSEC fournit la confiance), ce qui est inhabituel dans l’univers TLS et attractif en environnements verrouillés.
• La messagerie met du temps à évoluer car le protocole est fédéré et rétrocompatible par nécessité ; vous ne pouvez pas « forcer la mise à jour » des MTA d’internet.

Comment DANE échoue dans la vraie vie

Mode d’échec 1 : DNSSEC casse et vous ne le remarquez pas

La panne DANE la plus courante n’est pas « TLSA incorrect ». C’est « la validation DNSSEC échoue », ce qui rend le TLSA invisible aux validateurs.
Selon le MTA émetteur et sa politique, cela peut signifier un repli vers TLS opportuniste ou un échec dur.
La variante dangereuse est la rétrogradation silencieuse : vous pensez être protégé, mais les émetteurs validants ne voient pas votre TLSA, donc ils livrent opportunistement.

Mode d’échec 2 : TLSA pointe vers le certificat/clé d’hier

Vous avez renouvelé votre certificat SMTP. Super. Si vous épinglez le certificat (ou le SPKI) via TLSA et ne mettez pas à jour l’enregistrement avec la bonne synchronisation et TTL,
les émetteurs validant DANE échoueront à livrer. Cela se manifeste plutôt comme « certains partenaires ne peuvent pas nous envoyer de mails » plutôt qu’une panne totale,
car seule une partie valide.

Mode d’échec 3 : mauvaises hypothèses sur le comportement MX

DANE pour SMTP dépend des enregistrements TLSA spécifiques aux hôtes MX. Beaucoup d’équipes supposent pouvoir publier un TLSA à l’apex
et en rester là. Puis elles changent de MX, ou ajoutent un nouvel hôte MX, et oublient le TLSA pour la nouvelle cible.
Le courrier continue à fonctionner depuis les émetteurs non validants, ce qui retarde la détection jusqu’au pire moment.

Mode d’échec 4 : « On l’a activé » mais on n’applique rien

Si votre MTA sortant n’est pas configuré pour utiliser DANE (ou si vous n’avez pas activé la validation DNSSEC),
votre organisation n’« utilise » pas DANE. Vous « publiez des TLSA et vous vous sentez bien ».
Ce sont des activités différentes.

Une citation, volontairement courte et opérationnelle :
L’espoir n’est pas une stratégie. — James Cameron

Tâches pratiques : commandes, sorties et décisions (12+)

L’objectif de cette section n’est pas de briller avec des commandes. C’est de vous permettre de répondre : « DANE fonctionne‑t‑il ? » et « Si non, que faisons‑nous ensuite ? »
Tous les exemples supposent des outils Linux. Remplacez les domaines et hôtes par les vôtres.

Tâche 1 — Confirmer que votre résolveur valide DNSSEC

cr0x@server:~$ resolvectl status | sed -n '1,80p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=yes/allow-downgrade
resolv.conf mode: stub
Current DNS Server: 10.0.0.53
       DNS Servers: 10.0.0.53 10.0.0.54

Sens : DNSSEC est activé avec allow-downgrade, ce qui n’est pas équivalent à une validation stricte.
Décision : Pour le dépannage DANE, utilisez un chemin strictement validant (Unbound en mode validation, ou des tests explicites +dnssec) pour éviter une fausse confiance.

Tâche 2 — Vérifier la validité de la chaîne DNSSEC pour le domaine

cr0x@server:~$ dig +dnssec +multi example.com SOA
; <<>> DiG 9.18.24 <<>> +dnssec +multi example.com SOA
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16173
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
example.com.        3600 IN SOA ns1.example.net. hostmaster.example.com. (
                                2026010301 7200 3600 1209600 3600 )
example.com.        3600 IN RRSIG SOA 13 2 3600 (
                                20260110000000 20260103000000 12345 example.com.
                                ...signature... )

Sens : Vous avez un RRSIG, nécessaire mais pas suffisant ; cela indique que la zone est signée.
Décision : Continuez en validant avec un outil qui vérifie vraiment la chaîne (tâche suivante). « Signé » n’est pas synonyme de « valide ».

Tâche 3 — Valider DNSSEC avec delv (chaîne de confiance)

cr0x@server:~$ delv example.com SOA
; fully validated
example.com.        3600 IN SOA ns1.example.net. hostmaster.example.com. 2026010301 7200 3600 1209600 3600

Sens : « fully validated » est ce que vous voulez. Si vous voyez « resolution failed » ou « broken trust chain », DANE est mort‑né.
Décision : Si ce n’est pas complètement validé, corrigez DNSSEC d’abord. Ne touchez pas aux TLSA tant que la fondation ne tient pas.

Tâche 4 — Lister les cibles MX que vous devez couvrir avec TLSA

cr0x@server:~$ dig +short MX example.com
10 mx1.example.com.
20 mx2.example.com.

Sens : TLSA DANE pour SMTP est lié aux noms d’hôtes MX, pas à l’apex du domaine.
Décision : Assurez‑vous que chaque hôte MX acceptant du courrier a les enregistrements TLSA corrects pour le port 25 et est signé par DNSSEC.

Tâche 5 — Interroger l’enregistrement TLSA pour SMTP (port 25) d’un MX spécifique

cr0x@server:~$ dig +dnssec +short _25._tcp.mx1.example.com TLSA
3 1 1 7A9C2B4C0F4E0A18D8C4C3D66D3D1A64E2D3B9D3A2B2D9E0A3F7C1E8A7B5C6D
3 1 1 7A9C2B4C0F4E0A18D8C4C3D66D3D1A64E2D3B9D3A2B2D9E0A3F7C1E8A7B5C6D

Sens : Vous avez probablement des enregistrements en double (même donnée répétée), ce qui est négligent mais généralement inoffensif.
Les champs sont : usage=3 (DANE‑EE), selector=1 (SPKI), matching=1 (SHA‑256).
Décision : Supprimez les doublons pour réduire la confusion. Confirmez aussi que ce hash correspond à la clé publique présentée par le serveur (tâche suivante).

Tâche 6 — Confirmer que le TLSA est réellement protégé par DNSSEC

cr0x@server:~$ dig +dnssec _25._tcp.mx1.example.com TLSA | sed -n '1,30p'
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57421
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
_25._tcp.mx1.example.com. 300 IN TLSA 3 1 1 7A9C2B4C0F4E0A18D8C4C3D66D3D1A64E2D3B9D3A2B2D9E0A3F7C1E8A7B5C6D
_25._tcp.mx1.example.com. 300 IN RRSIG TLSA 13 4 300 (
                                20260110000000 20260103000000 45678 example.com.
                                ...signature... )

Sens : Le RRset TLSA est signé (RRSIG présent). Bien.
Décision : Si RRSIG manque, l’enregistrement n’est pas protégé ; corrigez la signature de zone ou la délégation.

Tâche 7 — Tester STARTTLS SMTP et observer le certificat présenté

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.example.com:25 -servername mx1.example.com -showcerts 

CONNECTED(00000003)
depth=0 CN = mx1.example.com
verify error:num=18:self signed certificate
verify return:1
---
250 SMTPUTF8
---
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
---
-----BEGIN CERTIFICATE-----
...pem...
-----END CERTIFICATE-----

Sens : Il présente un certificat auto‑signé. C’est acceptable avec DANE‑EE (usage 3) si le TLSA correspond.
Décision : Si vous comptez sur le WebPKI, n’utilisez pas de certificat auto‑signé. Si vous comptez sur DANE, assurez‑vous que le TLSA épingle correctement le SPKI/le certificat.

Tâche 8 — Extraire le hash SPKI et le comparer au TLSA (selector 1, matching 1)

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.example.com:25 -servername mx1.example.com 

CONNECTED(00000003)
...snip...
-----BEGIN CERTIFICATE-----
...pem...
-----END CERTIFICATE-----

cr0x@server:~$ openssl x509 -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256
SHA2-256(stdin)= 7a9c2b4c0f4e0a18d8c4c3d66d3d1a64e2d3b9d3a2b2d9e0a3f7c1e8a7b5c6d

Sens : Le hash correspond aux données TLSA (insensible à la casse). L’épinglage DANE est cohérent avec ce que le serveur présente.
Décision : Si ce n’est pas le cas, vous avez soit fait une rotation de clés/certificats sans mettre à jour le TLSA, soit publié le mauvais TLSA. Corrigez avant d’imposer l’application.

Tâche 9 — Valider DANE de bout en bout en utilisant le comportement de sonde intégré de postfix (basé sur les logs)

cr0x@server:~$ postconf -n | egrep 'smtp_dns_support_level|smtp_tls_security_level|smtp_tls_loglevel'
smtp_dns_support_level = dnssec
smtp_tls_security_level = dane
smtp_tls_loglevel = 1

Sens : Postfix sortant est configuré pour utiliser DNSSEC et DANE pour la livraison. C’est la configuration « on le pense vraiment ».
Décision : Si vous expérimentez, commencez par des maps de politique par domaine plutôt que par dane global.

Tâche 10 — Surveiller les logs pour les résultats de validation DANE pendant la livraison

cr0x@server:~$ journalctl -u postfix -n 50 --no-pager
Jan 03 10:12:41 mailgw postfix/smtp[22190]: Verified TLS connection established to mx1.example.com[203.0.113.10]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
Jan 03 10:12:41 mailgw postfix/smtp[22190]: TLSA validation succeeded for _25._tcp.mx1.example.com

Sens : Postfix indique explicitement que la validation TLSA a réussi. C’est votre feu vert.
Décision : Si vous voyez « TLSA lookup failed » ou « verification failed », ne devinez pas—passez aux vérifications DNSSEC et TLSA.

Tâche 11 — Vérifier si vos serveurs DNS publient correctement le DS (sanité de délégation)

cr0x@server:~$ dig +short DS example.com @1.1.1.1
12345 13 2 9A6B0D0F2A7C0D7A1B6E6E2F7C5F2A8D2B1A9C0D0E1F2A3B4C5D6E7F8A9B0C

Sens : La zone parente a un DS pour votre domaine. Sans cela, les validateurs ne feront pas confiance à vos signatures.
Décision : Si DS manque (sortie vide), corrigez le registraire/la délégation parente avant toute autre chose.

Tâche 12 — Confirmer que le DNSKEY de la zone correspond au DS (détecter un décalage)

cr0x@server:~$ delv +vtrace example.com DNSKEY | sed -n '1,40p'
; fetch: example.com/DNSKEY
; validating example.com/DNSKEY: got answer
; verify: success
example.com. 3600 IN DNSKEY 257 3 13 (
    ...keydata...
)

Sens : Succès de validation indique que DS et DNSKEY sont alignés.
Décision : Si delv +vtrace montre un échec à l’étape DS/DNSKEY, vous avez un problème de délégation—souvent un rollover mal fait.

Tâche 13 — Vérifier les TLSA obsolètes dues au TTL/mise en cache lors d’une rotation de certificat

cr0x@server:~$ dig _25._tcp.mx1.example.com TLSA +noall +answer +ttlid
_25._tcp.mx1.example.com. 300 IN TLSA 3 1 1 7A9C2B4C0F4E0A18D8C4C3D66D3D1A64E2D3B9D3A2B2D9E0A3F7C1E8A7B5C6D

Sens : Le TTL est de 300 secondes (5 minutes). C’est compatible avec les rotations si votre infrastructure DNS le respecte.
Décision : Si le TTL est de plusieurs heures/jours, planifiez les rotations soigneusement ou utilisez la double publication TLSA pendant la transition.

Tâche 14 — Confirmer que le MX entrant présente le bon nom/certificat sous SNI et a un EHLO cohérent

cr0x@server:~$ swaks --to test@example.com --server mx1.example.com --tls --tls-optional
=== Trying mx1.example.com:25...
=== Connected to mx1.example.com.
<--  220 mx1.example.com ESMTP
 --> EHLO test
<--  250-mx1.example.com
<--  250-STARTTLS
=== TLS started with cipher TLS_AES_256_GCM_SHA384

Sens : STARTTLS est proposé et la négociation se passe proprement. C’est l’hygiène de base avant même de discuter DANE.
Décision : Si STARTTLS n’est pas proposé, corrigez la configuration du MTA d’abord. DANE ne sauve pas un SMTP sans texte chiffré.

Playbook de diagnostic rapide

Quand quelqu’un dit « les mails vers nous rebondissent » et que DANE est impliqué, vous ne commencez pas par débattre des RFC.
Vous trouvez le goulot rapidement. Voici l’ordre qui fait gagner du temps.

Première étape : est‑ce que DNSSEC est valide maintenant ?

• Exécutez delv example.com SOA depuis au moins deux réseaux (corporel et externe).
• Si ce n’est pas « fully validated », arrêtez‑vous. Corrigez DNSSEC.
• Vérifiez la présence du DS chez le parent et comparez avec la validation DNSKEY.

Deuxième étape : TLSA est‑il présent et signé pour chaque MX actif ?

• Énumérez les cibles MX.
• Pour chaque MX, interrogez _25._tcp.mxN TLSA et confirmez qu’un RRSIG existe.
• Confirmez que le TTL est raisonnable pour votre cadence de rotation.

Troisième étape : le serveur présente‑t‑il ce que TLSA épingle ?

• Utilisez openssl s_client -starttls smtp pour capturer le certificat.
• Calculez le hash SPKI et comparez au TLSA.
• Confirmez que vous ne présentez pas par erreur un certificat différent sur certains nœuds (les load balancers adorent surprendre).

Quatrième étape : l’émetteur applique‑t‑il vraiment DANE ?

• Demandez l’extrait de bounce/log ; cherchez « TLSA validation failed » vs un « TLS error » générique.
• Si vous contrôlez l’émetteur, vérifiez la config MTA (smtp_tls_security_level, support DNSSEC, etc.).
• Si vous ne le contrôlez pas, reproduisez depuis un hôte connu validant DANE pour éviter de chasser des fantômes.

Cinquième étape : décider d’échouer ouvert ou fermé

Si vous êtes en mode incident, vous pouvez temporairement assouplir l’application DANE sortante pour un domaine spécifique
(map de politique) pendant que vous corrigez le problème DNSSEC/TLSA. Ne faites pas de changements globaux en panique.
Les changements paniques sont la façon d’obtenir deux incidents pour le prix d’un.

Erreurs courantes (symptômes → cause → correction)

1) Symbole : « Certains émetteurs ne peuvent pas nous atteindre, mais d’autres oui »

Cause : Seuls certains émetteurs valident DNSSEC/DANE. Votre chaîne DNSSEC est cassée ou TLSA est en désaccord, donc les émetteurs validants échouent tandis que les non‑validants livrent.

Correction : Validez avec delv en externe ; corrigez le décalage DS/DNSKEY ou les signatures expirées ; vérifiez le TLSA par rapport au certificat présenté.

2) Symbole : Les livraisons échouent juste après une rotation de certificat

Cause : TLSA épingle l’ancien certificat ou l’ancien SPKI. Ou vous avez fait la rotation du certificat sur un seul nœud MX mais pas sur les autres.

Correction : Double‑publiez TLSA pendant les rotations (ancien + nouveau SPKI), réduisez le TTL à l’avance, et assurez la cohérence de la flotte avant la bascule.

3) Symbole : DANE « marche en labo » mais échoue depuis l’internet

Cause : Les résolveurs internes valident ; la récursion externe voit une délégation cassée, DS manquant, ou des réponses différentes à cause d’un DNS split‑horizon.

Correction : Testez depuis des résolveurs publics et depuis un résolveur récursif validant hors de votre réseau ; éliminez le split‑horizon pour les enregistrements TLSA/DNSSEC.

4) Symbole : TLSA existe mais Postfix logge « TLSA lookup failed »

Cause : Votre chemin résolveur ne fait pas de validation DNSSEC (ou permet la rétrogradation), ou Postfix n’est pas configuré pour DNSSEC.

Correction : Définissez smtp_dns_support_level=dnssec et assurez‑vous que Postfix peut atteindre un résolveur validant ; confirmez le bit AD dans les réponses si applicable.

5) Symbole : Après changement de fournisseur DNS, la délivrabilité du mail se dégrade

Cause : Le re‑signing DNSSEC / la mise à jour DS a été mal gérée. La zone est signée, mais pas digne de confiance.

Correction : Traitez les migrations DNS comme des cérémonies de clé : coordonnez les mises à jour DS, vérifiez la propagation, et validez avec delv +vtrace.

6) Symbole : DANE échoue seulement pour un nom d’hôte MX

Cause : TLSA manquant pour le MX secondaire/nouveau, ou l’hôte MX est dans une zone enfant non signée.

Correction : Publiez TLSA sous chaque FQDN MX et assurez‑vous que la zone de l’hôte MX est signée par DNSSEC avec une chaîne valide jusqu’à la racine.

Trois micro‑histoires d’entreprise issues du terrain

Micro‑histoire 1 : L’incident causé par une mauvaise hypothèse

Une société SaaS de taille moyenne a décidé « d’activer DANE » après qu’un audit de sécurité ait déclaré que STARTTLS opportuniste était insuffisant.
L’équipe mail était compétente, mais petite. Le DNS était « possédé » par un groupe différent qui gérait surtout des enregistrements marketing et des bascules CDN.

L’hypothèse erronée était subtile : ils ont supposé que publier un TLSA sur _25._tcp.example.com couvrirait le courrier du domaine.
Ils n’ont pas intégré que la livraison SMTP utilise des cibles MX, et que la validation DANE est typiquement effectuée contre
_25._tcp.<mx-hostname>.

Ils ont changé de MX vers un nouveau nom d’hôte lors d’une transition de fournisseur. Le volume entrant avait l’air normal.
Puis un grand client avec une validation DANE stricte a commencé à rebondir. Le premier signal était « votre serveur mail est en panne »,
techniquement faux et opérationnellement peu utile.

Le vrai problème : le nouveau nom d’hôte MX n’avait aucun TLSA. Les émetteurs non validants livraient correctement.
Les émetteurs validants refusaient. L’incident a duré des heures parce que tout le monde essayait de le reproduire depuis leurs propres laptops,
et leurs résolveurs récursifs n’étaient pas validateurs. Ils déboguaient une politique de sécurité qui n’était pas présente dans leur chemin de test.

La correction fut simple : publier des TLSA signés pour chaque nom d’hôte MX, puis ajouter une procédure :
« Tout changement de MX nécessite revue TLSA et vérifications externes DNSSEC. » L’apprentissage fut plus coûteux :
si vous ne pouvez pas décrire précisément quel nom est validé, vous n’avez pas le droit de déployer la fonctionnalité.

Micro‑histoire 2 : L’optimisation qui s’est retournée contre eux

Une société financière disposait d’un solide dispositif DNSSEC et souhaitait que DANE épingle les clés SMTP sans impliquer les AC publiques.
Ils ont optimisé pour les rotations : TTL faibles sur TLSA (60 secondes), paramètres de cache agressifs dans leurs résolveurs récursifs,
et une chaîne qui mettait à jour TLSA immédiatement après déploiement des nouveaux certificats.

Sur le papier, c’est élégant. En pratique, ils ont créé une dépendance fragile sur le temps de propagation DNS across plusieurs serveurs autoritaires,
plus un ensemble étonnamment compliqué de caches : résolveurs locaux, forwarders en amont, et résolveurs partenaires qui ne respectaient pas systématiquement les TTL faibles.

Pendant une rotation de clé de routine, un serveur autoritaire a eu du retard sur la mise à jour. La moitié d’internet voyait le nouveau TLSA, l’autre moitié voyait l’ancien.
Leur load balancer déployait aussi les nœuds graduellement, si bien que différents nœuds MX présentaient des clés différentes pendant la fenêtre.
Cela produisit le type de défaillance qui fait douter les ingénieurs de la réalité : la validation réussissait ou échouait selon le résolveur et l’IP MX atteinte.

Ils l’ont « corrigé » en augmentant les TTL TLSA et en passant à la double publication des hashes SPKI pour une fenêtre de recouvrement plus longue,
et en exigeant que le déploiement des certificats/cles SMTP soit atomique sur la flotte acceptant (ou au moins par nom d’hôte MX).
La leçon : optimiser pour la vitesse dans les systèmes distribués augmente souvent juste le nombre de façons d’avoir tort en même temps.

Micro‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une grande entreprise gérait plusieurs passerelles mail par région. Ils avaient DNSSEC et DANE, mais sans illusion :
ils traitaient le DNS comme de la production et exécutèrent une gestion des changements qui était, franchement, ennuyeuse. L’ennui, c’est bien.

Chaque trimestre, ils faisaient un « exercice feu DANE et DNSSEC ». Pas un exercice sur table avec de jolis slides—un vrai exercice.
Quelqu’un validait intentionnellement DNSSEC depuis un réseau externe, vérifiait l’alignement DS, recomptait un hash TLSA contre le certificat présenté en live,
et s’assurait qu’un second ingénieur pouvait suivre le runbook sans connaissance tribale.

Un jour, une mise à jour DS côté registraire fut programmée dans le cadre d’un rollover KSK planifié. L’interface du registraire accepta le DS,
mais un délai d’approbation interne fit que l’ensemble DNSKEY de la zone n’était pas mis à jour comme prévu. Pendant une brève fenêtre,
le DS chez le parent ne correspondait pas au matériel de signature de l’enfant.

La surveillance le détecta rapidement car ils avaient une vérification externe simple : « delv doit fully validate maintenant ».
Ils ont rollbacké le changement DS et relancé le rollover avec la séquence correcte. Aucun impact prolongé sur le mail.
La pratique ennuyeuse a sauvé la mise—pas parce qu’elle empêchait les erreurs, mais parce qu’elle a raccourci le temps nécessaire pour être en erreur.

Listes de contrôle / plan étape par étape

Étape par étape : décider de déployer DANE pour SMTP

1. Définissez le modèle de menace. Si vous ne vous défendez pas contre des attaquants actifs ou des exigences de conformité strictes, DANE peut être une complexité inutile.
2. Inventoriez les contreparties. Si la plupart de vos pairs importants ne valident pas DANE, le ROI est limité.
3. Confirmez la maturité DNSSEC. Vous avez besoin d’un processus de rollover de clés, de surveillance, et de quelqu’un d’astreinte qui peut réparer.
4. Décidez du périmètre d’application. Envisagez d’abord une application par domaine pour l’envoi ; pour l’entrée, c’est surtout « publier et espérer que les émetteurs l’utilisent ».
5. Choisissez le mode TLSA. Décidez entre l’épinglage SPKI (selector 1) vs le certificat complet (selector 0) ; SPKI est généralement plus tolérant aux rotations.
6. Concevez la stratégie de rotation. Planifiez la double publication pour les transitions et définissez les TTL.
7. Implémentez la surveillance. Validation DNSSEC externe + présence TLSA + vérifications de correspondance cert/SPKI, sur un planning.
8. Rédigez le runbook. Incluez « comment désactiver l’application pour un domaine spécifique temporairement » pour contenir les incidents.

Checklist opérationnelle : avant d’activer l’application DANE sortante

• Tous les résolveurs récursifs utilisés par les MTA valident DNSSEC (strictement, pas par espoir).
• Validation externe avec delv réussit pour votre domaine et les noms d’hôtes MX.
• TLSA existe, signé, pour chaque nom d’hôte MX et correspond à la clé présentée par le certificat.
• Le déploiement cert/clé est cohérent sur la flotte qui accepte le courrier derrière chaque nom d’hôte MX.
• TLS‑RPT est configuré pour que vous receviez un signal quand des pairs échouent (même si pas spécifique à DANE, ça aide).
• L’astreinte a une page « DANE cassé » avec l’ordre de diagnostic (voir le playbook ci‑dessus).

Checklist de rotation : mettre à jour les clés SMTP sans casser DANE

1. Abaissez le TTL TLSA au moins une fenêtre de TTL avant les changements (si vous prévoyez de le changer).
2. Publiez des TLSA supplémentaires pour la nouvelle clé (double‑publication ancien + nouveau hash SPKI).
3. Attendez la propagation sur les serveurs autoritaires et vérifiez en externe.
4. Déployez le nouveau certificat/clé sur tous les nœuds MX pour un nom d’hôte (ou videz/flippez de façon atomique).
5. Vérifiez en recomputant le hash SPKI depuis le serveur live et en le comparant au TLSA.
6. Après la période de recouvrement, supprimez l’ancien enregistrement TLSA.
7. Rendez le TTL à la valeur normale.

Seconde (et dernière) blague courte : Si vous faites tourner les clés DNSSEC et les clés SMTP le même jour, pensez à prendre le lendemain—d’une façon ou d’une autre.

FAQ

DANE remplace‑t‑il SPF, DKIM ou DMARC ?

Non. DANE renforce la sécurité du transport (authenticité TLS pour SMTP). SPF/DKIM/DMARC concernent l’authentification de l’expéditeur et l’alignement de domaine.
Vous voulez généralement les deux jeux, pour des raisons différentes.

DANE est‑il meilleur que MTA‑STS ?

« Meilleur » dépend de ce que vous êtes prêt à exploiter. DANE évite les AC publiques et peut épingler les clés via DNSSEC.
MTA‑STS s’appuie sur le WebPKI et l’hébergement HTTPS, et il est souvent plus simple pour les organisations qui gèrent déjà l’infrastructure web.
Si DNSSEC n’est pas une compétence cœur, MTA‑STS est fréquemment le gain le plus réaliste.

DANE garantira‑t‑il la livraison chiffrée des e‑mails ?

Il peut garantir l’utilisation de TLS et l’identité du pair pour les MTA qui appliquent DANE et peuvent valider DNSSEC. Il ne peut pas forcer l’ensemble de l’internet à se conformer.
Beaucoup d’émetteurs livrent encore de façon opportuniste.

Puis‑je utiliser DANE avec un certificat auto‑signé sur mon MX ?

Oui, c’est l’un des attraits de DANE. Avec usage 3 (DANE‑EE), vous pouvez épingler un certificat leaf auto‑signé ou, plus couramment, le hash SPKI.
La confiance vient de DNSSEC, pas d’une AC publique.

Quel style d’enregistrement TLSA est le plus sûr pour l’exploitation ?

Épingler le SPKI (selector 1) avec un matching SHA‑256 (matching type 1) est courant car cela tolère la réémission de certificat
tant que la clé reste la même. Épingler le certificat entier est plus fragile lors des renouvellements.

Quelle est la raison principale des échecs de déploiement DANE ?

Des erreurs dans le cycle de vie DNSSEC : décalage DS/DNSKEY, signatures expirées, délégation cassée après migration de fournisseur DNS,
et absence de surveillance de validation externe. DANE n’est fiable que dans la mesure où vos opérations DNSSEC le sont.

Puis‑je publier TLSA pour le domaine et non pour les noms d’hôtes MX ?

Pour DANE SMTP, vous devez généralement publier TLSA aux noms d’hôtes MX car le MTA émetteur se connecte à la cible MX.
Publiez TLSA pour chaque nom d’hôte MX que vous attendez que les émetteurs utilisent.

Dois‑je appliquer DANE pour l’envoi de mails globalement ?

En général non. Commencez par une map de politique pour des domaines partenaires spécifiques avec lesquels vous vous êtes coordonnés, ou pour des flux à haute valeur où vous acceptez un échec fermé.
L’application globale augmente la portée des problèmes DNSSEC et des mauvaises configurations de pairs.

Comment savoir si un partenaire valide DANE ?

Demandez leurs logs MTA ou faites un test coordonné avec un émetteur connu validant DANE. À défaut de preuve, supposez qu’ils ne le font pas.
L’écosystème e‑mail regorge de déclarations « on le supporte » qui signifient « on l’a essayé une fois ».

DANE aide‑t‑il pour le courrier entrant vers nous ?

Vous pouvez publier TLSA pour vos hôtes MX afin de permettre aux émetteurs de vous authentifier. Vous ne pouvez pas forcer les émetteurs à valider.
Le bénéfice entrant dépend du nombre d’émetteurs importants qui appliquent réellement DANE.

Prochaines étapes réalisables cette semaine

Si vous envisagez DANE pour SMTP, ne commencez pas par ajouter des TLSA parce que ça fait productif.
Commencez par prouver que vous pouvez exploiter DNSSEC sans drame.

1. Exécutez des contrôles externes de validation DNSSEC quotidiennement (même une simple sonde delv) pour votre domaine et chaque nom d’hôte MX.
   Si vous ne pouvez pas détecter rapidement une confiance cassée, DANE ne sera pas votre ami.
2. Inventoriez votre flotte MX et le déploiement des certificats. Assurez‑vous que chaque nom d’hôte MX est cohérent sur les nœuds et load balancers.
3. Choisissez un flux partenaire où vous pouvez coordonner l’application et tester DANE de bout en bout.
   Utilisez‑le pour durcir vos runbooks et votre processus de rotation.
4. Décidez de votre posture de défaillance : où vous échouerez fermé (sécurité) et où vous échouerez ouvert (délivrabilité).
   Notez cette décision, car l’incident la tranchera sinon pour vous.
5. Si DNSSEC n’est pas mature, envisagez sérieusement MTA‑STS + TLS‑RPT en premier.
   Ce n’est pas « moins sûr », c’est « plus opérable » pour beaucoup d’organisations—et la sécurité opérable est celle qui survit au contact du mardi.

DANE n’est pas une mauvaise idée. C’est un outil tranchant. Si vous avez les mains pour l’utiliser, il résout proprement un vrai problème SMTP.
Si vous ne les avez pas, il résoudra plutôt votre disponibilité.