Fonctionnement de l’authentification BASÉE sur DNS SMTP des entités nommées (DANE)

Article
08/12/2023

Le protocole SMTP est le protocole main utilisé pour transférer des messages entre les serveurs de messagerie et n’est pas sécurisé par défaut. Le protocole TLS (Transport Layer Security) a été introduit il y a des années pour prendre en charge la transmission chiffrée de messages via SMTP. Il est couramment utilisé de manière opportuniste plutôt que comme une exigence, laissant une grande partie du trafic d’e-mails en texte clair, vulnérable à l’interception par des acteurs malveillants. En outre, SMTP détermine les adresses IP des serveurs de destination via l’infrastructure DNS publique, qui est susceptible d’usurpation d’identité et d’attaques mitm (Man-in-the-Middle). Cette vulnérabilité a conduit à la création de nombreuses nouvelles normes pour renforcer la sécurité de l’envoi et de la réception des e-mails, l’une de ces normes étant l’authentification dns des entités nommées (DANE).

DANE pour SMTP RFC 7672 utilise la présence d’un enregistrement TLSA (Transport Layer Security Authentication) dans le jeu d’enregistrements DNS d’un domaine pour signaler un domaine et ses serveurs de messagerie prennent en charge DANE. Si aucun enregistrement TLSA n’est présent, la résolution DNS pour le flux de courrier fonctionne comme d’habitude sans aucune tentative de vérification DANE. L’enregistrement TLSA signale en toute sécurité la prise en charge tls et publie la stratégie DANE pour le domaine. Par conséquent, l’envoi de serveurs de messagerie peut correctement authentifier les serveurs de messagerie de réception légitimes à l’aide du DANE SMTP. Cette authentification le rend résistant aux attaques de rétrogradation et MITM. DANE a des dépendances directes sur DNSSEC, qui fonctionne en signant numériquement des enregistrements pour les recherches DNS à l’aide du chiffrement à clé publique. Les vérifications DNSSEC se produisent sur les programmes de résolution DNS récursifs, les serveurs DNS qui effectuent des requêtes DNS pour les clients. DNSSEC garantit que les enregistrements DNS ne sont pas falsifiés et qu’ils sont authentiques.

Une fois que les enregistrements de ressources MX, A/AAAA et DNSSEC d’un domaine sont retournés au programme de résolution récursif DNS en tant qu’authentique DNSSEC, le serveur de messagerie émettrice demande l’enregistrement TLSA correspondant à l’entrée ou aux entrées de l’hôte MX. Si l’enregistrement TLSA est présent et s’il est prouvé qu’il est authentique à l’aide d’un autre case activée DNSSEC, le programme de résolution récursif DNS renvoie l’enregistrement TLSA au serveur de messagerie d’envoi.

Une fois l’enregistrement TLSA authentique reçu, le serveur de messagerie d’envoi établit une connexion SMTP à l’hôte MX associé à l’enregistrement TLSA authentique. Le serveur de messagerie d’envoi tente de configurer TLS et de comparer le certificat TLS du serveur avec les données de l’enregistrement TLSA pour vérifier que le serveur de messagerie de destination connecté à l’expéditeur est le serveur de messagerie de réception légitime. Le message est transmis (à l’aide de TLS) si l’authentification réussit. En cas d’échec de l’authentification ou si TLS n’est pas pris en charge par le serveur de destination, Exchange Online réessayez tout le processus de validation en commençant par une requête DNS pour le même domaine de destination au bout de 15 minutes, puis 15 minutes après, puis toutes les heures pendant les 24 heures suivantes. Si l’authentification continue d’échouer après 24 heures de nouvelle tentative, le message expire et une remise avec les détails de l’erreur est générée et envoyée à l’expéditeur.

Conseil

Si vous n’êtes pas un client E5, utilisez la version d’évaluation de 90 jours des solutions Microsoft Purview pour découvrir comment des fonctionnalités Supplémentaires purview peuvent aider vos organization à gérer les besoins en matière de sécurité et de conformité des données. Commencez dès maintenant au hub d’essais portail de conformité Microsoft Purview. En savoir plus sur les conditions d’inscription et d’essai.

