Interactions avec le DNS

Le DNS (domain name system) est le mécanisme distribué de nommage dans l'Internet. Le protocole SMTP est bien sûr dépendant du DNS, comme tout protocole utilisant des noms de sites. Mais le DNS comprend une caractéristique conçue spécialement pour le courrier électronique : les resource records (RR) de type MX (pour Mail eXchanger).

Un RR de type MX associé à un site S a pour but d'indiquer aux sites qui voudraient envoyer un courrier à S de ne pas lui envoyer directement, mais de l'envoyer à une autre machine citée dans le MX.

Par exemple :

cezanne.prism.uvsq.fr IN MX 10 soleil.uvsq.fr

Ce MX indique que tout courrier adressé à cezanne doit être en réalité envoyé à soleil. Toute implémentation de SMTP conforme doit obéir à ce MX.

Dans la pratique, à quoi sert un MX ?

• à router un message pour un site n'ayant pas de connectivité Internet. Par exemple :

  frmug.fr.net IN MX 10 soleil.uvsq.fr

  a pour effet de demander à tous les sites de l'Internet de router les courriers à envoyer à frmug vers soleil. Dans cet exemple (obsolète), frmug n'était pas sur l'Internet, mais disposait d'une connexion UUCP avec soleil, et était donc un site situé à la bordure de l'Internet (voir section 1.2.2).

• à recevoir les courriers adressés à un domaine. Par exemple :

  uvsq.fr IN MX 10 soleil.uvsq.fr

  Un courrier adressé au domaine uvsq.fr est en réalité reçu par soleil, ce qui permet d'avoir (si soleil est bien configuré) des adresses du genre user@domaine.

• à centraliser la distribution du courrier. On peut ainsi fiabiliser la distribution en passant par une machine maintenue, administrée et disponible qui re-route les courriers à l'intérieur d'un campus. La machine qui centralise le courrier doit donc utiliser les MX pour envoyer les courriers vers l'extérieur du campus, et ne doit pas utiliser les MX à l'intérieur pour rerouter les courriers vers les différentes machines (puisque c'est cette machine centralisatrice qui est sensée être le relais).

  Par exemple, toutes les machines de l'Université de Versailles/St Quentin en Yvelines ont la définition suivante :

  cezanne.prism.uvsq.fr IN MX 10 soleil.uvsq.fr

  La machine soleil.uvsq.fr devant transmettre les courriers destinés à l'intérieur de l'Université, elle ne doit surtout pas utiliser les MX sur le campus. En revanche, lorsqu'il s'agit d'envoyer un message à l'extérieur, elle doit bien sûr les consulter.

  Ce rôle centralisateur peut être renforcé, pour accroître la sécurité, par des filtres sur le routeur d'entrée de l'organisation.

• à re-router les courriers en cas de problème. Par exemple :

  jussieu.fr IN MX 10 shiva.jussieu.fr

  jussieu.fr IN MX 20 soleil.uvsq.fr

  Les MX sont triés par priorité. Plus le nombre est proche de 0, plus forte est la priorité. Lorsqu'un site Internet essaye d'envoyer un courrier à jussieu.fr, il tente d'abord de l'envoyer à shiva. Si ce n'est pas possible, par exemple si le campus de Jussieu est coupé du monde extérieur par suite d'un dysfonctionnement du réseau, le site essayera de l'envoyer à soleil.

  L'intérêt d'une telle manipulation peut paraître réduit : en effet, le protocole SMTP garantit que si un site n'est pas joignable, le message est mis en file d'attente. Mais si, au bout d'une journée, le campus de Jussieu redevient accessible, plusieurs milliers de machines essayeront de se connecter au serveur SMTP de shiva sur une très courte durée, ce qui se passera forcément très mal. Un « MX de secours » permet d'alléger cette reprise. Si shiva est indisponible, les courriers sont envoyés à soleil pendant toute la durée de la coupure. Lorsque shiva redevient disponible, elle n'aura à supporter qu'une seule connexion, ce qui est tout à fait raisonnable.

  Il y a cependant quelques inconvénients à une telle démarche :

  • les courriers peuvent transiter par un site tiers en cas de panne, ce qui peut amener des problèmes de confidentialité si le site tiers n'est pas sûr ;
  • si l'attente devient longue, la charge du site de secours peut s'alourdir.

  Malgré ces inconvénients, le fait d'avoir un site de secours est une bonne pratique. Attention toutefois : une telle opération ne peut se faire qu'avec l'accord de l'administrateur du site concerné.

  Dans l'exemple ci-dessus, nous n'avons pas décrit commnt la machine soleil.uvsq.fr traite les courriers reçus pour Jussieu. Par défaut, le programme sendmailles met en file d'attente, en attendant que shiva soit à nouveau disponible. Une pratique plus astucieuse est décrite en 3.6.10 (page ).

La RFC 974 définit le traitement des MX. Lorsqu'une machine A essaye d'envoyer un courrier à une autre machine B, elle interroge le DNS et récupère en retour une liste de MX.

• si la liste est vide, A ouvre une connexion directe avec B ;

• sinon, la liste est triée suivant les priorités ;

• si A figure dans la liste, toutes les autres machines de même priorité ainsi que les machines moins prioritaires sont retirées de la liste ;

• si la liste est maintenant vide, il s'agit d'une erreur (A est considérée comme étant un routeur pour B, mais A ne sait pas router spécialement les messages pour B) ;

• sinon, A essaye d'ouvrir une connexion directe avec les sites de la liste, en partant du plus prioritaire.

Plusieurs erreurs doivent être évitées lorsqu'on utilise des MX :

• un MX doit pointer sur un nom canonique. En particulier, un MX ne doit pas pointer sur un autre MX, ou sur un CNAME (alias). Le dernier cas est géré correctement par la version 8 de sendmail, mais un cas particulier n'est pas le cas général sur l'Internet ;

• une machine agissant comme routeur de courrier pour un domaine doit être capable de gérer les courriers dans son domaine sans tenir compte des MX ;

• il existe un cas spécial, appelé wildcard MX. Par exemple :

  *.frmug.fr.net IN MX 10 soleil.uvsq.fr

  Ce dispositif permet de re-router les messages adressés à toto.frmug.fr.net sans que la machine toto soit déclarée dans le DNS à l'intérieur du domaine frmug.fr.net. Les règles de gestion des wildcard MX ne sont pas toujours comprises (en particulier, ces MX ne s'appliquent qu'aux sites qui n'ont pas d'autre RR dans la zone correspondante). La seule règle importante est qu'il ne faut surtout pas les utiliser, sauf pour rendre visible au niveau courrier tout un domaine non connecté à l'Internet et non enregistré dans le DNS.

Enfin, une recommandation utile. Qu'on utilise les MX ou non, une bonne pratique est d'avoir un MX sur chaque machine. Par exemple :

soleil.uvsq.fr IN MX 0 soleil.uvsq.fr

Le but est de minimiser les requêtes au DNS. Pour comprendre l'intérêt, supposons qu'il n'y ait pas de MX. Une machine voulant envoyer un message à soleil procéderait en deux étapes : interrogation du DNS pour obtenir le MX, conduisant à un échec, puis à nouveau interrogation du DNS pour trouver le RR de type A (c'est-à-dire l'adresse IP). Dans ce cas, on voit qu'il y a deux recherches coûteuses.

Si maintenant, on met un MX comme spécifié ci-dessus, la première requête donnerait une réponse, enrichie avec des informations additionnelles telles que le ou les RR de type A correspondant (dans la partie « informations complémentaires » de la réponse). Dans ce cas, il n'y a plus qu'une seule recherche.