Dalam keadaan apa (jika ada) seharusnya catatan MX menunjuk ke localhost?


8

Saya berpikir bahwa sama sekali tidak ada alasan atau pembenaran untuk ini, tetapi sebelum saya membuka mulut dan mendapatkan admin dalam kimchi yang dalam, saya pikir saya harus bertanya.

Apakah ada setiap keadaan di mana catatan MX harus menunjuk ke alamat loopback? Bagi saya, ini mengatakan server email yang mencoba mengirim ke domain ini akan mengirim ke mereka sendiri, dan gagal, tapi saya bukan guru email, jadi mungkin saya kehilangan sesuatu.

Saya menemukan di bawah ini ketika memecahkan masalah mengapa-tidak-kita-mendapatkan-email ?? masalah untuk klien, dan saya mengalami kesulitan membungkus kepala saya di sekitarnya. Mungkin aku terlalu memikirkan hal-hal lain.

masukkan deskripsi gambar di sini


7
Ini pada dasarnya mengatakan, jangan mengirim email kepada kami ... bicara dengan tangan
Mike Pennington

@ MikePennington Jika Anda ingin tidak mendapatkan formulir email siapa pun, mengapa Anda melakukan ini alih-alih, misalnya, menghapus data MX Anda?
HopelessN00b

5
jika Anda menghapus data MX, email dikirim ke data A untuk bagian domain dari alamat email. tanpa catatan MX, Anda mendapatkan banyak orang mengetuk pintu Anda mencari server email yang tidak menjawab. dengan alamat loopback, pengirim mengetuk pintu mereka sendiri dan tidak membuang-buang bandwidth Anda.
longneck

@ Longneck Itulah hasil akhirnya, tapi itu mungkin bukan cara terbaik untuk melakukannya. IMHO mencemari DNS publik adalah langkah yang cukup untuk menyingkirkan spammer yang hanya akan dikenakan biaya beberapa byte untuk RSTpaket jika Anda tidak menjalankan server email ...
voretaq7

Saya tidak mengatakan itu ide yang bagus. saya baru saja menjelaskan apa yang terjadi ketika Anda menghapus data MX Anda, dan bagaimana menghapus data MX tidak mereplikasi konfigurasi yang ditanyakan.
longneck

Jawaban:


4

Jawaban singkat: Seharusnya tidak.

Jawaban panjang: Jika domain yang dipermasalahkan (DIQ) tidak boleh menerima email, maka memasukkan alamat loopback ke dalam data MX menyebabkan server pengirim mencoba untuk terhubung dengan dirinya sendiri. Ini menghemat DIQ beberapa byte byte dan mungkin membersihkan log firewall (jika ada yang bahkan menonton) ketika server mail lain mencoba untuk terhubung. Namun, menurut saya, penghematan bandwidth tidak cukup untuk membenarkan pelanggaran RFC 3330.


10

Jelas TIDAK, bukan dengan IP 127.0.0.0. Seluruh rentang 127.0.0.0 pada IPv4 berfungsi sebagai alamat loopback, jadi ketika mesin apa pun terhubung ke IP dalam rentang itu, ia akan mencoba untuk terhubung ke dirinya sendiri.

Alamat IP rekaman MX Anda harus dapat diakses dari dunia luar dan apa hasilnya memberitahu server mana pun yang melakukan kueri MX, untuk mencoba terhubung dengan dirinya sendiri.

Jika server saya mencoba mengirimi Anda email, itu akan mencari data MX dan kemudian menghubungkan alamat IP-nya sendiri, mengirim email dan gagal.


1
+1 - TIDAK ADA alasan bagus untuk PERNAH mengatur catatan DNS publik ke alamat di 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, atau 192.168.0.0/8 ... (Seperti semua "aturan" internet tentu saja dapat Anda abaikan, tetapi Anda melakukannya dengan risiko sendiri, dan hanya harus melakukannya dengan pengetahuan penuh tentang apa yang Anda lakukan dan mengapa ...)
voretaq7

