Microsoft Exchange Server 2019 – Comprendre et configurer les enregistrements DNS

I. Présentation

Dans ce nouvel épisode au sujet de Microsoft Exchange Server 2019, nous allons apprendre à configurer les enregistrements DNS nécessaires au bon fonctionnement de notre serveur de messagerie Exchange. Ces enregistrements, de différents types, sont indispensables. Au-delà d'en faire la configuration, il est important de connaître l'utilité de ces enregistrements DNS.

• Cliquez ici pour regarder la vidéo sur YouTube

• Installation pas-à-pas de Microsoft Exchange 2019 sur Windows Server 2022
• Exchange 2019 : comment ajouter un nouveau domaine ?
• Désactiver les accès externes au Centre d’administration Exchange

II. Exchange : les enregistrements DNS indispensables

Pour qu'un serveur de messagerie puisse fonctionner, que ce soit un serveur Exchange ou basé sur une autre solution, il y a des prérequis à respecter au niveau des enregistrements DNS. Les types d'enregistrements DNS "MX", "A", "CNAME" ou encore "SPF" sont généralement associés.

Les enregistrements DNS vont permettre aux clients et aux autres serveurs de messagerie de localiser notre serveur Exchange et de vérifier qu'il est bien légitime pour envoyer des e-mails avec ce domaine. Par ailleurs, ces enregistrements DNS vont permettre de configurer la fonctionnalité "Autodiscover", c'est-à-dire la découverte automatique, dont l'objectif est de faciliter la configuration des clients de messagerie (par exemple, l'ajout d'une boîte aux lettres dans Outlook). Ce point sera détaillé dans un prochain article.

A. Enregistrements DNS "MX"

