DANE TLSA Checker

Pourquoi vérifier votre DANE TLSA

Le transport SMTP en TLS opportuniste laisse la porte ouverte à deux scénarios discrets : un attaquant en position intermédiaire qui supprime STARTTLS pour forcer du clair, ou un faux certificat accepté par un MTA émetteur qui ne peut pas distinguer le vrai du faux. DANE colmate cette faille en publiant un hash du certificat attendu dans le DNS, signé par DNSSEC.

Mais DANE est exigeant : un enregistrement TLSA mal placé, une zone non signée DNSSEC, ou un hash désynchronisé après renouvellement de certificat suffit à invalider silencieusement votre déploiement. Aucun message d'erreur n'est remonté côté MTA émetteur : la connexion bascule en TLS opportuniste sans bruit, et votre flux SMTP perd la protection que vous croyiez avoir.

Vérifier votre DANE TLSA en direct devient indispensable :

• Après publication initiale : confirmer que l'enregistrement est résolu, signé DNSSEC, et que le hash correspond au certificat servi
• Après tout renouvellement de certificat : la cause numéro 1 des pannes DANE est la désynchronisation hash/certificat
• Audit de sécurité mail : valider que DANE couvre tous les MX et qu'aucun bord n'est laissé en TLS opportuniste
• Avant migration de fournisseur mail : Microsoft 365, Google Workspace et hébergeurs traditionnels n'ont pas le même niveau de prise en charge de DANE

Comment utiliser ce checker en 3 étapes

Étape 1 : entrer le domaine à analyser

Saisissez le domaine de messagerie tel qu'il apparaît dans vos adresses email :

• captaindns.com (domaine principal)
• marketing.captaindns.com (sous-domaine si vous gérez plusieurs zones)

L'outil énumère automatiquement les MX, puis interroge _25._tcp.<hôte-mx> pour chacun. La validation DNSSEC remonte la chaîne complète jusqu'à la racine.

Étape 2 : lire les résultats par MX

Le checker affiche, pour chaque MX :

Étape 3 : appliquer les correctifs

Les diagnostics sont classés par gravité :

• Bloquant : DNSSEC absent, TLSA introuvable, hash désaligné. Le déploiement DANE ne protège personne en l'état.
• Avertissement : combinaison non recommandée (usage 0 ou 1 sans CA contrôlée), matching type 0 qui publie le certificat brut, TTL anormalement long.
• Info : MX sans prise en charge de DANE attendue (Google Workspace), enregistrements multiples compatibles avec une rotation de clé en cours.

Corrigez la zone DNS, attendez la propagation (TTL), puis relancez le checker pour confirmer.

Anatomie d'un enregistrement TLSA

L'enregistrement TLSA est publié à un emplacement précis et contient quatre champs strictement spécifiés par le RFC 6698.

Emplacement DNS

_25._tcp.mail.captaindns.com.  IN  TLSA  3 1 1 2bb183af2e2b295b...

Le nom du propriétaire (owner name) suit le modèle _<port>._<protocole>.<host>. Pour SMTP entrant, c'est invariablement _25._tcp.<hôte-mx>. Publier l'enregistrement sur l'apex du domaine au lieu du nom d'hôte du MX est l'erreur la plus fréquente : aucun MTA ne le trouve.

Les quatre champs

La combinaison recommandée pour SMTP

3 1 1 reste le standard de fait :

• Usage 3 (DANE-EE) : la confiance est ancrée dans votre clé, indépendamment de toute autorité de certification
• Sélecteur 1 (SPKI) : l'enregistrement reste valide tant que la clé publique est conservée, même après renouvellement de certificat
• Matching type 1 (SHA-256) : 32 octets, universellement pris en charge, suffisamment robuste

DNSSEC : le prérequis incontournable

Sans DNSSEC, un enregistrement TLSA est ignoré par tout MTA conforme. Le checker plafonne explicitement le score à 30/100 dès que la chaîne DNSSEC est cassée ou absente.

Chaîne de confiance à valider

Racine (.) -> TLD (.com) -> Domaine (captaindns.com) -> _25._tcp.mail.captaindns.com
   DNSSEC       DNSSEC              DNSSEC                       Signé

Chaque maillon doit être signé. Une zone parent non signée invalide tout ce qui suit, indépendamment de la qualité de l'enregistrement TLSA en aval. Le checker remonte la chaîne et identifie le maillon défaillant.

Pièges courants liés à DNSSEC

• Zone du domaine signée mais pas la zone du host MX : si vos MX pointent vers un sous-domaine sur une zone séparée, c'est cette zone-là qui doit être signée.
• Enregistrements DS manquants chez le registrar : la zone signée localement reste invisible pour les résolveurs externes si le DS n'est pas remonté au TLD.
• RRSIG expirées : les signatures DNSSEC ont une durée de validité. Un renouvellement raté plonge la zone en mode bogus.

Le checker précise lequel de ces cas est en jeu.

Stratégies de rotation de clé

La rotation de certificat sans interruption de service est la difficulté opérationnelle principale de DANE. Trois stratégies coexistent.

