Pourquoi utiliser un validateur hors ligne
Un enregistrement TLSA mal formé est ignoré sans avertissement par les MTA conformes. Vous croyez que votre déploiement DANE protège votre flux SMTP entrant ; en pratique, aucun serveur émetteur ne vérifie quoi que ce soit. La panne est silencieuse jusqu'au prochain audit, ou jusqu'à un incident de livraison qui révèle la faille.
Le validateur de syntaxe DANE TLSA analyse votre enregistrement sans publier ni interroger le DNS. Aucune donnée ne quitte votre navigateur, aucun signal ne fuite vers un résolveur externe. Cette approche hors ligne couvre quatre cas d'usage que l'audit en direct ne peut pas traiter.
Cas d'usage typiques :
- Avant déploiement : validez un brouillon avant publication DNS, pour éviter un enregistrement silencieusement ignoré.
- Sortie de générateur : vérifiez la syntaxe d'un enregistrement produit par un outil tiers, un wiki interne ou un modèle partagé.
- Débogage hors ligne : reproduisez et corrigez une erreur sans toucher au DNS public, par exemple en pré-production.
- Revue de configuration : examinez un enregistrement reçu d'un partenaire ou exporté d'une infrastructure cliente avant de l'appliquer.
Le validateur applique la spécification RFC 6698 sur la structure, et la RFC 7671 sur les contraintes opérationnelles. Aucune requête DNS, aucune connexion externe.
Comment utiliser ce validateur en 3 étapes
Étape 1 : coller l'enregistrement TLSA
Copiez la valeur de votre enregistrement dans le champ prévu :
3 1 1 2bb183af2e2b295b444c1fd4072f2b59a8c1c9abf7f3f1e9b0d4c7e8f1a2b3c4
Vous pouvez aussi coller la ligne complète avec le nom du propriétaire :
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 2bb183af...
Le validateur extrait les quatre champs et analyse chacun indépendamment. Aucune connexion réseau n'est effectuée à cette étape.
Étape 2 : lire le verdict
Les résultats sont classés par gravité :
- Erreur : problème bloquant, l'enregistrement sera ignoré ou rejeté par les MTA conformes
- Avertissement : combinaison non recommandée, fonctionnelle mais qui expose à des risques opérationnels
- Valide : syntaxe conforme aux RFC 6698 et 7671
Chaque message inclut le champ concerné, la valeur invalide, et la correction attendue.
Étape 3 : corriger avant publication
Ajustez votre enregistrement selon les recommandations. Une fois la syntaxe propre, publiez le TXT à _25._tcp.<hôte-mx> dans la zone signée DNSSEC de l'hôte MX, attendez la propagation, puis confirmez en direct avec le DANE TLSA Checker.
Validateur ou vérificateur : quand utiliser chaque outil
Les deux outils sont complémentaires. Ils interviennent à des moments différents du cycle de vie d'un enregistrement TLSA.
| Dimension | Validateur (cet outil) | Vérificateur |
|---|---|---|
| Moment d'utilisation | Avant publication DNS | Après publication |
| Résolution DNS | Aucune | Résolution _25._tcp.<mx> en direct |
| Vérification DNSSEC | Non | Oui, chaîne complète |
| Comparaison du certificat en direct | Non | Oui, via STARTTLS sur port 25 |
| Source de l'enregistrement | Manuelle (collée) | DNS public |
| Données envoyées au serveur | Aucune | Domaine analysé |
Flux de travail recommandé :
- Concevez ou générez l'enregistrement, puis utilisez le validateur pour vérifier la syntaxe
- Publiez le TXT dans la zone DNSSEC de l'hôte MX, puis attendez la propagation
- Lancez le vérificateur pour confirmer DNSSEC et la correspondance du certificat en direct
Le validateur détecte les erreurs de saisie avant publication. Le vérificateur détecte les dérives et confirme que le DNS public servi correspond au certificat actuellement présenté en STARTTLS.
Anatomie d'un enregistrement TLSA
L'enregistrement TLSA contient quatre champs strictement spécifiés.
Structure générale
_25._tcp.mail.captaindns.com. IN TLSA <usage> <sélecteur> <correspondance> <donnée>
| Champ | Valeurs | Description |
|---|---|---|
| Usage | 0-3 | Ancrage de confiance |
| Sélecteur | 0-1 | Partie du certificat hachée |
| Type de correspondance | 0-2 | Algorithme de comparaison |
| Donnée | hex | Hash ou bloc binaire |
Usage (champ 1)
| Valeur | Nom | Description |
|---|---|---|
| 0 | PKIX-TA | Contrainte CA : le certificat doit être signé par cette CA ET passer la validation PKIX |
| 1 | PKIX-EE | Contrainte certificat : correspondance exacte + validation PKIX |
| 2 | DANE-TA | Ancrage de confiance : tout certificat signé par cette CA est accepté |
| 3 | DANE-EE | Certificat domaine : correspondance exacte, sans validation PKIX |
Recommandation pour SMTP : DANE-EE (3). L'ancrage est dans votre clé, indépendamment de toute autorité externe.
Sélecteur (champ 2)
| Valeur | Nom | Description |
|---|---|---|
| 0 | Cert | Certificat complet (DER) |
| 1 | SPKI | SubjectPublicKeyInfo (clé publique uniquement) |
Recommandation : SPKI (1). L'enregistrement reste valide tant que la clé publique est conservée, indépendamment des renouvellements de certificat.
Type de correspondance (champ 3)
| Valeur | Nom | Longueur hex attendue |
|---|---|---|
| 0 | Full | Variable (certificat ou clé brute) |
| 1 | SHA-256 | 64 caractères (32 octets) |
| 2 | SHA-512 | 128 caractères (64 octets) |
Recommandation : SHA-256 (1). Universellement supporté, suffisamment robuste, compact.
La combinaison recommandée pour SMTP
3 1 1 est le standard de fait pour SMTP DANE.
3 1 1 <sha256-de-la-spki>
- Usage 3 (DANE-EE) : pas de dépendance à une CA, ancrage direct dans votre clé
- Sélecteur 1 (SPKI) : invariant face au renouvellement de certificat tant que la clé est conservée
- Type de correspondance 1 (SHA-256) : 32 octets, parfaitement adapté
Les autres combinaisons sont possibles mais déconseillées :
| Combinaison | Statut | Pourquoi |
|---|---|---|
| 3 1 1 | Recommandée | Standard SMTP, robuste, invariant aux renouvellements |
| 3 0 1 | Tolérée | Hash sur le certificat complet, change à chaque renouvellement |
| 2 0 1 | Acceptable | DANE-TA sur CA, pas de mise à jour DNS au renouvellement |
| 2 1 1 | Acceptable | DANE-TA sur SPKI de la CA |
| 3 1 0 | Refusée | Type de correspondance 0 expose le certificat brut, taille DNS énorme |
| 1 x x | Refusée en SMTP | PKIX-EE rarement déployable côté MTA |
| 0 x x | Refusée en SMTP | PKIX-TA inadapté à SMTP |
Le validateur signale explicitement les combinaisons hors recommandation et propose la combinaison standard.
Erreurs de syntaxe courantes et corrections
Usage hors plage
Cause : valeur usage supérieure à 3.
Correction :
- 4 1 1 2bb183af...
+ 3 1 1 2bb183af...
Sélecteur invalide
Cause : sélecteur différent de 0 ou 1.
Correction :
- 3 2 1 2bb183af...
+ 3 1 1 2bb183af...
Type de correspondance hors plage
Cause : type de correspondance supérieur à 2.
Correction :
- 3 1 3 2bb183af...
+ 3 1 1 2bb183af...
Donnée hexadécimale invalide
Cause : caractères hors plage hexadécimale (0-9, a-f, A-F).
Correction :
- 3 1 1 2bg183zf...
+ 3 1 1 2bb183af...
Longueur de hash incorrecte
Cause : la longueur de la donnée ne correspond pas au type de correspondance.
Correction SHA-256 :
- 3 1 1 2bb183
+ 3 1 1 2bb183af2e2b295b444c1fd4072f2b59a8c1c9abf7f3f1e9b0d4c7e8f1a2b3c4
SHA-256 (type de correspondance 1) exige exactement 64 caractères hexadécimaux. SHA-512 (type de correspondance 2) exige exactement 128 caractères.
Combinaison usage/sélecteur fragile
Cause : DANE-EE (3) + Cert complet (0) entraîne un hash qui change à chaque renouvellement de certificat.
Correction recommandée : passer en SPKI (1) pour rendre l'enregistrement invariant aux renouvellements (avec l'option --reuse-key côté ACME).
- 3 0 1 <hash-du-certificat-complet>
+ 3 1 1 <hash-de-la-cle-publique>
Nom du propriétaire incorrect
Cause : enregistrement publié sur l'apex du domaine au lieu de l'hôte MX, ou sur le mauvais port.
Correction : _25._tcp.<hôte-mx> exactement. Pour un MX mail.captaindns.com, c'est _25._tcp.mail.captaindns.com.
Préparer une rotation de clé
Plusieurs enregistrements TLSA dans la même zone ne sont pas une erreur : c'est même le schéma recommandé pour une rotation de clé sans interruption.
Procédure de rotation propre
- J-7 : générez la prochaine clé, calculez son hash SPKI, publiez-le en double :
_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>
-
J-0 : effectuez la rotation de certificat avec la nouvelle clé. Les MTA conformes acceptent la connexion si au moins un des deux enregistrements correspond au certificat présenté.
-
J+7 (ou 2 fois le TTL) : supprimez l'ancien enregistrement. La rotation est terminée.
Ce que vérifie le validateur
Le validateur traite chaque enregistrement indépendamment et confirme que :
- Chaque hash respecte la longueur attendue par son type de correspondance
- Aucun champ ne sort des plages valides
- Les combinaisons restent dans les recommandations
Un enregistrement en double n'est jamais signalé comme une erreur quand les deux sont syntaxiquement corrects.
DANE et MTA-STS : approches complémentaires
| Critère | DANE | MTA-STS |
|---|---|---|
| Mécanisme | DNSSEC + enregistrement TLSA | HTTPS + politique texte |
| Dépendance | DNSSEC requis | HTTPS requis |
| Confiance | Cryptographique (DNS signé) | PKI (CA HTTPS) |
| Support Postfix / Exim | Excellent | Bon |
| Support Microsoft 365 / Google Workspace | Partiel à inexistant | Complet |
| Déploiement | Complexe (DNSSEC) | Plus simple |
Recommandation : ne choisissez pas, déployez les deux. Validez votre enregistrement TLSA ici, puis publiez aussi une politique MTA-STS. La couverture maximale impose la combinaison.
Outils complémentaires et ressources
| Outil | Quand l'utiliser |
|---|---|
| DANE TLSA Checker | Audit en direct de l'enregistrement publié dans le DNS, avec validation DNSSEC et correspondance du certificat |
| Générateur DANE TLSA | Créer un enregistrement TLSA à partir d'un certificat ou d'une clé publique |
| Validateur syntaxe MTA-STS | Valider la politique MTA-STS associée hors ligne |
| Validateur syntaxe TLS-RPT | Valider l'enregistrement TLS-RPT associé hors ligne |
| Audit email-authentication | Vue d'ensemble des outils d'authentification email |
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 DANE entrant et sortant sur Exchange Online.
- DANE TLSA, dépannage : 12 cas pratiques - 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)