DANE Record Checker - Recherche gratuite d'enregistrements TLSA

Consultez instantanément les enregistrements TLSA de n'importe quel domaine, vérifiez votre configuration DNS DANE et contrôlez les champs relatifs à l'utilisation des certificats – gratuitement et sans inscription.
Domaine Port Protocole
Je consulte les dossiers TLSA…
Nom de la requête
-
Résumé
Chèques
Remarque : la vérification de la correspondance du hachage du certificat nécessite une négociation TLS en temps réel et n'est pas effectuée par cet outil. L'état DNSSEC est vérifié via l'indicateur AD présent dans les réponses DNS.
Recherche gratuite de DANE · aucune inscription requise

Comment utiliser l'outil de vérification des enregistrements DANE

1
Saisissez votre nom de domaine (par exemple powerdmarc.com) - sans https://
2
Définissez le port et le protocole du service à vérifier. Utilisez 25 / TCP pour les e-mails SMTP, 443 / TCP pour HTTPS
3
Cliquez sur « Check DANE » : cet outil résout vos enregistrements MX, recherche les enregistrements TLSA sur le serveur de messagerie approprié et valide toutes les valeurs des champs

Qu'est-ce que DANE ?

DANE (DNS-Based Authentication of Named Entities) est un protocole de sécurité Internet défini dans la RFC 6698 qui utilise des enregistrements TLSA signés par DNSSEC pour associer des certificats TLS à des noms de domaine. Plutôt que de s'en remettre à une autorité de certification (CA) pour garantir la validité d'un certificat, DANE permet aux propriétaires de domaines de publier le certificat attendu directement dans le DNS, sécurisé par DNSSEC.

DANE est principalement utilisé pour sécuriser la messagerie SMTP, où il empêche les pirates d'intercepter les e-mails en transit à l'aide de certificats frauduleux. Il permet également de sécuriser les protocoles HTTPS, XMPP, SIP et tout autre protocole basé sur TLS.

Ancrage de certificats via le DNS
Publie l'empreinte digitale attendue du certificat dans le DNS afin que les clients qui se connectent puissent la vérifier indépendamment des autorités de certification.
Prévention des attaques de type MITM
Empêche les attaques de type « homme au milieu » en rendant impossible l'interception des connexions à l'aide de certificats frauduleux.
Envoi sécurisé d'e-mails via SMTP
Garantit que les serveurs de réception présentent exactement le certificat TLS attendu, assurant ainsi la transmission cryptée des e-mails.
Prévention des attaques par rétrogradation
Empêche les pirates de contraindre les serveurs de messagerie à utiliser un chiffrement en clair ou un chiffrement moins sûr lors de la négociation SMTP.

Comment fonctionne DANE ?

DANE fonctionne en publiant dans le DNS un enregistrement TLSA qui décrit le certificat TLS attendu pour un service. Lorsqu'un client se connecte, il récupère l'enregistrement TLSA via DNSSEC et le compare au certificat présenté lors de la négociation TLS.

1
Publier l'enregistrement TLSA - Le propriétaire du domaine crée un enregistrement TLSA à l'adresse _port._protocol.domain avec les paramètres de certificat attendus
2
Recherche DNS validée par DNSSEC - Le client qui se connecte effectue une requête validée par DNSSEC afin de récupérer et d'authentifier l'enregistrement TLSA
3
Comparaison de la négociation TLS - Le certificat présenté est comparé aux données d'association de certificats de l'enregistrement TLSA
4
Accepter ou refuser - Si le certificat correspond, la connexion est établie ; dans le cas contraire, elle est refusée afin d'éviter toute utilisation abusive

Qu'est-ce qu'un enregistrement TLSA ?

Un enregistrement TLSA est le type d'enregistrement DNS utilisé par DANE. Il stocke une empreinte de certificat TLS (ou le certificat complet) sous un nom DNS spécifique associé à un port et à un protocole, de sorte que tout client qui se connecte puisse le récupérer et le vérifier via DNSSEC avant de finaliser la négociation TLS.

Les enregistrements TLSA respectent la convention de nommage suivante :

_[port]._[protocol].[hostname] → e.g. _25._tcp.mail.example.com. IN TLSA 3 1 1 ab12cd34…

Pour le protocole SMTP, l'enregistrement TLSA se trouve sur le nom d'hôte MX, et non sur le domaine racine. C'est pourquoi cet outil résout automatiquement les enregistrements MX de votre domaine en premier lieu, puis vérifie le TLSA sur l'hôte approprié.

Comprendre les champs d'enregistrement TLSA

Un album comme 3 1 1 <hash> c'est-à-dire DANE-EE, SubjectPublicKeyInfo, SHA-256 — la configuration la plus couramment recommandée pour SMTP DANE.

Champ Valeurs Signification
Utilisation du certificat 0 = PKIX-TA · 1 = PKIX-EE · 2 = DANE-TA · 3 = DANE-EE Quel certificat de la chaîne doit être vérifié, et si une validation PKIX CA est également requise
Sélecteur 0 = Certificat complet · 1 = SubjectPublicKeyInfo S'il faut vérifier l'intégralité du certificat ou uniquement la clé publique
Type de correspondance 0 = Exact · 1 = SHA-256 · 2 = SHA-512 Comment les données du certificat sont-elles encodées dans l'enregistrement ?
Données du certificat Hachage codé en hexadécimal ou octets du certificat complet L'empreinte digitale ou le certificat à comparer avec ce que le serveur fournit