Tout d'abord, nous avons l'enregistrement DNS de type "MX" correspondant à "Mail Exchange" (qui n'a rien à voir avec le nom de produit Microsoft Exchange) dont l'objectif est de permettre de localiser le(s) serveur(s) de messagerie associés à un nom de domaine. Au même titre qu'un enregistrement DNS peut permettre de trouver le serveur Web qui héberge le site Internet d'une entreprise, l'enregistrement MX est spécifique aux serveurs de messagerie.

Une fois le serveur de messagerie identifié grâce à l'enregistrement MX, l'e-mail pourra être envoyé. Cela signifie que l'enregistrement MX va permettre le routage des messages. Parfois, au lieu de router les flux directement vers un serveur de messagerie, on indique à la place un service anti-spam, ce qui permet de filtrer les e-mails avant qu'ils n'arrivent jusqu'au serveur Exchange.

Dans cet enregistrement DNS "MX" on va préciser le nom de domaine, le nom FQDN du serveur de messagerie (un autre enregistrement permettra de faire le lien entre ce nom complet FQDN et l'adresse IP du serveur), ainsi qu'une priorité et une durée de vie (TTL). La priorité est utile dans les projets importants où il y a plusieurs serveurs en parallèle, afin d'assurer une redondance. Dans notre cas, il n'y a qu'un seul serveur Exchange donc la priorité n'a pas un réel intérêt, mais c'est à connaître. Le serveur avec la priorité la plus faible sera consulté en premier.

Note : l'enregistrement MX doit impérativement pointer vers un domaine, au même titre qu'un enregistrement CNAME. L'enregistrement MX doit pointer vers un domaine associé à un enregistrement A (IPv4) ou AAAA (IPv6) mais par vers un CNAME.

B. Enregistrements DNS "A" et "CNAME"

Un enregistrement DNS de type A permettra d'indiquer l'adresse IPv4 du serveur de messagerie Exchange, en associant un sous-domaine tel que "mail.domaine.fr". Ici, on reprend le même nom de domaine que celui utilisé dans l'enregistrement MX (comme vous pouvez le voir dans le tableau ci-dessus).

Quant à l'enregistrement CNAME, on l'utilisera pour créer des alias, notamment sur la partie Autodiscover ou l'accès au Webmail (OWA).

C. Enregistrements DNS "SPF"

L'enregistrement DNS de type "TXT" permet de déclarer un "SPF" pour Sender Policy Framework joue un rôle important pour sécuriser un minimum le nom de domaine public. Grâce à lui, on peut déclarer quelles sont les adresses IP (IPv4 ou IPv6) ou les noms de domaine autorisés à envoyer des e-mails pour ce nom de domaine.

Autrement dit, nous devons autoriser le serveur Exchange à envoyer des e-mails pour ce domaine et lorsqu'un serveur de messagerie recevra un e-mail avec ce domaine de messagerie, il pourra le vérifier par lui-même grâce à la lecture de l'enregistrement SPF. Ce qui donne :

600 IN TXT "v=spf1 mx ~all"

Dans l'exemple ci-dessus, le fait de se référer à "mx" permet d'autoriser le serveur visé par l'enregistrement MX de la zone DNS.

Eventuellement, nous pourrions l'ajouter explicitement comme je l'ai fais ci-dessous, mais ce n'est pas indispensable.

v=spf1 mx a:mail.domaine.fr ~all

Dans le cas où l'on a besoin d'autoriser un autre serveur externe à envoyer des e-mails pour ce nom de domaine, nous pourrons aussi l'ajouter à cet enregistrement SPF. Il y a notamment les paramètres "ip4" et ip6" qui permettent de déclarer des adresses IPv4 et IPv6 pour spécifier un hôte.

D. Enregistrements DMARC (+ DKIM)

Pour finir, nous allons évoquer les enregistrements DMARC (et la norme DKIM qui est associée) : bien qu'ils ne soient pas indispensables pour que le serveur Exchange fonctionne et que l'on puisse envoyer/recevoir des e-mails, ils ne doivent pas être ignorés. Ils jouent un rôle important pour améliorer la sécurité et la délivrabilité des e-mails, ce qui évite de finir en spam dans certains cas.

DKIM pour Domain Keys Identified Mail est une norme d'authentification qui permet d'ajouter une signature chiffrée dans l'en-tête des e-mails que vous envoyez. Les e-mails restent accessibles en clair, mais l'intérêt c'est de lutter contre l'usurpation d'identité et l'altération des messages, car on est capable de vérifier que le serveur émetteur est bien qui il prétend être.

DMARC pour Domain-based Message Authentication, Reporting, and Conformance permet d'indiquer une politique à appliquer dans le cas où une usurpation d'identité est détectée. En effet, avec DKIM (et SPF) on authentifie et vérifie l'émetteur, mais que faire dans le cas où il y a un problème ? C'est là que DMARC entre en jeu et cette politique se définit au sein du DNS.

Pour la mise en œuvre de DKIM et DMARC, ce sera abordé dans un prochain épisode. Pour en savoir, vous pouvez lire cet article qui s'applique à Office 365 mais où les concepts de DKIM et DMARC sont détaillés.

• Office 365 - Mise en place de DKIM et DMARC

III. Les enregistrements internes et externes

Un serveur de messagerie Exchange, au même titre qu'un Active Directory, s'appuie sur le DNS pour son fonctionnement. Ce serveur Exchange hébergé sur votre infrastructure (dans une DMZ) est accessible à la fois depuis l'extérieur et depuis l'intérieur de votre réseau local.

Les enregistrements DNS évoqués précédemment seront configurés sur la zone DNS publique, auprès du fournisseur que vous avez choisi au moment d'acheter votre nom de domaine. Par exemple, si l'on achète le nom de domaine "domaine.fr" chez OVHcloud, il faudra se connecter sur l'interface de gestion d'OVHcloud pour configurer la zone DNS. Ainsi, lorsqu'un hôte cherchera à localiser le serveur de messagerie pour ce domaine, il obtiendra l'adresse IP publique votre serveur Exchange.

Quand il est connecté à l'extérieur du réseau, c'est bien qu'il utilise l'adresse IP publique. Par exemple, un utilisateur connecté avec son PC au réseau d'un hôtel, ou encore un serveur de messagerie qui a besoin de contacter votre serveur pour vous transmettre un e-mail. Par contre, quand l'hôte est en interne (par exemple, l'ordinateur fixe connecté au réseau local), il doit utiliser les adresses IP locales (ici 10.10.100.211/24) pour atteindre le serveur Exchange. Sauf que ce n'est pas déclaré dans la zone DNS publique. De ce fait, il faut configurer le serveur DNS qui héberge déjà la zone DNS de l'Active Directory pour qu'il effectue la résolution avec l'adresse IP interne lorsque le client est en interne. Cela passe par la création d'une zone supplémentaire.

En résumé, les connexions en provenance de l'extérieur doivent arriver sur l'adresse IP publique et les connexions internes doivent arriver sur l'adresse IP locale, même si l'on utilise les mêmes noms de domaine. Grâce au DNS, on peut arriver à ce résultat.

IV. Configurer les zones DNS

Le domaine "florianburnel.fr" est pris à titre d'exemple.

A. La zone DNS publique pour Exchange

La zone DNS publique doit être configurée auprès du fournisseur (registrar) où le domaine a été acquis. Pour la partie Exchange, je retrouve 4 enregistrements : MX, A, CNAME et SPF correspondants à ce que j'évoquais précédemment.

En mode texte :

$TTL 3600
@ IN SOA dns104.ovh.net. tech.ovh.net. (2022111004 86400 3600 3600000 300)
  IN NS ns104.ovh.net.
  IN NS dns104.ovh.net.
  IN MX 10 mail.florianburnel.fr.
  600 IN TXT "v=spf1 mx ~all"
  autodiscover IN CNAME mail.florianburnel.fr.
  mail IN A 4.233.92.148

À partir d'une machine cliente, il est possible de vérifier la résolution de noms. On peut utiliser Resolve-DnsName en PowerShell, ou l'outil nslookup, voire même l'outil en ligne MXToolbox (qui a aussi une option pour valider votre SPF). On peut remarquer que c'est opérationnel et que l'adresse IP publique est associée à "mail.florianburnel.fr".

La résolution de noms fonctionne aussi pour l'enregistrement associé à l'Autodiscover.

Passons à la zone DNS privée.

B. La zone DNS interne pour Exchange

D'un point de vue du DNS interne, nous allons appliquer le principe du PinPoint DNS, c'est-à-dire que l'on va créer une zone "mail.domaine.fr" et une zone "autodiscover.domaine.fr" qui vont contenir un enregistrement de type A qui pointe vers l'adresse IP locale du serveur Exchange Server 2019. C'est préférable d'utiliser cette méthode plutôt que de créer la zone "domaine.fr" sinon cela oblige à maintenir la zone deux fois : en local et sur l'interface du fournisseur DNS.

Ouvrez la console DNS et créez une nouvelle zone. Un assistant s'exécute.

Nous allons créer une zone primaire "Primary zone" et elle sera stockée dans l'Active Directory ("Store the zone in Active Directory").

A l'étape suivante, on décide de répliquer cette zone auprès de tous les contrôleurs de domaine du domaine "it-connect.lan" pour unifier la résolution de noms pour cette zone.

En ce qui concerne le nom de la zone, nous allons indiquer "mail.florianburnel.fr" pour définir un enregistrement local personnalisé uniquement pour ce sous-domaine.

On poursuit en choisissant de refuser les mises à jour dynamiques ("Do not allow dynamic updates"). Puis, on finalise l'ajout de la zone.

Dans cette nouvelle zone, on ajoute un nouvel hôte via un enregistrement de type "A".

Nous n'indiquons pas de nom, car on souhaite jouer sur la résolution "mail.florianburnel.fr", et non d'un autre hôte. Pour l'adresse IP, il faut indiquer l'adresse IP privée du serveur Exchange, à savoir "10.10.100.211" dans mon cas. Ainsi, la résolution s'effectuera sur l'adresse IP interne pour cette adresse.

Répétez l'opération pour la zone Autodiscover, à savoir "autodiscover.florianburnel.fr" dans mon cas et créez le même enregistrement A. Au final, vous obtenez 2 nouvelles zones.

À partir du serveur ou d'un hôte qui utilise ce serveur comme DNS, on peut tester la résolution de noms. Cette fois-ci, c'est bien l'adresse IP "10.10.100.211" qui est renvoyée à la place de l'adresse IP publique. Cela fonctionne !

Une autre méthode basée sur le principe du "Split-Brain DNS" consiste à créer des politiques au niveau du serveur DNS. Ce n'est pas très user-friendly comme méthode si vous n'êtes pas à l'aise avec PowerShell. Vous pouvez lire ces deux articles pour approfondir le sujet :

• Tutoriel - Split-Brain DNS sur Windows Server
• Microsoft Docs - Split-Brain DNS

V. Conclusion

Nous venons de voir les grands principes des enregistrements DNS avec les serveurs de messagerie, en prenant l'exemple d'Exchange Server. Puis, nous avons également vu comment effectuer la configuration des zones DNS externes et internes.

Florian BURNEL Co-founder of IT-Connect

Ingénieur système et réseau, cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Je souhaite partager mon expérience et mes découvertes au travers de mes articles. Généraliste avec une attirance particulière pour les solutions Microsoft et le scripting. Bonne lecture.

See Full Bio