RFC yang menentukan bagaimana MTA harus menangani catatan MX adalah RFC974 , RFC1123 bagian 5.3.4 , RFC2821 bagian 5 dan RFC5321 bagian 5 .
Status RFC974 sekarang SEJARAH . Menurutnya, MTA diharapkan untuk menanyakan daftar catatan MX yang terkait dengan domain dan "didorong" untuk mencoba semua (atau jumlah tetap) server SMTP, dalam urutan preferensi yang meningkat. Jika ada beberapa catatan MX dengan nilai preferensi yang sama, MTA harus mencoba mengirimkan pesan ke semua server SMTP hingga berhasil. Urutan upaya adalah pilihan MTA, yaitu, RFC tidak mengesampingkan apakah server SMTP harus dihubungi secara acak atau dalam urutan yang diberikan oleh server DNS. Selain itu, RFC tidak mengesampingkan cara menangani register MX yang merujuk beberapa catatan 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. (...)
Status RFC1123 adalah INTERNET STANDARD . Bagian 5.3.4 bertujuan untuk "memperbaiki" prosedur RFC974 tentang bagaimana menangani catatan MX. Sekarang membutuhkan MTA untuk mencoba semua server SMTP dalam urutan preferensi naik sampai berhasil. Namun itu masih memungkinkan batas yang dapat dikonfigurasi pada jumlah percobaan. Jika ada beberapa catatan MX dengan nilai preferensi yang sama, RFC merekomendasikan (dan tidak mengharuskan) MTA untuk memilih satu catatan secara acak. Namun, jika catatan MX merujuk beberapa catatan A (alamat IPv4), RFC mengharuskan MTA untuk menghubungi semua alamat ini sampai satu berhasil, dalam urutan yang diberikan oleh server 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.
Status RFC2821 adalah PROPOSED STANDARD . RFC ini usang RFC974 dan, dalam lingkup penanganan catatan MX, itu sedikit berbeda dari RFC1123. Sementara yang pertama MEMBUTUHKAN pemilihan acak server SMTP di antara beberapa catatan MX dengan nilai preferensi yang sama, yang terakhir hanya MENYARANKANnya.
(...) 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. (...)
Status RFC5321 adalah DRAFT STANDARD . RFC ini usang RFC2821 dan, dalam konteks resolusi DNS, pada dasarnya penulisan ulang prosedur pencarian server yang sama dan menyajikan bagian baru yang sedikit membahas penanganan catatan MX yang merujuk alamat 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. (...)
Saya kira agen transfer surat modern mengikuti setidaknya prosedur RFC2821 atau RFC5321, sehingga ketiga pengaturan DNS menyediakan kemampuan failover. Namun, hanya pengaturan pertama yang dapat memberikan penyeimbangan beban yang lebih baik. Jika Anda mencoba pengaturan kedua atau ketiga, Anda harus memastikan server DNS Anda memberikan respons secara acak. Selain itu, catatan DNS dapat di-cache baik oleh MTA sendiri atau oleh server DNS rekursif, sehingga keacakan tidak dapat dijamin. Saya pikir mail1.example.comakan menerima sebagian besar pesan.
Alasan lain yang mengarahkan pendapat saya terhadap pengaturan kedua dan ketiga adalah referensi beberapa nama ke satu alamat IP. Server mail di internet umumnya menolak pesan dari host yang pemetaannya IP address => PTR => hostname => A => IP addresstidak cocok (seperti halnya pembatasan Postfix reject_unknown_client_hostname ), jadi Anda harus berhati-hati dalam mengatur catatan PTR.
Klien yang tidak mencoba data MX dalam urutan acak sudah melanggar standar RFC2821 dan RFC5321. Jadi, saya pikir tidak ada jaminan bahwa klien ini juga akan mencoba alamat IP sekunder secara otomatis. Karena itu, saya lebih suka konfigurasi DNS yang paling sederhana:
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: Menambahkan referensi ke RFC1123.
Pengaturan kedua tidak mendukung failover. Katakanlah mail.example.com telah diselesaikan ke 172.16.10.1 dan gagal. Maka 172.16.10.2 tidak akan dicoba karena hanya ada satu catatan MX.
Pengaturan ketiga menghasilkan dua kali lalu lintas DNS sebagai yang pertama. Selain lalu lintas, keduanya memiliki perilaku yang sama: Seperti yang Anda katakan beberapa klien tidak akan melakukan round-robin dengan MX prioritas yang sama.
Untuk memiliki load balancing dan failover saya akan mencoba:
sumber
Menurut pendapat saya, pengaturan pertama Anda sudah benar. Alasannya adalah:
Anda memiliki 2 catatan MX dengan prioritas yang sama yang baik untuk penyeimbangan beban. RFC5321 menyatakan bahwa SMTP-server perlu mendistribusikan beban secara acak karena semua server memiliki prioritas yang sama
Seperti yang Anda sebutkan, catatan round robin A tidak akan gagal dengan benar. Ini disebut multihomed-A record, pengirim akan mengirim email ke entri pertama pada respon DNS dan server DNS memutuskan urutan daftar kembali. Jadi, jika Anda memerlukan distribusi muatan atau failover, Anda memerlukan server DNS yang dapat melakukannya (heath and load monitor). Sekali lagi berdasarkan RFC semua pengirim perlu mencoba semua server dengan prioritas yang sama pada catatan MX terlebih dahulu, sehingga Anda dapat melakukan failover dengan dua catatan MX.
ref: https://tools.ietf.org/html/rfc5321 halaman 69
sumber
Untuk failover lakukan:
MTA pertama-tama akan mencoba mail1, kemudian mail2.
Menggabungkan load-balancing dan failover tidak benar-benar mungkin. Anda bisa melakukannya:
MTA pertama-tama akan mencoba mail1 yang setengah dari titik waktunya ke .1 dan waktu lainnya ke .2. Masalahnya di sini adalah bahwa mail2 dapat menunjuk ke alamat yang sama dengan mail1 dalam skenario di mana mail1 tidak dapat dijangkau.
Jadi Anda juga bisa mencoba
untuk menurunkan risiko koneksi awal tidak akan berfungsi. Namun risikonya tidak akan menjadi nol. Tetapi MTA akan mencoba kembali koneksi nanti.
Untuk melakukan penyeimbangan muatan dan failover misi yang efektif, kumpulkan atau kumpulkan penyeimbang beban (kluster).
sumber
itu tergantung server surat yang Anda miliki. Kami memiliki server surat bernama reddoxx - hanya menggunakan catatan mx pertama. (dengan prioritas yang sama) Hanya jika tidak ada respons dari mx pertama maka akan terhubung ke mx kedua dan seterusnya. Server email kami mengabaikan RFC5321
sumber