Quels sont les composants de DANE ?

Enregistrement de ressource TLSA

L’enregistrement TLSA (Tls Authentication) est utilisé pour associer le certificat X.509 ou la valeur de clé publique d’un serveur au nom de domaine qui contient l’enregistrement. Les enregistrements TLSA ne peuvent être approuvés que si DNSSEC est activé sur votre domaine. Si vous utilisez un fournisseur DNS pour héberger votre domaine, le DNSSEC peut être un paramètre proposé lors de la configuration d’un domaine avec celui-ci. Pour en savoir plus sur la signature de zone DNSSEC, visitez ce lien : Vue d’ensemble de DNSSEC | Microsoft Docs.

Exemple d’enregistrement TLSA :

Il existe quatre champs configurables propres au type d’enregistrement TLSA :

Champ d’utilisation du certificat : spécifie comment le serveur de messagerie émettrice doit vérifier le certificat du serveur de messagerie de destination.

Valeur	Acronyme	Description
0¹	PKIX-TA	Le certificat utilisé est l’autorité de certification publique d’ancre de confiance de la chaîne d’approbation X.509.
1¹	PKIX-EE	Le certificat vérifié est le serveur de destination ; Les vérifications DNSSEC doivent vérifier son authenticité.
2	DANE-TA	Utilisez la clé privée du serveur de l’arborescence X.509 qui doit être validée par une ancre d’approbation dans la chaîne d’approbation. L’enregistrement TLSA spécifie l’ancre d’approbation à utiliser pour valider les certificats TLS pour le domaine.
3	DANE-EE	Correspondent uniquement au certificat du serveur de destination.

¹ Exchange Online suit les instructions d’implémentation de RFC qui indiquent que les valeurs de champ d’utilisation du certificat de 0 ou 1 ne doivent pas être utilisées lorsque DANE est implémenté avec SMTP. Lorsqu’un enregistrement TLSA dont la valeur de champ Utilisation du certificat est 0 ou 1 est retourné à Exchange Online, Exchange Online le traitera comme non utilisable. Si tous les enregistrements TLSA sont jugés inutilisables, Exchange Online n’effectuez pas les étapes de validation DANE pour 0 ou 1 lors de l’envoi de l’e-mail. Au lieu de cela, en raison de la présence d’un enregistrement TLSA, Exchange Online applique l’utilisation de TLS pour l’envoi de l’e-mail, l’envoi de l’e-mail si le serveur de messagerie de destination prend en charge TLS ou la suppression de l’e-mail et la génération d’une notification d’échec de remise si le serveur de messagerie de destination ne prend pas en charge TLS.

