Dépannage DANE/TLSA : diagnostiquer et corriger les erreurs courantes

Vous avez déployé DANE/TLSA sur votre serveur email en suivant les bonnes pratiques, tout fonctionnait, puis un jour les emails commencent à être refusés par certains destinataires. Le message d'erreur mentionne "failed DANE validation" ou "TLSA record not found", mais les logs ne vous disent pas exactement ce qui a changé. Que s'est-il passé entre hier et aujourd'hui ?

Ce scénario est le quotidien des administrateurs DANE. La difficulté ne vient pas du protocole lui-même : DANE repose sur quatre composants interdépendants, et un seul maillon défaillant casse toute la chaîne. DNSSEC, certificat TLS, enregistrement TLSA, configuration MTA : chacun peut tomber indépendamment des trois autres.

Ce guide couvre les 5 erreurs DANE/TLSA les plus fréquentes avec, pour chacune, le symptôme, les commandes de diagnostic et la correction. Il s'adresse aux administrateurs système et DevOps qui ont déjà une configuration DANE en place. Si vous n'avez pas encore déployé DANE, commencez par le premier article de cette série (voir "Guides connexes" en bas de page).

Les 5 erreurs DANE les plus courantes

Les problèmes DANE se répartissent en 5 catégories. Laquelle affecte votre serveur ? Chaque section ci-dessous décrit le symptôme observable, la commande de diagnostic et la correction.

Erreur 1 : DNSSEC non signé ou signature expirée

Symptôme : les serveurs émetteurs signalent "DANE required but not available" ou "no DNSSEC" dans les rapports TLS-RPT. Sans DNSSEC, pas de DANE : les emails passent en mode opportuniste ou sont refusés.

Diagnostic :

# Vérifier le flag AD (Authenticated Data)
dig +dnssec MX captaindns.com | grep flags
# Résultat attendu : flags: qr rd ra ad

# Vérifier la validité des signatures RRSIG
dig +dnssec SOA captaindns.com | grep RRSIG
# La date d'expiration est dans le champ RRSIG

Causes fréquentes :

• Le registrar a désactivé DNSSEC après un transfert de domaine
• Les clés DNSSEC (KSK/ZSK) ont expiré sans rotation automatique
• Le DS record chez le registrar ne correspond plus à la DNSKEY active

Correction : vérifiez que le DS record chez votre registrar correspond à votre DNSKEY. Si vous utilisez Bind9, vérifiez les dates d'expiration des clés avec dnssec-settime et configurez la rotation automatique.

Erreur 2 : hash TLSA obsolète après renouvellement du certificat

Symptôme : "TLSA validation failed" ou "certificate mismatch" dans les logs. C'est l'erreur DANE la plus fréquente en production. Elle survient typiquement 60 à 90 jours après le déploiement initial, au premier renouvellement Let's Encrypt.

Diagnostic :

# Hash du certificat actif (selector 0 : Full cert)
openssl s_client -connect mail.captaindns.com:25 \
  -starttls smtp 2>/dev/null \
  | openssl x509 -outform DER \
  | openssl dgst -sha256

# Hash publié dans le DNS
dig TLSA _25._tcp.mail.captaindns.com +short
# Comparer les 64 caractères hexadécimaux

Causes fréquentes :

• Le hook de renouvellement Certbot ne met pas à jour le TLSA
• Le selector est Full (0) au lieu de SPKI (1) : chaque renouvellement change le hash
• L'usage est DANE-EE (3) sans --reuse-key dans Certbot

Correction :

• Solution rapide : générez le nouveau hash avec notre DANE TLSA Generator et mettez à jour le DNS
• Solution durable : utilisez SPKI selector (1) avec --reuse-key dans Certbot, ou passez à DANE-TA (2) avec le certificat CA Let's Encrypt. Consultez notre tutoriel Postfix/Bind/Let's Encrypt (article 2 de cette série) pour la configuration du hook de renouvellement automatique

Erreur 3 : TLSA publié au mauvais nom DNS

Symptôme : "no TLSA records found" alors que vous avez bien créé l'enregistrement. Vous avez publié le TLSA, mais au mauvais endroit. C'est le piège classique des débutants DANE.

Diagnostic :

# Trouver le hostname MX
dig MX captaindns.com +short
# Résultat : 10 mail.captaindns.com.

# Vérifier le TLSA au bon endroit (hostname MX)
dig TLSA _25._tcp.mail.captaindns.com +short

# Erreur typique : TLSA publié sur le domaine au lieu du MX
dig TLSA _25._tcp.captaindns.com +short
# Ce TLSA est IGNORE par les serveurs émetteurs

Cause : confusion entre le domaine et le hostname MX. Le domaine reçoit le courrier, le hostname MX le traite. Le TLSA doit être publié sur _25._tcp.<hostname-MX>, pas sur _25._tcp.<domaine>, conformément à la RFC 7672 section 2.1.1.

Correction : publiez le TLSA sur _25._tcp.mail.captaindns.com (ou le hostname que retourne votre enregistrement MX). Si votre domaine a plusieurs MX, chaque hostname doit avoir son propre TLSA.

Erreur 4 : STARTTLS non disponible ou mal configuré

