Tidak menerima email dari beberapa pengirim karena konfigurasi DNS

Saya perhatikan perilaku aneh dari domain aplikasi Google saya. Sebagian besar surat masuk seperti yang Anda harapkan, tetapi selama periode waktu saya sampai pada kesimpulan bahwa surat dari pengirim tertentu tidak datang. Setelah mengidentifikasi satu pengirim seperti itu, yang surat-suratnya tidak akan datang, saya memintanya untuk mencoba mengirim saya email dan meneruskan "kegagalan pengiriman" - sebagai respons terhadap gmail biasa saya.

Respons kegagalan pengiriman berisi cuplikan berikut:

----- Transkrip sesi berikut -----
<myusername@GHS.L.GOOGLE.COM>... Ditangguhkan: Koneksi habis waktu dengan ghs.l.google.com.

Ini membantu saya mengidentifikasi masalah dengan melakukan pencarian cepat yang mengarahkan saya ke halaman ini di Forum Bantuan Google Apps. Memang, saya memeriksa data DNS untuk domain saya, dan @ditetapkan ke ghs.google.com. (CNAME), yang seharusnya tidak. Mengubah itu untuk @ 74.125.93.121 (A)* menyelesaikan masalah.

Saya memahami bahwa dalam kasus-kasus di mana surat tidak akan masuk, nama domain saya diganti dengan nama kanonik melalui pencarian CNAME, jadi surat itu dikirim ke myusername@ghs.l.google.comalih-alih myusername@mydomain.com. Tetapi mengapa itu bekerja untuk sebagian besar pengirim? Apakah pengirim yang suratnya tidak masuk, menggunakan beberapa jenis protokol surat yang berbeda, beberapa pengaturan DNS yang aneh, atau apa itu?

Dari apa yang dapat saya lihat dengan meneliti masalah di google, ini tampaknya menjadi masalah yang tersebar luas (banyak orang mengeluh tentang email dari battle.net tidak datang, akan menjadi salah satu contoh populer), hanya saja orang-orang tampaknya tidak untuk menyadari bahwa masalahnya terletak pada pengaturan DNS mereka sendiri, daripada di sisi pengirim.

Jadi bagaimana ini bisa dijelaskan?

^{* Saya menggunakan IP ini karena apa yang saya baca di sini , tapi saya pikir IP apa pun akan melakukan trik. Adakah yang bisa mengkonfirmasi ini? Perhatikan bahwa hanya menghapus @catatan tidak menyelesaikan masalah, itu harus diubah.}

— 0jam
sumber

Jawaban:

Dari RFC 2821 "Protokol Transfer Surat Sederhana", bagian 5 "Resolusi Alamat dan Penanganan Surat":

Pencarian pertama kali mencoba untuk menemukan catatan MX yang terkait dengan nama. Jika catatan CNAME ditemukan sebagai gantinya, nama yang dihasilkan diproses seolah-olah itu adalah nama awal.

Secara umum, ini adalah cara kerja CNAME. Mereka sering salah digunakan, salah dipahami, dan salah diimplementasikan. :-)

Jika domain Anda adalah example.com, Anda mungkin memiliki catatan MX yang ada yang menunjuk ke host Google Apps yang biasa.

example.com. MX 10 ASPMX.L.GOOGLE.COM.
example.com. MX 20 ALT1.ASPMX.L.GOOGLE.COM.
example.com. MX 20 ALT2.ASPMX.L.GOOGLE.COM.
example.com. MX 30 ASPMX2.GOOGLEMAIL.COM.
example.com. MX 30 ASPMX3.GOOGLMAILE.COM.
example.com. MX 30 ASPMX4.GOOGLEMAIL.COM.
example.com. MX 30 ASPMX5.GOOGLEMAIL.COM.

Sepertinya Anda juga memiliki entri seperti ini:

example.com. CNAME ghs.l.google.com.

RFC 1034 "Konsep dan Fasilitas Domain" menyatakan di bagian 3.6.2 "Alias dan nama kanonik" merekomendasikan terhadap konfigurasi ini:

Jika CN CNAME hadir di sebuah node, tidak ada data lain yang harus ada; ini memastikan bahwa data untuk nama kanonik dan aliasnya tidak boleh berbeda.

Dalam kasus kesalahan yang Anda tempelkan, server surat dan / atau server DNS di pihak pengirim mencoba untuk mencari data MX untuk domain Anda, example.com, dan menemukan CNAME menunjuk ke ghs.l.google. com. Kemudian mencoba mencari data MX untuk ghs.l.google.com. Domain itu saat ini tidak memiliki catatan MX apa pun, sehingga server email akan masuk ke catatan A untuk ghs.l.google.com. Alamat IP itu tidak mendengarkan pada port SMTP, jadi hasilnya adalah kesalahan "Koneksi habis waktu dengan ghs.l.google.com."

Dengan menghapus data CNAME, Anda telah memperbaiki masalah email Anda. Anda mungkin mengalami masalah jika alamat IP yang Anda tetapkan di tempatnya diubah di ujung Google.

Anda bisa mendefinisikan cname untuk www.example.com:

www.example.com. CNAME ghs.l.google.com.

Dan jalankan server web kecil pada IP apa pun yang Anda tunjuk example.com, yang hanya melakukan HTTP redirect ke http://www.example.com/

Agak mengejutkan bahwa itu bekerja sebaik itu. Hukum Postel mendapat pujian di sana, saya yakin. :-)