Dans l’exemple d’enregistrement TLSA, le champ Utilisation du certificat est défini sur « 3 », de sorte que les données d’association de certificats (« abc123... xyz789') serait mis en correspondance avec le certificat du serveur de destination uniquement.

Champ sélecteur : indique les parties du certificat du serveur de destination qui doivent être vérifiées.

Valeur	Acronyme	Description
0	Cert	Utilisez le certificat complet.
1	SPKI (Informations sur la clé publique de l’objet)	Utilisez la clé publique du certificat et l’algorithme avec lequel la clé publique est identifiée pour utiliser.

Dans l’exemple d’enregistrement TLSA, le champ de sélection est défini sur « 1 » afin que les données d’association de certificats soient mises en correspondance à l’aide de la clé publique du certificat du serveur de destination et de l’algorithme avec lequel la clé publique est identifiée pour utiliser.

Champ type correspondant : indique le format que le certificat sera représenté dans l’enregistrement TLSA.

Valeur	Acronyme	Description
0	Complet	Les données de l’enregistrement TSLA sont le certificat complet ou SPKI.
1	SHA-256	Les données de l’enregistrement TSLA sont un hachage SHA-256 du certificat ou du SPKI.
2	SHA-512	Les données de l’enregistrement TSLA sont un hachage SHA-512 du certificat ou du SPKI.

Dans l’exemple d’enregistrement TLSA, le champ Type correspondant est défini sur « 1 », de sorte que les données d’association de certificats sont un hachage SHA-256 des informations de clé publique de l’objet à partir du certificat du serveur de destination

Données d’association de certificats : spécifie les données de certificat utilisées pour la correspondance avec le certificat du serveur de destination. Ces données dépendent de la valeur du champ sélecteur et de la valeur du type correspondant.

Dans l’exemple d’enregistrement TLSA, les données d’association de certificats sont définies sur abc123. xyz789'. Étant donné que la valeur du champ sélecteur dans l’exemple est définie sur « 1 », elle fait référence à la clé publique du certificat du serveur de destination et à l’algorithme identifié pour être utilisé avec celui-ci. Et comme la valeur du champ Type correspondant dans l’exemple est définie sur « 1 », elle fait référence au hachage SHA-256 des informations de clé publique de l’objet à partir du certificat du serveur de destination.

Comment Exchange Online clients peuvent-ils utiliser smtp DANE Outbound ?

En tant que client Exchange Online, vous n’avez rien à faire pour configurer cette sécurité de messagerie améliorée pour votre courrier sortant. Cette sécurité améliorée de la messagerie est quelque chose que nous avons conçu pour vous et elle est ACTIVÉE par défaut pour tous les clients Exchange Online et est utilisée lorsque le domaine de destination annonce la prise en charge de DANE. Pour tirer parti des avantages de l’envoi d’e-mails avec des vérifications DNSSEC et DANE, communiquez à vos partenaires commerciaux avec lesquels vous échangez des e-mails qu’ils doivent implémenter DNSSEC et DANE afin qu’ils puissent recevoir des e-mails en utilisant ces normes.

Comment Exchange Online clients peuvent-ils utiliser smtp DANE entrant ?

Actuellement, le DANE SMTP entrant n’est pas pris en charge pour Exchange Online. La prise en charge du DANE SMTP entrant sera disponible dans un avenir proche.

Quelle est la configuration d’enregistrement TLSA recommandée ?

Selon les conseils d’implémentation RFC pour SMTP DANE, un enregistrement TLSA composé du champ Utilisation du certificat défini sur 3, du champ Sélecteur défini sur 1 et du champ Type de correspondance défini sur 1 est recommandé.

flux de messagerie Exchange Online avec DANE SMTP

Le processus de flux de messagerie pour Exchange Online avec SMTP DANE, indiqué dans l’organigramme ci-dessous, valide la sécurité des enregistrements de domaine et de ressources via DNSSEC, la prise en charge tls sur le serveur de messagerie de destination, et que le certificat du serveur de messagerie de destination correspond à ce qui est attendu en fonction de son enregistrement TLSA associé.

Il existe seulement deux scénarios dans lesquels une défaillance DANE SMTP entraîne le blocage de l’e-mail :

Le domaine de destination a signalé la prise en charge de DNSSEC, mais un ou plusieurs enregistrements ont été retournés comme inauthentiques.
Tous les enregistrements MX pour le domaine de destination ont des enregistrements TLSA et aucun des certificats du serveur de destination ne correspond à ce qui était attendu par les données d’enregistrement TSLA, ou une connexion TLS n’est pas prise en charge par le serveur de destination.

Technologie	Informations complémentaires
L’agent de transfert de courrier : strict transport security (MTA-STS) permet de contrer les attaques de rétrogradation et de man-in-the-middle en fournissant un mécanisme pour définir des stratégies de domaine qui spécifient si le serveur de messagerie de destination prend en charge TLS et ce qu’il faut faire quand TLS ne peut pas être négocié, par exemple arrêter la transmission.	Plus d’informations sur la prise en charge prochaine de Exchange Online pour les MTA-STS entrants et sortants seront publiées plus tard cette année. Exchange Online Transport News de Microsoft Ignite 2020 - Microsoft Tech Community rfc8461 (ietf.org)
Sender Policy Framework (SPF) utilise des informations IP pour s’assurer que les systèmes de messagerie de destination approuvent les messages envoyés à partir de votre domaine personnalisé.	Comment SPF (Sender Policy Framework) empêche l’usurpation d’identité
DomainKeys Identified Mail (DKIM) utilise les informations de certificat X.509 pour garantir que les systèmes de messagerie de destination approuvent les messages sortants envoyés à partir de votre domaine personnalisé.	Utiliser DKIM pour le courrier électronique dans votre domaine personnalisé
L’authentification, la création de rapports et la conformité des messages basés sur le domaine (DMARC) fonctionne avec Sender Policy Framework et DomainKeys Identified Mail pour authentifier les expéditeurs de courrier et garantir que les systèmes de messagerie de destination approuvent les messages envoyés à partir de votre domaine.	Utiliser DMARC pour valider les e-mails et les étapes de configuration

Résolution des problèmes d’envoi d’e-mails avec SMTP DANE

Actuellement, il existe quatre codes d’erreur pour DANE lors de l’envoi d’e-mails avec Exchange Online. Microsoft met activement à jour cette liste de codes d’erreur. Les erreurs sont visibles dans :

Le portail Exchange Administration Center via la vue Détails de la trace des messages.
NDRs générés lorsqu’un message n’est pas envoyé en raison d’une défaillance DANE ou DNSSEC.
Outil Analyseur de connectivité à distance Microsoft Remote Connectivity Analyzer.

Code d’échec de remise	Description
4/5.7.321	starttls-not-supported : le serveur de messagerie de destination doit prendre en charge TLS pour recevoir des messages.
4/5.7.322	certificate-expired : le certificat du serveur de messagerie de destination a expiré.
4/5.7.323	tlsa-invalid : la validation DANE du domaine a échoué.
4/5.7.324	dnssec-invalid : le domaine de destination a retourné des enregistrements DNSSEC non valides.

Remarque

Actuellement, lorsqu’un domaine signale qu’il prend en charge DNSSEC mais échoue aux vérifications DNSSEC, Exchange Online ne génère pas l’erreur dnssec-invalid 4/5.7.324. Il génère une erreur DNS générique :

4/5.4.312 DNS query failed

Nous travaillons activement pour remédier à cette limitation connue. Si vous recevez cette instruction d’erreur, accédez à Microsoft Remote Connectivity Analyzer et effectuez le test de validation DANE sur le domaine qui a généré l’erreur 4/5.4.312. Les résultats indiquent s’il s’agit d’un problème DNSSEC ou d’un autre problème DNS.

Résolution des problèmes 4/5.7.321 starttls-not-supported

Cette erreur indique généralement un problème avec le serveur de messagerie de destination. Après avoir reçu le message :

Vérifiez que l’adresse e-mail de destination a été correctement entrée.
Avertissez l’administrateur de la messagerie de destination que vous avez reçu ce code d’erreur afin qu’il puisse déterminer si le serveur de destination est configuré correctement pour recevoir des messages à l’aide du protocole TLS.
Réessayez d’envoyer l’e-mail et passez en revue les détails de la trace du message dans le portail Exchange Administration Center.

Résolution des problèmes 4/5.7.322 certificat expiré

Un certificat X.509 valide qui n’a pas expiré doit être présenté au serveur de messagerie d’envoi. Les certificats X.509 doivent être renouvelés après leur expiration, généralement tous les ans. Après avoir reçu le message :

Avertissez l’administrateur de l’e-mail de destination que vous avez reçu ce code d’erreur et fournissez la chaîne de code d’erreur.
Prévoyez le temps nécessaire au renouvellement du certificat du serveur de destination et à la mise à jour de l’enregistrement TLSA pour référencer le nouveau certificat. Ensuite, réessayez d’envoyer l’e-mail et passez en revue les détails de la trace du message dans le portail Exchange Administration Center.

Résolution des problèmes 4/5.7.323 tlsa-invalid

Ce code d’erreur est lié à une mauvaise configuration d’enregistrement TLSA et ne peut être généré qu’après qu’un enregistrement TLSA d’authentification DNSSEC a été retourné. Il existe de nombreux scénarios lors de la validation DANE qui se produisent après que l’enregistrement a été retourné, ce qui peut entraîner la génération du code. Microsoft travaille activement sur les scénarios couverts par ce code d’erreur, afin que chaque scénario ait un code spécifique. Actuellement, un ou plusieurs de ces scénarios peuvent entraîner la génération du code d’erreur :

Le certificat du serveur de messagerie de destination ne correspond pas à ce qui est attendu par l'enregistrement TLSA authentique.
L’enregistrement TLSA authentique n’est pas correctement configuré.
Le domaine de destination est attaqué.
Toute autre défaillance DANE.

Après avoir reçu le message :

Avertissez l’administrateur de l’e-mail de destination que vous avez reçu ce code d’erreur et fournissez-lui la chaîne de code d’erreur.
Laissez le temps à l’administrateur de l’e-mail de destination de vérifier sa configuration DANE et la validité du certificat de serveur de messagerie. Ensuite, réessayez d’envoyer l’e-mail et passez en revue les détails de la trace du message dans le portail Exchange Administration Center.

Résolution des problèmes 4/5.7.324 dnssec-invalid

Ce code d’erreur est généré lorsque le domaine de destination a indiqué qu’il était DNSSEC-authentic, mais Exchange Online n’a pas pu le vérifier comme DNSSEC-authentic.

Après avoir reçu le message :

Avertissez l’administrateur de l’e-mail de destination que vous avez reçu ce code d’erreur et fournissez-lui la chaîne de code d’erreur.
Laissez le temps à l’administrateur de l’e-mail de destination d’examiner la configuration DNSSEC de son domaine. Ensuite, réessayez d’envoyer l’e-mail et passez en revue les détails de la trace du message dans le portail Exchange Administration Center.

Résolution des problèmes de réception d’e-mails avec SMTP DANE

Actuellement, il existe deux méthodes qu’un administrateur d’un domaine de réception peut utiliser pour valider et dépanner sa configuration DNSSEC et DANE pour recevoir des e-mails de Exchange Online en utilisant ces normes.

Adopter SMTP TLS-RPT (Transport Layer Security Reporting) introduit dans RFC8460
Utiliser l’outil Analyseur de connectivité à distance Microsoft Remote Connectivity Analyzer

TLS-RPT https://datatracker.ietf.org/doc/html/rfc8460 est un mécanisme de création de rapports permettant aux expéditeurs de fournir des détails aux administrateurs de domaine de destination sur les réussites et échecs DANE et MTA-STS avec ces domaines de destination respectifs. Pour recevoir des rapports TLS-RPT, vous devez uniquement ajouter un enregistrement TXT dans les enregistrements DNS de votre domaine qui inclut l’adresse e-mail ou l’URI auquel vous souhaitez envoyer les rapports. Exchange Online enverront des rapports TLS-RPT au format JSON.

Exemple d’enregistrement :

La deuxième méthode consiste à utiliser l’analyseur de connectivité à distance Microsoft Remote Connectivity Analyzer, qui peut effectuer les mêmes vérifications DNSSEC et DANE par rapport à votre configuration DNS que Exchange Online fera lors de l’envoi d’e-mails en dehors du service. Cette méthode est le moyen le plus direct de résoudre les erreurs dans votre configuration pour recevoir des e-mails de Exchange Online en utilisant ces normes.

Lorsque des erreurs sont résolues, les codes d’erreur ci-dessous peuvent être générés :

Code d’échec de remise	Description
4/5.7.321	starttls-not-supported : le serveur de messagerie de destination doit prendre en charge TLS pour recevoir des messages.
4/5.7.322	certificate-expired : le certificat du serveur de messagerie de destination a expiré.
4/5.7.323	tlsa-invalid : la validation DANE du domaine a échoué.
4/5.7.324	dnssec-invalid : le domaine de destination a retourné des enregistrements DNSSEC non valides.

Remarque

4/5.4.312 DNS query failed

Résolution des problèmes 4/5.7.321 starttls-not-supported

Remarque

Ces étapes sont destinées aux administrateurs de messagerie pour résoudre les problèmes de réception d’e-mails de Exchange Online à l’aide de SMTP DANE.

Cette erreur indique généralement un problème avec le serveur de messagerie de destination. Serveur de messagerie avec lequel l’Analyseur de connectivité à distance teste la connexion. Il existe généralement deux scénarios qui génèrent ce code :

Le serveur de messagerie de destination ne prend pas du tout en charge la communication sécurisée, et une communication simple et non chiffrée doit être utilisée.
Le serveur de destination est configuré de manière incorrecte et ignore la commande STARTTLS.

Après avoir reçu le message :

Vérifiez l’adresse e-mail.
Recherchez l’adresse IP associée à l’instruction d’erreur afin de pouvoir identifier le serveur de messagerie auquel l’instruction est associée.
Vérifiez le paramètre de votre serveur de messagerie pour vous assurer qu’il est configuré pour écouter le trafic SMTP (généralement les ports 25 et 587).
Patientez quelques minutes, puis réessayez le test avec l’outil Analyseur de connectivité à distance.
Si l’échec persiste, essayez de supprimer l’enregistrement TLSA et réexécutez le test avec l’outil Analyseur de connectivité à distance.
S’il n’y a pas d’échec, ce message peut indiquer que le serveur de messagerie que vous utilisez pour recevoir des messages ne prend pas en charge STARTTLS et que vous devrez peut-être effectuer une mise à niveau vers un serveur qui le fait pour utiliser DANE.

Résolution des problèmes 4/5.7.322 certificat expiré

Remarque

Ces étapes sont destinées aux administrateurs de messagerie pour résoudre les problèmes de réception d’e-mails de Exchange Online à l’aide de SMTP DANE.

Vérifiez l’adresse IP associée à l’instruction d’erreur afin de pouvoir identifier le serveur de messagerie auquel elle est associée. Recherchez le certificat expiré sur le serveur de messagerie que vous avez identifié.
Connectez-vous au site web de votre fournisseur de certificats.
Sélectionnez le certificat expiré et suivez les instructions pour renouveler et payer le renouvellement.
Une fois que votre fournisseur a vérifié l’achat, vous pouvez télécharger un nouveau certificat.
Installez le certificat renouvelé sur le serveur de messagerie associé.
Mettez à jour l’enregistrement TLSA associé au serveur de messagerie avec les données du nouveau certificat.
Après avoir attendu un laps de temps approprié, réessayez le test avec l’outil Analyseur de connectivité à distance.

Résolution des problèmes 4/5.7.323 tlsa-invalid

Remarque

Ces étapes sont destinées aux administrateurs de messagerie pour résoudre les problèmes de réception d’e-mails de Exchange Online à l’aide de SMTP DANE.

Ce code d’erreur est lié à une mauvaise configuration d’enregistrement TLSA et ne peut être généré qu’après qu’un enregistrement TSLA d’authentification DNSSEC a été retourné. Toutefois, il existe de nombreux scénarios lors de la validation DANE qui se produisent après que l’enregistrement a été retourné et qui peuvent entraîner la génération du code. Microsoft travaille activement sur les scénarios couverts par ce code d’erreur, afin que chaque scénario ait un code spécifique. Actuellement, un ou plusieurs de ces scénarios peuvent entraîner la génération du code d’erreur :

L’enregistrement TLSA authentique n’est pas correctement configuré.
Le certificat n’est pas encore valide/configuré pour une fenêtre de temps ultérieure.
Le domaine de destination fait l’objet d’une attaque.
Toute autre défaillance DANE.

Après avoir reçu le message :

Vérifiez l’adresse IP associée à l’instruction d’erreur pour identifier le serveur de messagerie auquel elle est associée.
Identifiez l’enregistrement TLSA associé au serveur de messagerie identifié.
Vérifiez la configuration de l’enregistrement TLSA pour vous assurer qu’il indique à l’expéditeur d’effectuer les vérifications DANE préférées et que les données de certificat correctes ont été incluses dans l’enregistrement TLSA.
1. Si vous devez effectuer des mises à jour de l’enregistrement en cas de différences, attendez quelques minutes, puis réexécutez le test avec l’outil Analyseur de connectivité à distance.
Recherchez le certificat sur le serveur de messagerie identifié.
Vérifiez la fenêtre de temps pour laquelle le certificat est valide. S’il est défini pour commencer la validité à une date ultérieure, il doit être renouvelé pour la date actuelle.
1. Connectez-vous au site web de votre fournisseur de certificats.
2. Sélectionnez le certificat expiré et suivez les instructions pour renouveler et payer le renouvellement.
3. Une fois que votre fournisseur a vérifié l’achat, vous pouvez télécharger un nouveau certificat.
4. Installez le certificat renouvelé sur le serveur de messagerie associé.

Résolution des problèmes 4/5.7.324 dnssec-invalid

Remarque

Ces étapes sont destinées aux administrateurs de messagerie pour résoudre les problèmes de réception d’e-mails de Exchange Online à l’aide de SMTP DANE.

Ce code d’erreur est généré lorsque le domaine de destination a indiqué qu’il est DNSSEC-authentic, mais Exchange Online n’est pas en mesure de le vérifier comme DNSSEC-authentic. Cette section n’est pas complète pour résoudre les problèmes DNSSEC et se concentre sur les scénarios où les domaines ont précédemment passé l’authentification DNSSEC, mais pas maintenant.

Après avoir reçu le message :

Si vous utilisez un fournisseur DNS, par exemple GoDaddy, alertez votre fournisseur DNS de l’erreur afin qu’il puisse travailler sur la résolution des problèmes et la modification de la configuration.
Si vous gérez votre propre infrastructure DNSSEC, de nombreuses erreurs de configuration DNSSEC peuvent générer ce message d’erreur. Voici quelques problèmes courants à case activée si votre zone a déjà passé l’authentification DNSSEC :
1. Chaîne d’approbation rompue, lorsque la zone parente contient un ensemble d’enregistrements DS qui pointent vers un élément qui n’existe pas dans la zone enfant. Ces pointeurs par des enregistrements DS peuvent entraîner la marque de la zone enfant comme fausse en validant les programmes de résolution.
  - Résolvez en examinant les ID de clé RRSIG des domaines enfants et en veillant à ce qu’ils correspondent aux ID de clé dans les enregistrements DS publiés dans la zone parente.
2. L’enregistrement de ressource RRSIG pour le domaine n’est pas valide, il a expiré ou sa période de validité n’a pas commencé.
  - Résolvez en générant de nouvelles signatures pour le domaine à l’aide d’intervalles de temps valides.

Remarque

Ce code d’erreur est également généré si Exchange Online reçoit une réponse SERVFAIL du serveur DNS sur une requête TLSA pour le domaine de destination.

Lorsqu’un e-mail sortant est envoyé, si dnssec est activé dans le domaine de réception, nous interrogeons les enregistrements TLSA associés aux entrées MX dans le domaine. Si aucun enregistrement TLSA n’est publié, la réponse à la recherche TLSA doit être NOERROR (aucun enregistrement de type demandé pour ce domaine) ou NXDOMAIN (il n’existe aucun domaine de ce type). DNSSEC nécessite cette réponse si aucun enregistrement TLSA n’est publié ; sinon, Exchange Online interprète l’absence de réponse comme une erreur SERVFAIL. Conformément à la norme RFC 7672, une réponse SERVFAIL n’est pas fiable ; par conséquent, le domaine de destination échoue à la validation DNSSEC. Cet e-mail est ensuite reporté avec l’erreur suivante :

450 4.7.324 dnssec-invalid: Destination domain returned invalid DNSSEC records

Si l’expéditeur de l’e-mail signale la réception du message

Si vous utilisez un fournisseur DNS, par exemple, GoDaddy, alertez votre fournisseur DNS de l’erreur afin qu’il puisse résoudre les problèmes de réponse DNS. Si vous gérez votre propre infrastructure DNSSEC, il peut s’agir d’un problème avec le serveur DNS lui-même ou avec le réseau.

Forum Aux Questions

En tant que client Exchange Online, puis-je refuser d’utiliser DNSSEC et/ou DANE ?

Nous croyons fermement que DNSSEC et DANE augmenteront considérablement la position de sécurité de notre service et profiteront à tous nos clients. Nous avons travaillé avec diligence au cours de la dernière année pour réduire le risque et la gravité de l’impact potentiel de ce déploiement sur les clients Microsoft 365. Nous allons surveiller et suivre activement le déploiement pour nous assurer que l’impact négatif est réduit au fur et à mesure qu’il se déploie. Pour cette raison, les exceptions au niveau du locataire ou l’exclusion ne seront pas disponibles. Si vous rencontrez des problèmes liés à l’activation de DNSSEC et/ou DANE, les différentes méthodes d’examen des échecs indiquées dans ce document vous aideront à identifier la source de l’erreur. Dans la plupart des cas, le problème concerne la partie de destination externe et vous devez communiquer à ces partenaires commerciaux qu’ils doivent configurer correctement DNSSEC et DANE afin de recevoir des e-mails de Exchange Online en utilisant ces normes.

Quel est le lien entre DNSSEC et DANE ?

DNSSEC ajoute une couche de confiance à la résolution DNS en appliquant l’infrastructure de clé publique pour garantir que les enregistrements retournés en réponse à une requête DNS sont authentiques. DANE garantit que le serveur de messagerie de réception est le serveur de messagerie légitime et attendu pour l’enregistrement MX authentique.

Quelle est la différence entre MTA-STS et DANE pour SMTP ?

DANE et MTA-STS ont le même objectif, mais DANE requiert DNSSEC pour l’authentification DNS, tandis que MTA-STS s’appuie sur des autorités de certification.

Pourquoi le protocole TLS opportuniste n’est-il pas suffisant ?

Tls opportuniste chiffrera la communication entre deux points de terminaison si les deux acceptent de la prendre en charge. Toutefois, même si TLS chiffre la transmission, un domaine peut être usurpé lors de la résolution DNS de sorte qu’il pointe vers le point de terminaison d’un acteur malveillant au lieu du point de terminaison réel pour le domaine. Cette usurpation d’identité est une lacune dans la sécurité de la messagerie qui est résolue en implémentant MTA-STS et/ou SMTP DANE avec DNSSEC.

Pourquoi DNSSEC n’est-il pas suffisant ?

DNSSEC n’est pas entièrement résistant aux attaques de l’intercepteur et aux attaques de passage à une version antérieure (du protocole TLS au texte clair) pour les scénarios de flux de courrier. L’ajout de MTA-STS et DANE avec DNSSEC fournit une méthode de sécurité complète pour contrecarrer les attaques MITM et rétrograder.

Liens supplémentaires

Rechercher et corriger des problèmes après avoir ajouté votre domaine ou des enregistrements DNS

Vue d’ensemble de DNSSEC | Microsoft Docs

Utiliser DMARC pour valider les e-mails et les étapes de configuration - Office 365 | Microsoft Docs

Comment utiliser DKIM pour la messagerie électronique dans votre domaine personnalisé - Office 365 | Microsoft Docs

Comment SPF (Sender Policy Framework) empêche l’usurpation - Office 365 | Microsoft Docs

Exchange Online Transport News de Microsoft Ignite 2020 - Microsoft Tech Community

rfc8461 (ietf.org)

Fonctionnement de l’authentification BASÉE sur DNS SMTP des entités nommées (DANE)