Symptôme : DANE est configuré côté DNS mais le serveur ne propose pas STARTTLS, ou le certificat présenté ne correspond pas au hostname. Un TLSA parfait ne sert à rien si le serveur ne chiffre pas la connexion. Les logs montrent "TLS handshake failed" ou "certificate hostname mismatch".

Diagnostic :

# Tester si STARTTLS est proposé
openssl s_client -connect mail.captaindns.com:25 \
  -starttls smtp -verify 5

# Vérifier le Common Name et les SAN du certificat
openssl s_client -connect mail.captaindns.com:25 \
  -starttls smtp 2>/dev/null \
  | openssl x509 -noout -subject -ext subjectAltName

Causes fréquentes :

• smtpd_tls_cert_file pointe vers un mauvais fichier dans Postfix
• Le certificat ne contient pas le hostname MX dans ses Subject Alternative Names
• Le firewall bloque STARTTLS ou le port 25 n'est pas accessible en TLS

Correction : dans Postfix, vérifiez que smtpd_tls_security_level est au minimum may et que les chemins des certificats sont corrects :

# /etc/postfix/main.cf
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.captaindns.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.captaindns.com/privkey.pem
smtpd_tls_security_level = may

Erreur 5 : propagation DNS incomplète

Symptôme : DANE fonctionne par intermittence. Un test local passe, mais des serveurs distants signalent des erreurs. Ce comportement aléatoire pointe presque toujours vers un problème de propagation DNS, surtout après une mise à jour récente.

Diagnostic :

# Comparer les réponses entre serveurs NS
dig TLSA _25._tcp.mail.captaindns.com @ns1.captaindns.com +short
dig TLSA _25._tcp.mail.captaindns.com @ns2.captaindns.com +short

# Vérifier le TTL restant
dig TLSA _25._tcp.mail.captaindns.com +noall +answer

Causes fréquentes :

• Transfert de zone incomplet entre serveurs DNS primaire et secondaire
• TTL élevé sur l'ancien enregistrement (les caches DNS gardent l'ancienne valeur)
• Un serveur NS ne répond pas ou retourne une version obsolète de la zone

Correction : vérifiez que tous vos serveurs NS retournent la même valeur TLSA. La règle d'or : ne jamais supprimer un ancien TLSA avant l'expiration de son TTL. Pour les rotations de certificat, publiez le nouveau TLSA au moins 2x TTL avant la rotation effective.

Surveiller DANE en production

Corriger une erreur ponctuelle ne suffit pas. DANE casse silencieusement : sans monitoring, vous ne découvrez le problème que lorsque vos correspondants vous signalent des rejets. Les 3 mécanismes suivants préviennent les incidents récurrents.

TLS-RPT : activez les rapports TLS-RPT (RFC 8460) pour recevoir les signalements d'échec DANE de la part des serveurs émetteurs. Le champ failure-type dans le rapport JSON indique précisément le type d'erreur :

Monitoring certificat : configurez une alerte 14 jours avant l'expiration du certificat TLS. Le renouvellement Let's Encrypt est automatique, mais le hook de mise à jour TLSA peut échouer sans aucune alerte visible.

Vérification automatique : planifiez une vérification quotidienne avec notre DANE TLSA Syntax Checker ou un script cron qui compare le hash publié au certificat actif :

#!/bin/bash
# Vérification quotidienne DANE
TLSA_HASH=$(dig TLSA _25._tcp.mail.captaindns.com +short | awk '{print $4}')
CERT_HASH=$(openssl s_client -connect mail.captaindns.com:25 \
  -starttls smtp 2>/dev/null \
  | openssl x509 -pubkey -noout \
  | openssl pkey -pubin -outform DER \
  | openssl dgst -sha256 | awk '{print $2}')

if [ "$TLSA_HASH" != "$CERT_HASH" ]; then
  echo "ALERTE : hash TLSA diverge du certificat actif" | \
    mail -s "DANE TLSA mismatch" admin@captaindns.com
fi

Plan d'action recommandé

1. Diagnostiquer : utilisez la méthodologie en 5 étapes ci-dessus ou notre DANE TLSA Checker pour identifier le problème
2. Identifier : classez l'erreur dans l'une des 5 catégories (DNSSEC, hash, nom DNS, STARTTLS, propagation)
3. Corriger : appliquez la solution correspondante avec les commandes fournies
4. Vérifier : testez la correction avec dig +dnssec et openssl s_client avant de considérer le problème résolu
5. Prévenir : mettez en place TLS-RPT, le monitoring certificat et la vérification automatique

📚 Guides DANE/TLSA connexes

• DANE/TLSA : le guide complet pour authentifier les certificats email par DNS : fonctionnement, anatomie TLSA, usages recommandés et comparaison avec MTA-STS
• Configurer DANE/TLSA avec Postfix, Bind et Let's Encrypt : tutoriel pas-à-pas avec commandes copiables, automatisation du renouvellement et vérification
• Déployer DANE pour Exchange Online et Microsoft 365

Sources

• RFC 7672 - SMTP Security via Opportunistic DANE TLS
• RFC 7671 - The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance
• RFC 6698 - The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
• Postfix TLS README - DANE
• ISC BIND 9 DNSSEC Guide