Les RFC qui spécifient comment un MTA doit gérer les enregistrements MX sont RFC974 , RFC1123 section 5.3.4 , RFC2821 section 5 et RFC5321 section 5 .
Le statut RFC974 est désormais HISTORIQUE . Selon lui, les MTA devraient interroger la liste des enregistrements MX associés à un domaine et sont "encouragés" à essayer tous (ou un nombre fixe de) serveurs SMTP, par ordre croissant de préférence. S'il existe plusieurs enregistrements MX avec une valeur de préférence égale, les MTA doivent essayer de remettre le message à tous les serveurs SMTP jusqu'à ce qu'un réussisse. L'ordre des tentatives est le choix d'un MTA, c'est-à-dire que le RFC ne règle pas si les serveurs SMTP doivent être contactés au hasard ou dans l'ordre donné par le serveur DNS. En outre, le RFC ne règle pas la façon de gérer un registre MX qui référence plusieurs enregistrements A.
(...) If the list of MX RRs is not empty, the mailer should try to deliver
the message to the MXs in order (lowest preference value tried
first). The mailer is required to attempt delivery to the lowest
valued MX. Implementors are encouraged to write mailers so that they
try the MXs in order until one of the MXs accepts the message, or all
the MXs have been tried. A somewhat less demanding system, in which
a fixed number of MXs is tried, is also reasonable. Note that
multiple MXs may have the same preference value. In this case, all
MXs at with a given value must be tried before any of a higher value
are tried. In addition, in the special case in which there are
several MXs with the lowest preference value, all of them should be
tried before a message is deemed undeliverable. (...)
Le statut RFC1123 est INTERNET STANDARD . La section 5.3.4 vise à "affiner" les procédures RFC974 sur la façon de gérer les enregistrements MX. Il faut maintenant que les MTA essaient tous les serveurs SMTP par ordre croissant de préférence jusqu'à ce que l'on réussisse. Cependant, il permet toujours une limite configurable sur le nombre d'essais. S'il existe plusieurs enregistrements MX avec une valeur de préférence égale, la RFC recommande (et n'exige pas) aux MTA de sélectionner un enregistrement au hasard. Cependant, si un enregistrement MX fait référence à plusieurs enregistrements A (adresses IPv4), le RFC exige que le MTA contacte toutes ces adresses jusqu'à ce que l'une réussisse, dans l'ordre donné par le serveur DNS.
(...) When it succeeds, the mapping can result in a list of
alternative delivery addresses rather than a single address,
because of (a) multiple MX records, (b) multihoming, or both.
To provide reliable mail transmission, the sender-SMTP MUST be
able to try (and retry) each of the addresses in this list in
order, until a delivery attempt succeeds. However, there MAY
also be a configurable limit on the number of alternate
addresses that can be tried. In any case, a host SHOULD try at
least two addresses.
The following information is to be used to rank the host
addresses:
(1) Multiple MX Records -- these contain a preference
indication that should be used in sorting. If there are
multiple destinations with the same preference and there
is no clear reason to favor one (e.g., by address
preference), then the sender-SMTP SHOULD pick one at
random to spread the load across multiple mail exchanges
for a specific organization; note that this is a
refinement of the procedure in [DNS:3].
(2) Multihomed host -- The destination host (perhaps taken
from the preferred MX record) may be multihomed, in which
case the domain name resolver will return a list of
alternative IP addresses. It is the responsibility of the
domain name resolver interface (see Section 6.1.3.4 below)
to have ordered this list by decreasing preference, and
SMTP MUST try them in the order presented.
(...)
[DNS:3] "Mail Routing and the Domain System," C. Partridge, RFC-974,
January 1986.
Le statut du RFC2821 est PROPOSED STANDARD . Cette RFC obsolète la RFC974 et, dans le cadre de la gestion des enregistrements MX, elle diffère légèrement de la RFC1123. Alors que le premier EXIGE une sélection aléatoire d'un serveur SMTP parmi plusieurs enregistrements MX avec une valeur de préférence égale, le second le RECOMMANDE.
(...) Multiple MX records contain a preference indication that MUST be used
in sorting (see below). Lower numbers are more preferred than higher
ones. If there are multiple destinations with the same preference
and there is no clear reason to favor one (e.g., by recognition of an
easily-reached address), then the sender-SMTP MUST randomize them to
spread the load across multiple mail exchangers for a specific
organization.
The destination host (perhaps taken from the preferred MX record) may
be multihomed, in which case the domain name resolver will return a
list of alternative IP addresses. It is the responsibility of the
domain name resolver interface to have ordered this list by
decreasing preference if necessary, and SMTP MUST try them in the
order presented. (...)
Le statut du RFC5321 est DRAFT STANDARD . Cette RFC rend la RFC2821 obsolète et, dans le contexte de la résolution DNS, elle réécrit essentiellement la même procédure de recherche de serveur et présente une nouvelle section qui traite légèrement de la gestion des enregistrements MX qui font référence aux adresses IPv6.
(...) When a domain name associated with an MX RR is looked up and the
associated data field obtained, the data field of that response MUST
contain a domain name. That domain name, when queried, MUST return
at least one address record (e.g., A or AAAA RR) that gives the IP
address of the SMTP server to which the message should be directed.
(...) When the lookup succeeds, the mapping can result in a list of
alternative delivery addresses rather than a single address, because
of multiple MX records, multihoming, or both. To provide reliable
mail transmission, the SMTP client MUST be able to try (and retry)
each of the relevant addresses in this list in order, until a
delivery attempt succeeds.
(...) MX records contain a preference indication that MUST be used in
sorting if more than one such record appears (see below). Lower
numbers are more preferred than higher ones. If there are multiple
destinations with the same preference and there is no clear reason to
favor one (e.g., by recognition of an easily reached address), then
the sender-SMTP MUST randomize them to spread the load across
multiple mail exchangers for a specific organization.
The destination host (perhaps taken from the preferred MX record) may
be multihomed, in which case the domain name resolver will return a
list of alternative IP addresses. It is the responsibility of the
domain name resolver interface to have ordered this list by
decreasing preference if necessary, and the SMTP sender MUST try them
in the order presented. (...)
Je suppose qu'un agent de transfert de courrier moderne suit au moins les procédures RFC2821 ou RFC5321, donc les trois configurations DNS offrent des capacités de basculement. Cependant, seule la première configuration peut fournir un meilleur équilibrage de charge. Si vous essayez la deuxième ou la troisième configuration, vous devrez vous assurer que votre serveur DNS fournit des réponses dans un ordre aléatoire. En outre, les enregistrements DNS peuvent être mis en cache par les MTA eux-mêmes ou par des serveurs DNS récursifs, de sorte que le caractère aléatoire ne peut pas être garanti. Je pense mail1.example.comque recevra la plupart des messages.
Une autre raison qui oriente mon opinion contre les deuxième et troisième configurations est la référence de plusieurs noms à une seule adresse IP. Les serveurs de messagerie sur Internet rejettent généralement les messages des hôtes dont le mappage IP address => PTR => hostname => A => IP addressne correspond pas (tout comme la restriction Postfix rejette_unknown_client_hostname ), vous devrez donc faire particulièrement attention à la définition des enregistrements PTR.
Les clients qui n'essaient pas les enregistrements MX dans un ordre aléatoire violent déjà les normes RFC2821 et RFC5321. Donc, je pense qu'il n'y a aucune garantie que ces clients essaieront également l'adresse IP secondaire automatiquement. Pour cette raison, je préfère la configuration DNS la plus simple:
example.com. 1200 IN MX 10 mail1.example.com.
example.com. 1200 IN MX 10 mail2.example.com.
mail1.example.com. 1200 IN A 172.16.10.1
mail2.example.com. 1200 IN A 172.16.10.2
EDIT: Ajout de références à RFC1123.
La deuxième configuration ne prend pas en charge le basculement. Disons que mail.example.com a été résolu en 172.16.10.1 et qu'il échoue. Ensuite, 172.16.10.2 ne sera pas essayé car il n'y a qu'un seul enregistrement MX.
La troisième configuration génère deux fois le trafic DNS comme la première. Mis à part le trafic, les deux ont le même comportement: comme vous l'avez dit, certains clients ne feront pas correctement le round-robin avec la même priorité MX.
Afin d'avoir à la fois l'équilibrage de charge et le basculement, j'essaierais:
la source
À mon avis, votre première configuration est correcte. Les raisons sont les suivantes:
Vous avez 2 enregistrements MX avec la même priorité, ce qui est bon pour l'équilibrage de charge. RFC5321 indique que le serveur SMTP doit distribuer aléatoirement la charge pour tous les serveurs ont la même priorité
Comme vous l'avez mentionné, l'enregistrement round robin A ne basculera pas correctement. Cela s'appelle un enregistrement multi-hôte-A, l'expéditeur enverra un courrier à la première entrée A sur la réponse DNS et le serveur DNS décidera de l'ordre de retour de la liste. Donc, si vous avez besoin d'une distribution de charge ou d'un basculement, vous avez besoin d'un serveur DNS pour le faire (surveillance de la santé et de la charge). Toujours basé sur RFC, tous les expéditeurs doivent d'abord essayer tous les serveurs avec la même priorité sur les enregistrements MX, afin que vous puissiez effectuer un basculement avec deux enregistrements MX.
réf: https://tools.ietf.org/html/rfc5321 page 69
la source
Pour le basculement, procédez comme suit:
Le MTA essaiera d'abord mail1, puis mail2.
La combinaison de l'équilibrage de charge et du basculement n'est pas vraiment possible. Vous pourriez faire:
Le MTA essaiera d'abord mail1 dont la moitié du temps pointe vers .1 et l'autre fois vers .2. Le problème ici est que mail2 peut pointer vers la même adresse que mail1 dans le scénario où mail1 n'est pas accessible.
Vous pouvez donc aussi essayer
pour réduire le risque que la connexion initiale ne fonctionne pas. Le risque ne sera toujours pas nul. Mais les MTA tenteront à nouveau la connexion ultérieurement.
Pour un équilibrage de charge et un basculement efficaces et essentiels à la mission, obtenez ou créez un équilibreur de charge (cluster).
la source
cela dépend du serveur de messagerie dont vous disposez. Nous avons un serveur de messagerie appelé reddoxx - il utilise uniquement le premier enregistrement mx. (avec la même priorité) Seulement s'il n'y a pas de réponse du premier mx, il se connectera au deuxième mx et ainsi de suite. Notre serveur de messagerie ignore simplement le RFC5321
la source