RFC, które określają, w jaki sposób MTA powinien obsługiwać rekordy MX, to RFC974 , RFC1123 sekcja 5.3.4 , RFC2821 sekcja 5 i RFC5321 sekcja 5 .
Status RFC974 ma teraz HISTORIC . Zgodnie z nim oczekuje się, że MTA sprawdzą listę rekordów MX powiązanych z domeną i „zachęca się” do wypróbowania wszystkich (lub stałej liczby) serwerów SMTP, w kolejności rosnącej. Jeśli istnieje wiele rekordów MX o jednakowej wartości preferencji, MTA muszą próbować dostarczyć wiadomość do wszystkich serwerów SMTP, dopóki jeden się nie powiedzie. Kolejność prób jest wyborem MTA, to znaczy RFC nie decyduje, czy z serwerami SMTP należy się kontaktować losowo, czy w kolejności podanej przez serwer DNS. Ponadto RFC nie rządzi sposobem obsługi rejestru MX, który odwołuje się do wielu rekordów 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. (...)
Status RFC1123 to STANDARD INTERNETOWY . Sekcja 5.3.4 ma na celu „udoskonalenie” procedur RFC974 dotyczących obsługi rekordów MX. Teraz wymaga od MTA wypróbowania wszystkich serwerów SMTP w rosnącej kolejności preferencji, dopóki jeden się nie powiedzie. Jednak nadal pozwala na konfigurowalne ograniczenie liczby prób. Jeśli istnieje wiele rekordów MX o jednakowej wartości preferencji, RFC zaleca (i nie wymaga) MTA wybranie jednego rekordu losowo. Jeśli jednak rekord MX odwołuje się do wielu rekordów A (adresów IPv4), RFC wymaga, aby MTA skontaktowały się ze wszystkimi tymi adresami, dopóki jeden się nie powiedzie, w kolejności podanej przez serwer 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.
Status RFC2821 ma PROPONOWANY STANDARD . To RFC przestarzałe RFC974 i, w zakresie obsługi rekordów MX, nieznacznie różni się od RFC1123. Podczas gdy pierwszy WYMAGA losowego wyboru serwera SMTP spośród wielu rekordów MX o jednakowej wartości preferencji, ten drugi po prostu ZALECA go.
(...) 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. (...)
Status RFC5321 to PROJEKT STANDARDOWY . To RFC dezaktualizuje RFC2821 i, w kontekście rozpoznawania DNS, w zasadzie przepisuje tę samą procedurę wyszukiwania serwera i przedstawia nową sekcję, która omawia nieco obsługę rekordów MX, które odwołują się do adresów 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. (...)
Wydaje mi się, że nowoczesny agent przesyłania poczty przestrzega co najmniej procedur RFC2821 lub RFC5321, więc wszystkie trzy konfiguracje DNS zapewniają przełączanie awaryjne. Jednak tylko pierwsza konfiguracja może zapewnić lepsze równoważenie obciążenia. Jeśli spróbujesz użyć drugiej lub trzeciej konfiguracji, musisz upewnić się, że Twój serwer DNS dostarcza odpowiedzi w losowej kolejności. Poza tym rekordy DNS mogą być buforowane przez same MTA lub rekurencyjne serwery DNS, więc nie można zagwarantować losowości. Myślę, że mail1.example.comotrzyma większość wiadomości.
Innym powodem, który kieruje moją opinią w stosunku do drugiego i trzeciego zestawu, jest odwołanie wielu nazw do jednego adresu IP. Serwery pocztowe w Internecie zwykle odrzucają wiadomości od hostów, których mapowanie IP address => PTR => hostname => A => IP addressnie jest zgodne (podobnie jak ograniczenie Postfix odmowa_poznania_nazwa_hosta_klienta ), dlatego należy zachować szczególną ostrożność przy ustawianiu rekordów PTR.
Klienci, którzy nie próbują rekordów MX w losowej kolejności, już naruszają standardy RFC2821 i RFC5321. Myślę więc, że nie ma gwarancji, że ci klienci również spróbują automatycznie użyć dodatkowego adresu IP. Z tego powodu wolę najprostszą konfigurację DNS:
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
EDYCJA: Dodano odniesienia do RFC1123.
Druga konfiguracja nie obsługuje przełączania awaryjnego. Załóżmy, że mail.example.com został rozwiązany do 172.16.10.1 i kończy się niepowodzeniem. Wówczas 172.16.10.2 nie będzie próbował, ponieważ istnieje tylko jeden rekord MX.
Trzecia konfiguracja generuje dwukrotnie większy ruch DNS niż pierwszy. Oprócz ruchu, oba mają takie samo zachowanie: jak powiedziałeś, niektórzy klienci nie będą poprawnie wykonywać rundy z tym samym priorytetem MX.
Aby mieć zarówno równoważenie obciążenia, jak i przełączanie awaryjne, spróbowałbym:
źródło
Moim zdaniem Twoja pierwsza konfiguracja jest poprawna. Powody są następujące:
Masz 2 rekordy MX o tym samym priorytecie, co jest dobre dla równoważenia obciążenia. RFC5321 stwierdza, że serwer SMTP musi losowo rozłożyć obciążenie na wszystkie serwery o tym samym priorytecie
Jak wspomniałeś, rekord round robin A nie przejdzie w tryb failover poprawnie. Nazywa się to rekordem multihomed-A, nadawca wyśle pocztę do pierwszego wpisu w odpowiedzi DNS, a serwer DNS zdecyduje o kolejności zwrotu listy. Jeśli więc potrzebujesz dystrybucji obciążenia lub przełączenia awaryjnego, potrzebujesz serwera DNS, który może to zrobić (monitor obciążenia i obciążenia). Ponownie na podstawie RFC wszyscy nadawcy muszą najpierw wypróbować wszystkie serwery o tym samym priorytecie w rekordach MX, aby można było wykonać przełączenie awaryjne za pomocą dwóch rekordów MX.
ref: https://tools.ietf.org/html/rfc5321 strona 69
źródło
W przypadku przełączania awaryjnego wykonaj:
MTA najpierw spróbuje mail1, a następnie mail2.
Połączenie równoważenia obciążenia i przełączania awaryjnego nie jest tak naprawdę możliwe. Mógłbyś:
MTA najpierw spróbuje mail1, która połowa czasu wskazuje na .1, a innym razem na .2. Problem polega na tym, że mail2 może wskazywać ten sam adres co mail1 w scenariuszu, w którym mail1 jest nieosiągalny.
Więc możesz też spróbować
aby zmniejszyć ryzyko, że początkowe połączenie nie zadziała. Jednak ryzyko nie wyniesie zero. Ale MTA ponowią próbę połączenia później.
Aby uzyskać efektywne równoważenie obciążenia i przełączanie awaryjne, pobierz lub złóż moduł równoważenia obciążenia (klaster).
źródło
zależy to od posiadanego serwera pocztowego. Mamy serwer pocztowy o nazwie reddoxx - wykorzystuje on tylko pierwszy rekord mx. (z tym samym priorytetem) Tylko jeśli nie ma odpowiedzi od pierwszego MX, to połączy się z drugim MX i tak dalej. Nasz serwer pocztowy ignoruje RFC5321
źródło