Kembali ke RFC 1034 2.6.2:

CNAME RRs menyebabkan tindakan khusus dalam perangkat lunak DNS. Ketika server nama gagal menemukan RR yang diinginkan dalam rangkaian sumber daya yang terkait dengan nama domain, itu memeriksa untuk melihat apakah kumpulan sumber daya terdiri dari catatan CNAME dengan kelas yang cocok. Jika demikian, server nama menyertakan catatan CNAME dalam respons dan mulai ulang kueri pada nama domain yang ditentukan dalam bidang data catatan CNAME. Satu-satunya pengecualian untuk aturan ini adalah bahwa kueri yang cocok dengan tipe CNAME tidak dimulai kembali.

Jadi, dalam hal ini dapat dikatakan bahwa server DNS akan / tidak boleh mengikuti CNAME pada pencarian MX kecuali tidak ada catatan MX ditemukan.

Saat mengirim surat, Sendmail dan qmail (dan kemungkinan orang lain) secara default akan mencoba menulis ulang CNAME yang digunakan di sebelah kanan alamat email ke nama kanonik.

Memang, beberapa situs mengandalkan perilaku ini. Djj merinci mengapa ia berpikir orang harus berhenti mengandalkan itu dalam dokumen "CNAME records in mail" nya .

— jeff
sumber

Terima kasih atas jawaban lengkap ini! :) Jadi untuk meringkas, Anda akan mengatakan bahwa alasan mengapa itu bekerja untuk beberapa tetapi tidak untuk pengirim lain, adalah bahwa mereka menggunakan MTA berbeda yang mengikuti CNAME meskipun ada catatan MX di sana, yang menurut RFC 1034 2.6.2 dapat dianggap perilaku yang salah?

— 0sh

Saya tidak yakin saya akan menyebut perilaku "salah". Konfigurasi CNAME dengan catatan lain (MX, NS, dll) adalah sesuatu yang rusak / tidak disarankan, dan host yang berbeda menafsirkannya dengan cara yang berbeda.

— jeff

Apakah itu 'umumnya ya' tetapi Anda tidak yakin Anda akan menyebut perilaku itu salah, atau apakah saya benar-benar kehilangan intinya?

— 0sh

Spesifikasinya berantakan, jadi 'umumnya ya' :-)

— jeff

MTA harus menanyakan domain setelah @alamat email untuk catatan MX dan tidak ada yang lain. Jika ada, itu harus segera mencoba pengiriman ke salah satu catatan MX terendah. Jika semua server MX gagal terhubung atau tidak ada catatan MX ditemukan, itu harus mencoba menghubungkan ke domain itu sendiri. MTA yang dimaksud jelas terlalu jauh dalam menyelesaikan informasi, atau tidak mengikuti aturan untuk menentukan server email mana yang akan disambungkan. Seharusnya tidak ada yang salah dengan mengarahkan domain Anda ke CNAME - tetapi Anda membutuhkan data MX agar email berfungsi.

— Eli Sand

The @simbol dalam catatan BIND adalah cara singkat menulis domain. Jika Anda membuat catatan untuk example.com, maka @itu hanyalah alias untuk example.com. Mengatakan bahwa @rekaman tersebut harus IP adalah pernyataan yang tidak memiliki informasi penting - Anda tidak memberi tahu kami jenis rekaman itu.

Dari laporan pengiriman, tampaknya Anda mungkin melakukan sesuatu dengan DNS Anda untuk menyebabkan server surat jarak jauh menulis ulang domain Anda ke ghs.l.google.com - sangat aneh (PS, catatan A harus berupa IP, catatan CNAME harus tidak menjadi catatan CNAME lain IP atau).

Mengapa server surat orang itu menulis ulang alamat Anda aneh - seharusnya tidak kecuali orang itu melakukan sesuatu untuk secara eksplisit menyuruhnya menulis ulang alamatnya. Seharusnya juga tidak peduli sama sekali apa IP domain Anda kecuali jika tidak dapat menemukan catatan MX, karena catatan MX adalah bagaimana server mail mencari tahu ke mana surat dikirimkan.

Kedengarannya bagi saya seperti, mengingat informasi yang diberikan sangat sedikit, bahwa Anda tidak mengikuti instruksi google tentang cara mengkonfigurasi DNS untuk email Anda sama sekali. Anda bahkan mungkin memiliki beberapa kesalahan dalam file zona Anda - memeriksanya oleh administrator zona yang kompeten.

— Eli Sand
sumber

Pertama, saya memang menyebutkan bahwa @catatan adalah tipe CNAME. Kedua, DNS yang saya gunakan adalah yang disediakan oleh google saat pembelian, oleh karena itu saya bahkan tidak memiliki akses ke file zona. Saya menggunakan pengaturan default yang disediakan oleh google. Dan yang tak kalah pentingnya, "informasi yang diberikan sangat sedikit" ternyata cukup bagi seseorang yang kompeten untuk memberikan jawaban yang ramah, memuaskan, dan (berbeda dengan Anda sendiri).

— 0sh

Anda jelas tidak mengerti DNS dan downvote sama sekali tidak beralasan. Anda juga mengedit pertanyaan Anda setelah saya memposting jawaban saya menambahkan informasi tambahan. Anda juga tidak pernah menyebutkan sekali bahwa Anda tidak memiliki akses ke file zona Anda meskipun dengan jelas menyebutkan bahwa Anda telah mengubahnya.

— Eli Sand