Que vérifie cet inspecteur DANE TLSA ?
Un enregistrement TLSA désynchronisé bloque la livraison email depuis les expéditeurs DANE-aware. Cet outil détecte ces problèmes avant qu'ils n'impactent votre courrier.
L'inspecteur exécute cinq contrôles sur chaque domaine :
- Résolution MX : identifie les serveurs mail du domaine
- Recherche TLSA : interroge
_25._tcp.hostnamepour chaque MX - Vérification DNSSEC : contrôle que la chaîne de signatures est intacte
- Validation syntaxe : vérifie la conformité RFC 6698 et RFC 7672
- Correspondance certificat : compare le TLSA au certificat TLS actuel du serveur
Comprendre les enregistrements DANE TLSA
Emplacement DNS
L'enregistrement TLSA se publie à un emplacement précis, dérivé du hostname MX, jamais du domaine racine.
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 2bb183af2e2b295b...
Règle critique : si le MX de captaindns.com pointe vers mail.captaindns.com, publiez le TLSA à _25._tcp.mail.captaindns.com. Un TLSA au mauvais emplacement est invisible pour les MTA.
Structure de l'enregistrement
| Champ | Valeurs | Signification |
|---|---|---|
| Certificate Usage | 0 (PKIX-TA), 1 (PKIX-EE), 2 (DANE-TA), 3 (DANE-EE) | Type de contrainte |
| Selector | 0 (Cert), 1 (SPKI) | Partie du certificat matchée |
| Matching Type | 0 (Full), 1 (SHA-256), 2 (SHA-512) | Méthode de comparaison |
| Certificate Data | Hexadécimal | Hash ou données complètes |
Configuration recommandée pour SMTP
3 1 1 <sha256-hash>
- Usage 3 (DANE-EE) : Pas besoin de validation PKIX
- Selector 1 (SPKI) : Survit aux renouvellements avec même clé
- Matching Type 1 (SHA-256) : Compact et sécurisé
Le rôle de DNSSEC
Sans DNSSEC, les enregistrements TLSA n'ont aucune valeur. Les MTA les ignorent systématiquement.
Chaîne de confiance
Racine DNS (.) → TLD (.com) → Domaine (captaindns.com) → TLSA record
DNSSEC DNSSEC DNSSEC Signé
Chaque niveau de la hiérarchie DNS doit être signé. Un seul maillon manquant invalide toute la chaîne : les TLSA deviennent non authentifiables et sont ignorés.
Ce que notre outil vérifie
| Vérification | Description | Impact si échoue |
|---|---|---|
| Zone signée | Le domaine a des clés DNSSEC | TLSA records ignorés |
| Chaîne valide | Les signatures sont vérifiables | TLSA records ignorés |
| Signature non expirée | Les RRSIG sont encore valides | TLSA records ignorés temporairement |
Problèmes courants détectés
Aucun enregistrement TLSA trouvé
Cause : le domaine n'a pas configuré DANE. Impact : aucune protection DANE pour le courrier entrant. Les connexions SMTP restent en TLS opportuniste. Action : générez un enregistrement DANE TLSA, puis publiez-le dans votre zone DNS.
DNSSEC absent
Cause : le domaine n'est pas signé DNSSEC. Impact : les enregistrements TLSA sont ignorés, même s'ils existent. DANE est inopérant. Action : activez DNSSEC chez votre registrar et votre hébergeur DNS. Vérifiez la propagation des enregistrements DS.
Hash de certificat désynchronisé
Cause : le certificat TLS a été renouvelé sans mise à jour du TLSA.
Impact : les MTA DANE-aware refusent la connexion ou repassent en TLS opportuniste. Du courrier peut être retardé ou rejeté.
Action : mettez à jour le hash TLSA immédiatement. Pour éviter cette situation, utilisez DANE-TA (usage 2) ou SPKI selector (1) avec réutilisation de clé (--reuse-key).
TLSA au mauvais emplacement
Cause : enregistrement publié sur le domaine racine au lieu du hostname MX.
Impact : les serveurs expéditeurs ne trouvent pas l'enregistrement TLSA. DANE est invisible.
Action : publiez à _25._tcp.<hostname-mx>, pas à _25._tcp.<domaine>. Vérifiez avec cet outil après correction.
Stratégie de rotation de certificat avec DANE
La désynchronisation certificat/TLSA est la cause n°1 des échecs DANE. Choisissez une stratégie de rotation adaptée à votre infrastructure.
Stratégie 1 : DANE-TA (recommandé pour Let's Encrypt)
Épinglez le certificat CA au lieu du certificat serveur :
2 0 1 <sha256-du-certificat-CA>
Avantage : Le TLSA reste valide tant que la même CA signe vos certificats. Inconvénient : Moins strict qu'un épinglage direct.
Stratégie 2 : DANE-EE avec réutilisation de clé
Gardez la même clé privée entre renouvellements :
3 1 1 <sha256-de-la-cle-publique>
Avantage : Épinglage fort + survit aux renouvellements.
Inconvénient : Nécessite de configurer la réutilisation de clé (ex: --reuse-key dans Certbot).
Stratégie 3 : Double enregistrement (rollover)
Publiez les deux TLSA avant la rotation :
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 <hash-certificat-actuel>
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 <hash-certificat-futur>
Après la rotation, supprimez l'ancien.
DANE et SMTP : protection du courrier en transit
Comment fonctionne DANE pour SMTP
- Le serveur expéditeur résout le MX de
captaindns.com - Il cherche les enregistrements TLSA pour le serveur MX
- Il vérifie que la réponse TLSA est signée DNSSEC
- Il se connecte en STARTTLS et compare le certificat aux données TLSA
- Si le certificat correspond → connexion sécurisée confirmée
- Si non → refuse de livrer (contrairement au TLS opportuniste)
Différence avec le TLS opportuniste
Le TLS opportuniste accepte n'importe quel certificat, y compris un faux. DANE impose une vérification cryptographique via DNSSEC.
| Aspect | TLS opportuniste | DANE |
|---|---|---|
| Vérification certificat | Aucune (accepte tout) | Via enregistrement TLSA signé DNSSEC |
| Protection MITM | Non | Oui |
| Fallback non-TLS | Oui | Non (par défaut) |
| Prérequis | Aucun | DNSSEC |
Vérifiez votre configuration DANE pour confirmer que vos emails bénéficient de cette protection.
FAQ - Questions fréquentes
Q : Que vérifie le DANE TLSA Checker ?
R : Notre checker effectue un lookup DNS des enregistrements TLSA sur votre domaine, valide leur syntaxe, vérifie le statut de signature DNSSEC, contrôle la correspondance avec le certificat du serveur mail, et signale les problèmes de configuration.
Q : Pourquoi mon DANE TLSA check échoue-t-il ?
R : Causes courantes : DNSSEC absent sur le domaine, enregistrements TLSA non publiés au bon emplacement (_25._tcp.mail.captaindns.com), hash de certificat désynchronisé après renouvellement, ou combinaison usage/selector/matching type incorrecte.
Q : Quel est le bon nom DNS pour les enregistrements TLSA SMTP ?
R : Les enregistrements TLSA SMTP doivent être publiés à _port._protocole.hostname, typiquement _25._tcp.mail.captaindns.com. Le hostname doit être celui du serveur MX cible, pas le domaine lui-même.
Q : Comment DANE protège-t-il le courrier en transit ?
R : DANE empêche les attaques man-in-the-middle sur les connexions SMTP en permettant au serveur expéditeur de vérifier le certificat TLS via DNS/DNSSEC au lieu de dépendre uniquement des autorités de certification.
Q : À quelle fréquence vérifier mes enregistrements DANE TLSA ?
R : Vérifiez après chaque renouvellement de certificat TLS, après tout changement DNS, et mensuellement. L'expiration de certificat est la cause numéro 1 des échecs DANE.
Q : DANE fonctionne-t-il avec les certificats Let's Encrypt ?
R : Oui, mais planifiez les renouvellements de 90 jours. DANE-TA (usage 2) avec le certificat CA de Let's Encrypt est plus facile. DANE-EE (usage 3) avec réutilisation de clé (--reuse-key dans Certbot) fonctionne aussi.
Outils complémentaires
| Outil | Utilité |
|---|---|
| DANE TLSA Validator | Valider la syntaxe avant publication |
| DANE TLSA Generator | Créer un enregistrement TLSA depuis un certificat |
| Inspecteur MTA-STS | Vérifier la politique MTA-STS (sécurité TLS alternative) |
| Inspecteur TLS-RPT | Surveiller les échecs TLS via les rapports |
| SMTP Check | Vérifier la connexion STARTTLS que DANE protège |
| Audit domaine email | Audit complet de l'authentification email |
Ressources utiles
- RFC 6698 - DANE TLSA (spécification originale)
- RFC 7671 - Updates to DANE (mises à jour opérationnelles)
- RFC 7672 - SMTP Security via DANE (DANE pour SMTP)
- Microsoft - DANE with DNSSEC (guide Exchange Online)
- Let's Encrypt - Using DANE (conseils DANE avec LE)