MX 记录，更好地设置负载平衡和故障转移

Question

以域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

谢谢。

Answer 1

指定 MTA 应如何处理 MX 记录的 RFC 是RFC974、RFC1123 第 5.3.4 节、RFC2821 第 5 节和RFC5321 第 5 节。

RFC974 状态现在是 HISTOIC。根据它，MTA 应该查询与域关联的 MX 记录列表，并“鼓励”尝试所有（或固定数量的）SMTP 服务器，按偏好的升序排列。如果有多个 MX 记录具有相同的首选项值，则 MTA 必须尝试将邮件传送到所有 SMTP 服务器，直到其中一个成功。尝试的顺序是 MTA 的选择，也就是说，RFC 没有规定是否必须随机或按照 DNS 服务器给出的顺序联系 SMTP 服务器。此外，RFC 没有规定如何处理引用多个 A 记录的 MX 寄存器。

(...) 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 状态是 INTERNET STANDARD。第 5.3.4 节旨在“完善”有关如何处理 MX 记录的 RFC974 程序。现在要求 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 状态是 PROPOSED STANDARD。此 RFC 废弃了 RFC974，并且在 MX 记录处理的范围内，它与 RFC1123 略有不同。前者需要在具有相同首选项值的多个 MX 记录中随机选择一个 SMTP 服务器，而后者只是推荐它。

(...) 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 状态为 DRAFT STANDARD。此 RFC 废弃了 RFC2821，并且在 DNS 解析的上下文中，它基本上重写了相同的服务器查找过程，并提供了一个新部分，稍微讨论了对引用 IPv6 地址的 MX 记录的处理。

(...) 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 地址的引用。Internet 中的邮件服务器通常会拒绝来自映射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 的引用。