Problèmes courants liés à la configuration DNS DANE

La plupart des échecs DANE sont dus à quelques erreurs de configuration récurrentes. Voici les éléments à vérifier lorsque la vérification de votre enregistrement DANE donne des résultats inattendus.

Problème Cause Impact
Aucun enregistrement TLSA trouvé Le DANE n'a pas été publié pour ce port/protocole, ou a été vérifié sur un nom d'hôte incorrect Le DANE ne peut pas être imposé ; les connexions reposent uniquement sur la confiance accordée à l'autorité de certification
DNSSEC n'est pas activé Les enregistrements TLSA ne disposant pas de DNSSEC peuvent faire l'objet d'une usurpation d'identité pendant leur transit Les clients DANE rejettent ou ignorent complètement l'enregistrement TLSA
Incompatibilité de certificat après le renouvellement Le certificat TLS a été renouvelé, mais l'enregistrement TLSA n'a pas été mis à jour en conséquence Connexions légitimes rejetées ; échec de la distribution du courrier
Utilisation incorrecte / Sélecteur / Champs de correspondance Valeurs de champs hors limites ou non prises en charge dans l'enregistrement TLSA La validation échoue systématiquement, même lorsque le certificat est valide
Enregistrement de transfert manquant Un seul enregistrement TLSA publié pendant la transition de certificat Interruption de service si l'ancienne entrée est supprimée avant que le DNS n'ait propagé la nouvelle

Bonnes pratiques pour les enregistrements DANE

Publier les enregistrements TLSA de transfert
Veillez à toujours préparer un deuxième enregistrement TLSA pour votre prochain certificat avant de procéder au renouvellement, afin d'éviter tout problème de livraison.
Activez d'abord le protocole DNSSEC
DANE ne fonctionne que lorsque le protocole DNSSEC est activé. Ne publiez vos enregistrements TLSA qu'une fois que vous vous êtes assuré que le protocole DNSSEC fonctionne correctement.
Mettre à jour le TLSA avant le renouvellement du certificat
Ajoutez le nouvel enregistrement TLSA au DNS avant de renouveler le certificat afin que la propagation soit effective à temps.
Surveiller en permanence les enregistrements TLSA
Détectez automatiquement les incohérences entre les certificats et les TLSA avant qu'elles n'entraînent des échecs de livraison des e-mails.

Foire aux questions

Un enregistrement TLSA est un type d'enregistrement DNS (type 52) utilisé par DANE pour associer un certificat TLS ou une clé publique à un domaine, un port et un protocole spécifiques. Il stocke une empreinte de certificat sécurisée par DNSSEC, ce qui permet aux clients qui se connectent de vérifier le certificat lors de la négociation TLS sans avoir recours à une autorité de certification.

DANE (DNS-Based Authentication of Named Entities) est un protocole de sécurité qui publie les informations relatives aux certificats TLS directement dans le DNS à l'aide d'enregistrements TLSA, protégés par le protocole DNSSEC. Il supprime la dépendance vis-à-vis des autorités de certification tierces en permettant aux propriétaires de domaines de spécifier précisément quel certificat doit être considéré comme fiable pour leurs services.

Pour la transmission de courriels via SMTP entre serveurs de messagerie, utilisez le port 25 avec TCP. L'enregistrement TLSA est publié à l'adresse _25._tcp.[mx-hostname]. Notez que pour la messagerie électronique, les enregistrements TLSA doivent être associés au nom d'hôte MX — et non au domaine racine. Utilisez le port 443 / TCP pour le protocole HTTPS.

Oui, et c'est recommandé. DANE impose l'utilisation du protocole TLS à l'aide de certificats fixés par DNSSEC, tandis queMTA-STSimpose le protocole TLS via une politique hébergée sur HTTPS. L'utilisation conjointe de ces deux protocoles optimise la couverture : DANE protège contre les autorités de certification malveillantes, tandis que MTA-STS couvre les serveurs émetteurs qui ne prennent pas en charge DANE.

Oui — le protocole DNSSEC est une condition indispensable pour le DANE. Sans DNSSEC, n'importe qui pourrait publier un faux enregistrement TLSA renvoyant vers un certificat malveillant, ce qui rendrait toute la procédure de validation inutile. Le protocole DNSSEC signe cryptographiquement vos enregistrements DNS afin que les résolveurs puissent vérifier qu'ils n'ont pas été altérés.

DANE-TA (Trust Anchor, utilisation 2) correspond à un certificat d'autorité de certification intermédiaire ou racine : tout certificat signé par cette autorité de certification sera validé. DANE-EE (End Entity, utilisation 3) correspond directement au certificat ou à la clé publique du serveur lui-même. Pour SMTP, l'utilisation 3 avec le sélecteur 1 (clé publique) et le type de correspondance 1 (SHA-256) est la configuration recommandée selon la RFC 7672.

Surveillez vos enregistrements DANE et la sécurité de vos e-mails 24 heures sur 24, 7 jours sur 7


PowerDMARC surveille automatiquement vos enregistrements TLSA, l'état DNSSEC et vos certificats TLS, et vous alerte dès qu'un problème survient ou qu'un élément arrive à expiration.