Stratégie 1 : sélecteur SPKI + réutilisation de clé

Avec --reuse-key (Certbot) ou --key-type rsa partagé, la clé publique reste identique entre renouvellements. Le hash SPKI ne change pas, et l'enregistrement 3 1 1 <hash-spki> reste valide indéfiniment. C'est la stratégie la plus simple.

Stratégie 2 : DANE-TA sur l'autorité de certification

2 0 1 <sha256-du-certificat-CA>

Vous épinglez le certificat racine de votre CA (Let's Encrypt ISRG Root X1 par exemple) au lieu de votre propre certificat. Avantage : aucune mise à jour DNS lors d'un renouvellement. Inconvénient : confiance déléguée à la CA, donc moins strict que DANE-EE.

Stratégie 3 : double enregistrement pendant la transition

_25._tcp.mail.captaindns.com.  IN  TLSA  3 1 1 <hash-cle-actuelle>
_25._tcp.mail.captaindns.com.  IN  TLSA  3 1 1 <hash-cle-suivante>

Publiez le hash de la clé suivante 7 jours avant la rotation (au minimum 2 fois le TTL maximum). Les MTA conformes acceptent une connexion si au moins un enregistrement correspond au certificat présenté. Après rotation, supprimez l'ancien hash.

Le checker reconnaît la présence d'enregistrements multiples et l'affiche comme une rotation de clé en cours plutôt que comme une erreur.

DANE et SMTP : ce qui se passe à la livraison

1. Le serveur expéditeur résout les MX de captaindns.com
2. Il interroge _25._tcp.<mx> pour récupérer l'enregistrement TLSA
3. Il valide la chaîne DNSSEC jusqu'à la racine
4. Il ouvre STARTTLS sur le port 25 et récupère le certificat présenté
5. Il calcule le hash du certificat selon le matching type publié
6. Si le hash correspond : connexion sécurisée confirmée
7. Sinon : refus de livrer (différence fondamentale avec le TLS opportuniste)

DANE vs TLS opportuniste

Diagnostics courants et solutions

Aucun enregistrement TLSA trouvé

Cause : le domaine n'a pas configuré DANE, ou l'enregistrement est publié au mauvais emplacement.

Solution : générez et publiez un enregistrement TLSA à _25._tcp.<hôte-mx>. Notre guide d'installation DANE TLSA pour Postfix, BIND et Let's Encrypt couvre le déploiement pas-à-pas.

DNSSEC absent ou cassé

Cause : la zone n'est pas signée, ou les DS n'ont pas été remontés au registrar.

Solution : activez DNSSEC chez votre hébergeur DNS, exportez les DS, et publiez-les chez votre registrar. Vérifiez la propagation avec un outil DNSSEC dédié avant de relancer ce checker.

Hash de certificat désynchronisé

Cause : le certificat TLS a été renouvelé et le hash publié n'est plus à jour.

Solution : utilisez le sélecteur SPKI (1) avec --reuse-key pour rendre l'enregistrement invariant au renouvellement. À défaut, mettez à jour le hash immédiatement et adoptez la stratégie de double enregistrement pour les prochaines rotations.

TLSA au mauvais emplacement

Cause : enregistrement publié sur le domaine racine au lieu du nom d'hôte du MX, ou sur le mauvais port.

Solution : republiez à _25._tcp.<hôte-mx> exactement. Pour un MX mail.captaindns.com, c'est _25._tcp.mail.captaindns.com. Pas autre chose.

Microsoft 365 / Google Workspace sans DANE en entrée

Cause : ces fournisseurs ne signent pas leurs zones DNS, donc DANE n'est pas applicable côté entrant.

Solution : déployez MTA-STS à la place de DANE pour ces fournisseurs. MTA-STS s'appuie sur HTTPS au lieu de DNSSEC et est pris en charge par Google Workspace et Microsoft 365.

DANE et MTA-STS : approches complémentaires

Les deux protocoles forment une défense en profondeur, pas un choix exclusif.

Recommandation : déployez les deux. DANE pour les domaines hébergés sur Postfix ou Exim, MTA-STS pour les domaines délégués à Microsoft 365 ou Google Workspace. La couverture maximale impose la combinaison.

Outils complémentaires et ressources

Guides associés

• DANE TLSA : le guide complet - Comprendre DANE de bout en bout, du DNSSEC au déploiement SMTP.
• DANE TLSA sur Postfix, BIND et Let's Encrypt - Installation pas-à-pas avec rotation de clé.
• DANE TLSA et Microsoft 365 Exchange Online - Prise en charge de DANE en entrée et en sortie sur Exchange Online.
• DANE TLSA : 12 cas pratiques de dépannage - Diagnostic et résolution des incidents DANE.
• MTA-STS vs DANE : comparatif détaillé - Choisir ou combiner les deux protocoles.

Spécifications

• RFC 6698 - DANE TLSA (spécification originale)
• RFC 7671 - Updates to DANE (clarifications opérationnelles)
• RFC 7672 - SMTP Security via DANE (DANE pour SMTP)