MXlogging，更好地设置负载平衡和故障转移

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

RFC974状态现在是HISTORIC 。 据此，MTA预计将查询与域相关联的MXlogging列表，并且按照优先级的升序尝试所有（或固定数量）的SMTP服务器。 如果有多个MXlogging具有相同的首选项值，则MTA必须尝试将邮件传递到所有SMTP服务器，直到成功。 尝试的次序是MTA的select，即RFC不规定是否必须随机地或按照DNS服务器给定的顺序联系SMTP服务器。 另外，RFC不规定如何处理引用多个Alogging的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节旨在“细化”有关如何处理MXlogging的RFC974程序。 现在，它需要MTA按照首选项的升序尝试所有SMTP服务器，直到成功。 但是，它仍然允许尝试次数的可configuration限制。 如果有多个具有相同优先级值的MXlogging，则RFCbuild议（并且不要求）MTA随机select一条logging。 但是，如果MXlogging引用了多个Alogging（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 (eg, 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状态是build议标准 。 这个RFC废弃了RFC974，在MXlogging处理的范围内，它与RFC1123略有不同。 前者需要在多个MXlogging中随机select一个具有相同优先级值的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 (eg, 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，在DNSparsing的上下文中，它基本上重写了相同的服务器查找过程，并提出了一个新的部分，稍微讨论处理引用IPv6地址的MXlogging。

 (...) 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 (eg, 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 (eg, 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. (...) 

我想现代邮件传输代理至less遵循RFC2821或RFC5321过程，所以三个DNS设置都提供故障转移function。 但是，只有第一个设置可以提供更好的负载平衡。 如果您尝试第二或第三个设置，则必须确保您的DNS服务器以随机顺序提供响应。 此外，DNSlogging可能由MTA自己或recursionDNS服务器caching，因此无法保证随机性。 我认为mail1.example.com会收到大部分的消息。

引导我对第二和第三个设置的看法的另一个原因是将多个名称引用到一个IP地址。 互联网上的邮件服务器通常会拒绝来自IP address => PTR => hostname => A => IP address不匹配的主机的邮件（因为Postfix的限制reject_unknown_client_hostname ），所以您必须特别小心PTRlogging。

不按随机顺序尝试MXlogging的客户端已经违反了RFC2821和RFC5321标准。 所以，我认为不能保证这些客户端也会自动尝试从IP地址。 因此，我更喜欢最简单的DNSconfiguration：

 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已经parsing为172.16.10.1，并且失败。 那么172.16.10.2将不会被尝试，因为只有一个MXlogging。

第三个设置生成两个DNSstream量作为第一个。 除了stream量，他们两个都有相同的行为：正如你所说的，一些客户端将不能正确地使用相同的优先级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 MXlogging——>某种负载平衡
• 20,30个MXlogging – >故障转移

在我看来，你的第一个设置是正确的。 原因是：

1. 您有2个具有相同优先级的MXlogging，这对于负载平衡很有帮助。 RFC5321指出，SMTP服务器需要为所有服务器随机分配负载具有相同的优先级

2. 正如你所提到的，循环Alogging不会正确地进行故障转移。 它被称为multihomed-Alogging，发件人将首先发送邮件到DNS响应的一个条目，DNS服务器决定列表返回的顺序。 所以，如果你需要负载分配或故障转移，你需要一个DNS服务器可以做到这一点（健康和负载监视器）。 同样基于RFC，所有发件人都需要首先尝试所有MXlogging上具有相同优先级的服务器，因此您可以使用两个MXlogging进行故障转移。

ref： https : //tools.ietf.org/html/rfc5321 page 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。 这里的问题是，在mail1不可访问的情况下，mail2可能指向与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的邮件服务器 – 它只使用第一个mxlogging。 （具有相同的优先级）只有在没有来自第一个mx的响应时才会连接到第二个mx，依此类推。 我们的邮件服务器只是忽略了RFC5321