Die RFCs, die angeben, wie ein MTA mit MX-Datensätzen umgehen soll , sind RFC974 , RFC1123, Abschnitt 5.3.4 , RFC2821, Abschnitt 5 und RFC5321, Abschnitt 5 .
Der RFC974-Status ist jetzt HISTORISCH . Demnach wird von MTAs erwartet, dass sie die Liste der einer Domäne zugeordneten MX-Einträge abfragen, und sie werden "aufgefordert", alle (oder eine feste Anzahl von) SMTP-Server in aufsteigender Reihenfolge ihrer Präferenz zu testen. Wenn mehrere MX-Einträge mit gleichem Präferenzwert vorhanden sind, müssen MTAs versuchen, die Nachricht an alle SMTP-Server zu senden, bis einer erfolgreich ist. Die Reihenfolge der Versuche liegt bei einem MTA. Das heißt, der RFC regelt nicht, ob SMTP-Server zufällig oder in der vom DNS-Server angegebenen Reihenfolge kontaktiert werden müssen. Darüber hinaus regelt der RFC nicht, wie ein MX-Register behandelt wird, das auf mehrere A-Datensätze verweist.
(...) 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. (...)
Der RFC1123-Status lautet INTERNET STANDARD . Abschnitt 5.3.4 zielt darauf ab, die RFC974-Prozeduren zum Umgang mit MX-Datensätzen zu "verfeinern". Jetzt müssen MTAs alle SMTP-Server in aufsteigender Reihenfolge ihrer Präferenz testen, bis einer erfolgreich ist. Es ist jedoch weiterhin eine konfigurierbare Begrenzung für die Anzahl der Versuche möglich. Wenn mehrere MX-Datensätze mit gleichem Präferenzwert vorhanden sind, empfiehlt der RFC (und erfordert keine) MTAs, einen Datensatz zufällig auszuwählen. Wenn ein MX-Eintrag jedoch auf mehrere A-Einträge (IPv4-Adressen) verweist, müssen die MTAs nach dem RFC alle diese Adressen kontaktieren, bis einer erfolgreich ist, und zwar in der vom DNS-Server angegebenen Reihenfolge.
(...) 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.
Der Status des RFC2821 lautet VORGESCHLAGENER STANDARD . Dieser RFC veraltet RFC974 und unterscheidet sich im Rahmen der MX-Datensatzbehandlung geringfügig von RFC1123. Während der erstere eine zufällige Auswahl eines SMTP-Servers unter mehreren MX-Datensätzen mit gleichem Präferenzwert erfordert, EMPFIEHLT der letztere nur.
(...) 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. (...)
Der Status des RFC5321 lautet ENTWURF EINES STANDARDS . Dieser RFC macht RFC2821 überflüssig und schreibt im Kontext der DNS-Auflösung im Grunde das gleiche Server-Suchverfahren neu und enthält einen neuen Abschnitt, in dem die Behandlung von MX-Einträgen, die auf IPv6-Adressen verweisen, leicht erläutert wird.
(...) 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. (...)
Ich vermute, ein moderner Mail-Transfer-Agent befolgt mindestens die RFC2821- oder RFC5321-Verfahren, sodass alle drei DNS-Setups Failover-Funktionen bieten. Möglicherweise bietet jedoch nur das erste Setup einen besseren Lastausgleich. Wenn Sie das zweite oder dritte Setup ausprobieren, müssen Sie sicherstellen, dass Ihr DNS-Server die Antworten in zufälliger Reihenfolge liefert. Außerdem können DNS-Einträge entweder von MTAs selbst oder von rekursiven DNS-Servern zwischengespeichert werden, sodass die Zufälligkeit nicht garantiert werden kann. Ich denke, ich mail1.example.comwerde die meisten Nachrichten erhalten.
Ein weiterer Grund, der meine Meinung gegen das zweite und dritte Setup richtet, ist die Bezugnahme mehrerer Namen auf eine IP-Adresse. Mailserver im Internet lehnen IP address => PTR => hostname => A => IP addressnormalerweise Nachrichten von Hosts ab, deren Zuordnung nicht übereinstimmt (ebenso wie die Postfix-Einschränkung " reply_unknown_client_hostname" ). Daher müssen Sie beim Festlegen von PTR-Datensätzen besondere Sorgfalt walten lassen .
Clients, die MX-Datensätze nicht in zufälliger Reihenfolge testen, verstoßen bereits gegen die Standards RFC2821 und RFC5321. Ich denke, es gibt keine Garantie dafür, dass diese Clients auch die sekundäre IP-Adresse automatisch versuchen. Aus diesem Grund bevorzuge ich die einfachste DNS-Konfiguration:
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
BEARBEITEN: Verweise auf RFC1123 hinzugefügt.
Das zweite Setup unterstützt kein Failover. Angenommen , mail.example.com wurde in 172.16.10.1 aufgelöst und schlägt fehl. Dann wird 172.16.10.2 nicht ausprobiert, da es nur einen MX-Datensatz gibt.
Das dritte Setup generiert zweimal DNS-Verkehr wie das erste. Abgesehen vom Datenverkehr haben beide dasselbe Verhalten: Wie Sie sagten, führen einige Clients Round-Robin mit MX mit derselben Priorität nicht korrekt durch.
Um sowohl Lastausgleich als auch Failover zu haben, würde ich versuchen:
quelle
Meiner Meinung nach ist Ihr erstes Setup korrekt. Die Gründe sind:
Sie haben 2 MX-Datensätze mit derselben Priorität, was für den Lastausgleich gut ist. RFC5321 besagt, dass der SMTP-Server die Last für alle Server mit gleicher Priorität zufällig verteilen muss
Wie Sie bereits erwähnt haben, wird der Round-Robin-A-Datensatz nicht korrekt ausgefallen. Es wird als Multihomed-A-Eintrag bezeichnet. Der Absender sendet eine E-Mail an den ersten Eintrag in der DNS-Antwort. Der DNS-Server entscheidet über die Reihenfolge der Listenrückgabe. Wenn Sie also eine Lastverteilung oder ein Failover benötigen, benötigen Sie einen DNS-Server (Heide- und Lastmonitor). Basierend auf RFC müssen alle Absender zuerst alle Server mit derselben Priorität für MX-Datensätze testen, damit Sie ein Failover mit zwei MX-Datensätzen durchführen können.
Ref: https://tools.ietf.org/html/rfc5321 Seite 69
quelle
Für ein Failover tun Sie Folgendes:
Der MTA versucht zuerst mail1, dann mail2.
Die Kombination von Lastausgleich und Failover ist nicht wirklich möglich. Du könntest es tun:
Der MTA versucht zuerst mail1, wobei die Hälfte der Zeit auf .1 und die andere Zeit auf .2 liegt. Das Problem hierbei ist, dass mail2 in dem Szenario, in dem mail1 nicht erreichbar ist, möglicherweise auf dieselbe Adresse wie mail1 verweist.
Sie könnten es also auch versuchen
um das Risiko zu verringern, dass die anfängliche Verbindung nicht funktioniert. Trotzdem wird das Risiko nicht Null sein. MTAs werden die Verbindung jedoch später erneut versuchen.
Holen Sie sich einen Load Balancer (Cluster) oder stellen Sie ihn zusammen, um einen effektiven Missionsausgleich und ein Failover durchzuführen.
quelle
Es hängt davon ab, welchen Mailserver Sie haben. Wir haben einen Mailserver namens reddoxx - er verwendet nur den ersten mx-Datensatz. (mit gleicher Priorität) Nur wenn vom ersten mx keine Antwort kommt, wird eine Verbindung zum zweiten mx hergestellt und so weiter. Unser Mailserver ignoriert nur RFC5321
quelle