@ voretaq7warez IN A 127.0.0.1
Michael Hampton

@MichaelHampton dilayani dari DNS publik yang menghadap dunia? Saya cukup yakin ada sesuatu dalam RFC yang mengatakan hal itu sama dengan menenggelamkan anak kucing ...
voretaq7

@ voretaq7 Ya, saya pernah melihatnya, dan di banyak tempat. Tanggal setidaknya kembali ke 1990-an. Cara itu digunakan adalah: seseorang akan bertanya di mana menemukan warez, dan diberi alamat warez.example.comyang memiliki catatan khusus ini ...
Michael Hampton

6

RFC yang relevan mengatakan:

  • Catatan sumber daya MX HARUS menunjuk ke nama domain yang sepenuhnya memenuhi syarat (bukan alamat IP) dari server di Internet publik yang menerima email untuk domain tersebut. Perhatikan bahwa server ini tidak harus berada di domain yang sama dengan catatan MX. RFC 1035 bagian 3.3.9

  • Alamat dalam kisaran 127.0.0.0/8 HARUS tidak pernah muncul di Internet publik. RFC 5735 bagian 3

Perhatikan bahwa beberapa server email akan menolak email dari pengirim yang tidak mematuhi RFC yang relevan .


4

Ketika sebuah host harus dapat mengirim email ke dirinya sendiri di berbagai domain yang dihosting tetapi tidak menerima email eksternal, "MX 0 localhost." bisa diterima. Untuk menunjukkan bahwa suatu host tidak memiliki server mail sama sekali, gunakan "MX 0."

"MX 0." dirinci dalam RFC7505 .


3

Yah, saya punya situasi di mana pengaturan MX domain ke localhost tampaknya diperlukan.

Pada bulan Maret 2012 saya mendaftarkan domain lucu yang saya terkejut menemukan tersedia. Itu untuk situs kolaborasi artistik yang ingin didirikan oleh putriku. Saya mengatur MX ke salah satu server smtp saya yang lain. Ini bekerja dengan baik, tetapi kemudian saya mulai mendapatkan banyak bouncing email "pengguna tak dikenal" ke xxx@cute-domain.com (bukan nama domain asli). Jadi saya menggunakan MailScanner untuk memblokir semua pesan masuk ke domain itu kecuali untuk satu alamat yang sah. Tampaknya domain tersebut adalah layanan email gratis mulai tahun 2001 tetapi tampaknya sudah gelap dan menyerahkan nama domain imut mereka.

Ini bekerja dengan baik hingga beberapa hari yang lalu (11/20/12) ketika server smtp mulai menolak pesan masuk karena koneksi terbuka yang berlebihan. Ini adalah proses smtp menunggu respons "tanda terima", saya kira. Saya melihat lalu lintas dan saya dibombardir oleh ribuan pesan masuk untuk xxx@cute-domain.com dari banyak relay smtp di seluruh dunia. (17.000 pesan dalam satu periode 24 jam)

Jadi saya mengubah MX untuk menunjuk ke server lain yang tidak menjalankan smtp dengan port 25 diblokir. Benar saja, ribuan sesi yang dibatalkan mulai muncul. Karena perilaku ini terlihat seperti semacam torrent spam, mungkin dari botnet, saya menduga bahwa pengaturan MX ke localhost mungkin diperlukan.

Saya akan membiarkannya seperti ini sebentar. Kami sama sekali tidak memerlukan email untuk cute.domain.com, jadi tidak ada yang hilang kecuali siklus untuk botnet.


-1

Mengapa tidak menggunakan target MX yang tidak menyelesaikan apa pun? Misalnya:

example.com. DALAM MX 10 sesuatu. Tidak valid.

Spammer akan melihat kesalahan resolusi dan tidak repot-repot dengan catatan MX berikutnya, mengira targetnya salah dikonfigurasi. Server nyata akan mencoba catatan berikutnya. Ini tidak akan mengganggu port TCP 25 yang ditutup siapa pun - yaitu tidak ada lalu lintas smtp, hanya DNS.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.