Возьмем домен example.com, у него есть два почтовых сервера mail1.example.com и mail2.example.com, оба уже настроены, обычно я бы пошел со следующей настройкой:
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
Сотрудник предложил следующую схему:
example.com. 1200 IN MX 10 mail.example.com.
mail.example.com. 1200 IN A 172.16.10.1
mail.example.com. 1200 IN A 172.16.10.2
mail1.example.com. 1200 IN A 172.16.10.1
mail2.example.com. 1200 IN A 172.16.10.2
Одно новое имя хоста с двумя записями A, которые указывают на два сервера, поскольку он заявляет, что некоторые клиенты неправильно выполняют циклический перебор с одинаковым приоритетом MX, это должна быть правильная настройка, но все же правильно поддерживает переключение при отказе, например 172.16.10.1 не работает, 172.16.10.2 пытается доставить? Или было бы еще лучше такой вариант:
example.com. 1200 IN MX 10 mail.example.com.
example.com. 1200 IN MX 20 mail1.example.com.
example.com. 1200 IN MX 20 mail2.example.com.
mail.example.com. 1200 IN A 172.16.10.1
mail.example.com. 1200 IN A 172.16.10.2
mail1.example.com. 1200 IN A 172.16.10.1
mail2.example.com. 1200 IN A 172.16.10.2
Спасибо.
RFC, которые определяют, как MTA должен обрабатывать записи MX: RFC974, RFC1123 раздел 5.3.4, RFC2821 раздел 5 и RFC5321 раздел 5.
Статус RFC974 теперь ИСТОРИЧЕСКИЙ. В соответствии с ним ожидается, что MTA будут запрашивать список записей MX, связанных с доменом, и «поощряются» опробовать все (или фиксированное количество) SMTP-серверов в порядке возрастания предпочтений. Если имеется несколько записей MX с одинаковым значением предпочтения, MTA должен попытаться доставить сообщение на все SMTP-серверы, пока один из них не завершится успешно. Порядок попыток - это выбор MTA, то есть RFC не определяет, следует ли связываться с SMTP-серверами случайным образом или в порядке, заданном DNS-сервером. Кроме того, RFC не определяет, как обрабатывать регистр MX, который ссылается на несколько записей 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. (...)
RFC1123 статус - СТАНДАРТ ИНТЕРНЕТ. Раздел 5.3.4 направлен на «уточнение» процедур RFC974 относительно того, как обрабатывать записи MX. Теперь требуется, чтобы MTA пробовал все SMTP-серверы в порядке возрастания предпочтений, пока один из них не завершился успешно. Однако он по-прежнему позволяет настраивать ограничение на количество попыток. Если имеется несколько записей MX с одинаковым значением предпочтения, RFC рекомендует (и не требует) MTA выбирать одну запись случайным образом. Однако, если запись MX ссылается на несколько записей A (адресов IPv4), RFC требует, чтобы MTA связывался со всеми этими адресами до тех пор, пока один из них не будет успешным, в порядке, заданном 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.
Статус RFC2821 ПРЕДЛАГАЕТСЯ СТАНДАРТ. Этот RFC отменяет RFC974 и в части обработки записей MX немного отличается от RFC1123. В то время как первое ТРЕБУЕТ случайного выбора SMTP-сервера среди нескольких записей MX с одинаковым значением предпочтения, второе просто РЕКОМЕНДУЕТ это.
(...) 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. (...)
Статус RFC5321 - ПРОЕКТ СТАНДАРТА. Этот RFC отменяет RFC2821 и, в контексте разрешения DNS, в основном переписывает ту же процедуру поиска на сервере и представляет новый раздел, в котором немного обсуждается обработка записей MX, которые ссылаются на адреса 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. (...)
Я предполагаю, что современный агент пересылки почты следует как минимум процедурам RFC2821 или RFC5321, поэтому все три настройки DNS обеспечивают возможность аварийного переключения. Однако только первая настройка может обеспечить лучшую балансировку нагрузки. Если вы попробуете вторую или третью настройку, вам нужно будет убедиться, что ваш DNS-сервер доставляет ответы в случайном порядке. Кроме того, записи DNS могут кэшироваться либо самими MTA, либо рекурсивными DNS-серверами, поэтому случайность не может быть гарантирована. думаю mail1.example.com получит большинство сообщений.
Другая причина, которая направляет мое мнение против второй и третьей установок, - это ссылка нескольких имен на один IP-адрес. Почтовые серверы в Интернете обычно отклоняют сообщения от хостов, сопоставление которых IP address => PTR => hostname => A => IP address не совпадает (как и ограничение Postfix reject_unknown_client_hostname), поэтому вам нужно будет уделить особое внимание настройке PTR-записей.
Клиенты, которые не пробуют записи MX в случайном порядке, уже нарушают стандарты RFC2821 и RFC5321. Итак, я думаю, нет никакой гарантии, что эти клиенты также автоматически попробуют вторичный IP-адрес. Из-за этого я предпочитаю самую простую конфигурацию 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
РЕДАКТИРОВАТЬ: Добавлены ссылки на RFC1123.
Вторая установка не поддерживает аварийное переключение. Скажем mail.example.com был разрешен до 172.16.10.1 и не работает. Тогда 172.16.10.2 не будет пробоваться, так как есть только одна запись MX.
Третья установка генерирует двойной DNS-трафик по сравнению с первой. Помимо трафика, оба они ведут себя одинаково: как вы сказали, некоторые клиенты не будут правильно выполнять циклический перебор с одинаковым приоритетом MX.
Чтобы иметь как балансировку нагрузки, так и аварийное переключение, я бы попробовал:
example.com. 1200 IN MX 10 mail1.example.com.
example.com. 1200 IN MX 10 mail2.example.com.
example.com. 1200 IN MX 20 mail3.example.com.
example.com. 1200 IN MX 30 mail4.example.com.
mail1.example.com. 1200 IN A 172.16.10.1
mail2.example.com. 1200 IN A 172.16.10.2
mail3.example.com. 1200 IN A 172.16.10.1
mail4.example.com. 1200 IN A 172.16.10.2
На мой взгляд, ваша первая настройка верна. Причины:
У вас есть 2 записи MX с одинаковым приоритетом, что хорошо для балансировки нагрузки. RFC5321 утверждает, что SMTP-серверу необходимо случайным образом распределять нагрузку для всех серверов с одинаковым приоритетом.
Как вы упомянули, циклическая запись A не будет правильно переключаться при отказе. Это называется многосетевой записью A, отправитель будет отправлять почту первой записи A в ответе DNS, а DNS-сервер определяет порядок возврата списка. Поэтому, если вам нужно распределение нагрузки или аварийное переключение, вам нужен DNS-сервер, который может это сделать (мониторинг состояния и нагрузки). Опять же, на основе RFC всем отправителям необходимо сначала опробовать все серверы с одинаковым приоритетом в записях MX, чтобы можно было выполнить аварийное переключение с двумя записями MX.
ссылка: https://tools.ietf.org/html/rfc5321 стр.69
Для аварийного переключения выполните:
example.com. 1200 IN MX 10 mail1.example.com.
example.com. 1200 IN MX 20 mail2.example.com.
mail1.example.com. 1200 IN A 172.16.10.1
mail2.example.com. 1200 IN A 172.16.10.2
MTA сначала попробует mail1, затем mail2.
Совмещение балансировки нагрузки и аварийного переключения на самом деле невозможно. Вы могли сделать:
example.com. 1200 IN MX 10 mail1.example.com.
example.com. 1200 IN MX 20 mail2.example.com.
mail1.example.com. 1200 IN A 172.16.10.1
mail1.example.com. 1200 IN A 172.16.10.2
mail2.example.com. 1200 IN A 172.16.10.1
mail2.example.com. 1200 IN A 172.16.10.2
MTA сначала попробует mail1, который в половине случаев указывает на .1, а другой - на .2. Проблема здесь в том, что mail2 может указывать на тот же адрес, что и mail1 в сценарии, где mail1 недоступен.
Так что вы также можете попробовать
example.com. 1200 IN MX 10 mail1.example.com.
example.com. 1200 IN MX 10 mail2.example.com.
example.com. 1200 IN MX 20 mail2.example.com.
example.com. 1200 IN MX 20 mail1.example.com.
mail1.example.com. 1200 IN A 172.16.10.1
mail1.example.com. 1200 IN A 172.16.10.2
mail2.example.com. 1200 IN A 172.16.10.1
mail2.example.com. 1200 IN A 172.16.10.2
чтобы снизить риск того, что первоначальное соединение не будет работать. Тем не менее риск не будет нулевым. Но MTA повторно попытаются установить соединение позже.
Для эффективной балансировки нагрузки и переключения при отказе необходимо создать или собрать балансировщик нагрузки (кластер).
это зависит от того, какой у вас почтовый сервер. У нас есть почтовый сервер под названием reddoxx - он использует только первую запись mx. (с таким же приоритетом) Только если нет ответа от первого mx, он подключится ко второму mx и так далее. Наш почтовый сервер просто игнорирует RFC5321