Los RFC que especifican cómo debe manejar un MTA los registros MX son RFC974 , RFC1123 sección 5.3.4 , RFC2821 sección 5 y RFC5321 sección 5 .
El estado RFC974 ahora es HISTÓRICO . Según esto, se espera que los MTA consulten la lista de registros MX asociados a un dominio y se los "alienta" a probar todos (o un número fijo) de servidores SMTP, en orden ascendente de preferencia. Si hay varios registros MX con un valor de preferencia igual, los MTA deben intentar entregar el mensaje a todos los servidores SMTP hasta que uno tenga éxito. El orden de los intentos es una elección del MTA, es decir, el RFC no determina si los servidores SMTP deben contactarse al azar o en el orden dado por el servidor DNS. Además, el RFC no determina cómo manejar un registro MX que hace referencia a múltiples registros 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. (...)
El estado RFC1123 es ESTÁNDAR DE INTERNET . La Sección 5.3.4 tiene como objetivo "refinar" los procedimientos RFC974 sobre cómo manejar los registros MX. Ahora requiere que los MTA prueben todos los servidores SMTP en orden ascendente de preferencia hasta que uno tenga éxito. Sin embargo, todavía permite un límite configurable en el número de intentos. Si hay varios registros MX con un valor de preferencia igual, el RFC recomienda (y no requiere) que los MTA seleccionen un registro al azar. Sin embargo, si un registro MX hace referencia a múltiples registros A (direcciones IPv4), el RFC requiere que los MTA se pongan en contacto con todas estas direcciones hasta que tenga éxito, en el orden dado por el servidor 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.
El estado RFC2821 es NORMA PROPUESTA . Este RFC obsoleto RFC974 y, en el ámbito del manejo de registros MX, difiere ligeramente de RFC1123. Mientras que el primero REQUIERE una selección aleatoria de un servidor SMTP entre múltiples registros MX con un valor de preferencia igual, el último simplemente lo RECOMIENDA.
(...) 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. (...)
El estado RFC5321 es DRAFT STANDARD . Este RFC obsoleto RFC2821 y, en el contexto de la resolución DNS, básicamente reescribe el mismo procedimiento de búsqueda del servidor y presenta una nueva sección que trata un poco sobre el manejo de registros MX que hacen referencia a direcciones 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. (...)
Supongo que un agente de transferencia de correo moderno sigue al menos los procedimientos RFC2821 o RFC5321, por lo que las tres configuraciones de DNS proporcionan capacidades de conmutación por error. Sin embargo, solo la primera configuración puede proporcionar un mejor equilibrio de carga. Si prueba la segunda o la tercera configuración, deberá asegurarse de que su servidor DNS proporcione respuestas en un orden aleatorio. Además, los registros DNS pueden almacenarse en caché, ya sea por los propios MTA o por servidores DNS recursivos, por lo que no se puede garantizar la aleatoriedad. Creo mail1.example.comque recibirá la mayoría de los mensajes.
Otra razón que dirige mi opinión contra las configuraciones segunda y tercera es la referencia de múltiples nombres a una dirección IP. Los servidores de correo en Internet comúnmente rechazan los mensajes de los hosts cuya asignación IP address => PTR => hostname => A => IP addressno coincide (al igual que la restricción de Postfix rechazo_desconocido_nombre_host_cliente ), por lo que deberá tener especial cuidado al establecer registros PTR.
Los clientes que no prueban los registros MX en un orden aleatorio ya están violando los estándares RFC2821 y RFC5321. Por lo tanto, creo que no hay garantía de que estos clientes también prueben la dirección IP secundaria automáticamente. Por eso, prefiero la configuración de DNS más 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
EDITAR: Se agregaron referencias a RFC1123.
La segunda configuración no admite la conmutación por error. Digamos que mail.example.com se ha resuelto a 172.16.10.1 y falla. Entonces 172.16.10.2 no se probará, ya que solo hay un registro MX.
La tercera configuración genera dos veces el tráfico de DNS como la primera. Aparte del tráfico, ambos tienen el mismo comportamiento: como dijiste, algunos clientes no harán correctamente el round-robin con la misma prioridad MX.
Para tener tanto el equilibrio de carga como la conmutación por error, intentaría:
fuente
En mi opinión, su primera configuración es correcta. Los motivos son:
Tiene 2 registros MX con la misma prioridad, lo cual es bueno para el equilibrio de carga. RFC5321 establece que el servidor SMTP necesita distribuir aleatoriamente la carga para todos los servidores que tienen la misma prioridad
Como mencionó, el registro round robin A no funcionará correctamente. Se llama registro multihomed-A, el remitente enviará el correo a la primera entrada A en la respuesta DNS y el servidor DNS decidirá el orden de devolución de la lista. Entonces, si necesita distribución de carga o conmutación por error, necesita un servidor DNS que pueda hacerlo (monitor de salud y carga). Una vez más, basado en RFC, todos los remitentes deben probar primero todos los servidores con la misma prioridad en los registros MX, para que pueda realizar la conmutación por error con dos registros MX.
ref: https://tools.ietf.org/html/rfc5321 página 69
fuente
Para failover hacer:
El MTA primero intentará mail1, luego mail2.
La combinación de equilibrio de carga y conmutación por error no es realmente posible. Podrías hacerlo:
El MTA primero intentará mail1, que la mitad del tiempo apunta a .1 y la otra vez a .2. El problema aquí es que mail2 puede apuntar a la misma dirección que mail1 en el escenario donde mail1 no es accesible.
Entonces también podrías intentar
para reducir el riesgo de que la conexión inicial no funcione. Aún así el riesgo no será cero. Pero los MTA volverán a intentar la conexión más tarde.
Para lograr un equilibrio de carga y misión faciales de manera efectiva, obtenga o arme un equilibrador de carga (clúster).
fuente
depende del servidor de correo que tengas. Tenemos un servidor de correo llamado reddoxx: solo usa el primer registro mx. (con la misma prioridad) Solo si no hay respuesta del primer mx, se conectará al segundo mx y así sucesivamente. Nuestro servidor de correo simplemente ignora RFC5321
fuente