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

Question 1

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

RFC974 状态现已变为历史性。根据该规则，MTA 应查询与域关联的 MX 记录列表，并“鼓励”按优先顺序尝试所有（或固定数量的）SMTP 服务器。如果有多个具有相同优先值的 MX 记录，则 MTA 必须尝试将邮件发送到所有 SMTP 服务器，直到其中一个成功。尝试的顺序由 MTA 选择，也就是说，RFC 不会规定是随机联系 SMTP 服务器还是按照 DNS 服务器给出的顺序联系。此外，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 标准。第 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 略有不同。前者要求在具有相等优先值的多个 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 状态为草案标准。此 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 地址。互联网上的邮件服务器通常会拒绝来自映射IP address => PTR => hostname => A => IP address不匹配的主机的消息（Postfix 限制也是如此拒绝未知客户端主机名)，因此您必须特别小心设置 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 的引用。

Answer

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

RFC974 状态现已变为历史性。根据该规则，MTA 应查询与域关联的 MX 记录列表，并“鼓励”按优先顺序尝试所有（或固定数量的）SMTP 服务器。如果有多个具有相同优先值的 MX 记录，则 MTA 必须尝试将邮件发送到所有 SMTP 服务器，直到其中一个成功。尝试的顺序由 MTA 选择，也就是说，RFC 不会规定是随机联系 SMTP 服务器还是按照 DNS 服务器给出的顺序联系。此外，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 标准。第 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 略有不同。前者要求在具有相等优先值的多个 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 状态为草案标准。此 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 地址。互联网上的邮件服务器通常会拒绝来自映射IP address => PTR => hostname => A => IP address不匹配的主机的消息（Postfix 限制也是如此拒绝未知客户端主机名)，因此您必须特别小心设置 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 的引用。

Question 2

第二种设置不支持故障转移。假设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

10 MX 记录 ------> 某种负载平衡
20、30 MX 记录 --> 故障转移

Answer

第二种设置不支持故障转移。假设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

10 MX 记录 ------> 某种负载平衡
20、30 MX 记录 --> 故障转移

Question 3

我认为，您的第一个设置是正确的。原因如下：

您有 2 个优先级相同的 MX 记录，这有利于负载平衡。RFC5321 规定 SMTP 服务器需要随机分配负载，因为所有服务器都具有相同的优先级
正如您所提到的，循环 A 记录将无法正确进行故障转移。它被称为多宿主 A 记录，发件人将向 DNS 响应中的第一个 A 条目发送邮件，DNS 服务器决定列表返回的顺序。因此，如果您需要负载分配或故障转移，则需要 DNS 服务器可以执行此操作（健康和负载监视器）。同样，根据 RFC，所有发件人都需要首先尝试所有在 MX 记录上具有相同优先级的服务器，因此您可以使用两个 MX 记录进行故障转移。

參考文獻：https://www.rfc-editor.org/rfc/rfc5321第 69 页

Answer

我认为，您的第一个设置是正确的。原因如下：

您有 2 个优先级相同的 MX 记录，这有利于负载平衡。RFC5321 规定 SMTP 服务器需要随机分配负载，因为所有服务器都具有相同的优先级
正如您所提到的，循环 A 记录将无法正确进行故障转移。它被称为多宿主 A 记录，发件人将向 DNS 响应中的第一个 A 条目发送邮件，DNS 服务器决定列表返回的顺序。因此，如果您需要负载分配或故障转移，则需要 DNS 服务器可以执行此操作（健康和负载监视器）。同样，根据 RFC，所有发件人都需要首先尝试所有在 MX 记录上具有相同优先级的服务器，因此您可以使用两个 MX 记录进行故障转移。

參考文獻：https://www.rfc-editor.org/rfc/rfc5321第 69 页

Question 4

这取决于您拥有什么邮件服务器。我们有一个名为 reddoxx 的邮件服务器 - 它只使用第一个 mx 记录。（具有相同的优先级）只有当第一个 mx 没有响应时，它才会连接到第二个 mx，依此类推。我们的邮件服务器只是忽略 RFC5321

Answer

这取决于您拥有什么邮件服务器。我们有一个名为 reddoxx 的邮件服务器 - 它只使用第一个 mx 记录。（具有相同的优先级）只有当第一个 mx 没有响应时，它才会连接到第二个 mx，依此类推。我们的邮件服务器只是忽略 RFC5321

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

答案1

答案2

答案3

答案4

相关内容