MXレコード、ロードバランシングとフェイルオーバーの設定の改善
ドメインexample.comを例にとると、2つのメールサーバー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
2つのサーバーを指す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
ありがとう。
MTAがMXレコードを処理する方法を指定するRFCは RFC974 、 RFC1123セクション5.3.4 、 RFC2821セクション5 および RFC5321です。セクション5 。
RFC974ステータスはHISTORICになりました 。それによると、MTAはドメインに関連付けられたMXレコードのリストをクエリすることが期待され、すべての（または固定数の）SMTPサーバーを優先順に昇格するように「推奨」されます。同じ設定値を持つMXレコードが複数ある場合、MTAは、1つが成功するまですべての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 STANDARD です。セクション5.3.4は、MXレコードの処理方法に関するRFC974手順を「洗練」することを目的としています。現在は、MTAがすべてのSMTPサーバーを優先順位の高い順に1つ成功するまで試行する必要があります。ただし、試行回数の構成可能な制限は引き続き許可されます。同じ設定値のMXレコードが複数ある場合、RFCは、ランダムに1つのレコードを選択することを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の手順に従っていると思います。そのため、3つのDNS設定すべてがフェイルオーバー機能を提供します。ただし、ロードバランシングを改善できるのは最初のセットアップだけです。 2番目または3番目のセットアップを試す場合は、DNSサーバーがランダムな順序で応答を配信することを確認する必要があります。さらに、DNSレコードはMTA自体または再帰DNSサーバーのいずれかによってキャッシュされる可能性があるため、ランダム性は保証されません。 mail1.example.comはほとんどのメッセージを受信すると思います。
2番目と3番目のセットアップに対して私の意見を向けるもう1つの理由は、1つの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
EDIT：RFC1123への参照を追加しました。
2番目のセットアップはフェイルオーバーをサポートしていません。 mail.example.comが172.16.10.1に解決され、失敗したとしましょう。 MXレコードが1つしかないため、172.16.16.2は試行されません。
3番目のセットアップでは、最初のセットアップの2倍のDNSトラフィックが生成されます。 fomトラフィックは別として、どちらも同じ動作をします。あなたが言ったように、一部のクライアントは同じ優先度の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レコード->フェイルオーバー
私の意見では、あなたの最初のセットアップは正しいです。理由は次のとおりです。
同じ優先度の2つのMXレコードがあり、負荷分散に適しています。 RFC5321は、SMTPサーバーがすべてのサーバーの負荷をランダムに分散する必要があると述べており、優先順位は同じです
おっしゃったように、ラウンドロビンAレコードは正しくフェイルオーバーしません。これはマルチホームAレコードと呼ばれ、送信者はDNS応答の最初のAエントリにメールを送信し、DNSサーバーはリストが返される順序を決定します。したがって、負荷分散またはフェイルオーバーが必要な場合は、DNSサーバーがそれを実行できる必要があります（ヒースと負荷モニター）。再びRFCに基づいて、すべての送信者は最初にMXレコードで同じ優先度のすべてのサーバーを試す必要があるため、2つのMXレコードでフェイルオーバーを実行できます。
ref： 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は後で接続を再試行します。
ミッションクリティカルなロードバランシングとフェイルオーバーを効果的に行うには、ロードバランサー（クラスター）を取得またはまとめます。