Mengapa RFC 7505 (Null MX) diperlukan?


18

IETF RFC 7505 menjelaskan catatan MX untuk domain / host yang secara eksplisit tidak boleh menerima email. Ini dilakukan dengan mengarahkan MX di root Domain Name System. Sebagai contoh,

nomail.example.com. 86400 IN MX 0 "."

Mengapa ini dibutuhkan? Dalam pemahaman saya, sangkalan eksplisit tersedia dengan menggunakan domain di bawah TLD invalid. Sebagai contoh,

nomail.example.com. 86400 IN MX 0 "spam.invalid."
nomail.example.com. 86400 IN MX 10 "null.invalid."

Saya melihat bahwa RFC 2782, DNS SRV, juga menentukan bahwa "Target '." berarti bahwa layanan ini jelas tidak tersedia di domain ini. " Jadi saya kira pertanyaan saya adalah:

Mengapa kita harus menggunakan root DNS berarti "tidak tersedia" ketika invalidsudah melayani fungsi ini?


2
Tapi itu bukan sangkalan eksplisit! Itu hanya data yang tidak valid.
Michael Hampton

Jawaban:


21

Karena bukan itu yang seharusnya Anda gunakan .invalid. Suka .exampleitu dimaksudkan untuk pengujian dan dokumentasi lokal.

Selain itu, menggunakan .invalidmasih menyebabkan hal-hal tambahan terjadi - DNS tambahan mencari dan mengantri pada server mail untuk mencoba lagi untuk salah satu dari atas kepala saya.

Menggunakan "."format seharusnya menyebabkan kegagalan langsung. Menyebabkan MTA untuk segera menghentikan upaya pengiriman. Setidaknya begitulah intro ke RFC dibaca.


2
Terima kasih. Bagian 2, tetapi BCP: 32 / RFC 2606 berbunyi "'.invalid' dimaksudkan untuk digunakan dalam konstruksi online nama domain yang pasti tidak valid dan sekilas jelas tidak valid." 2606 tidak mengatakan apa pun untuk menunjukkan bahwa ".invalid" hanya untuk pengujian lokal. Ini untuk domain apa pun yang harus, yah, tidak valid
Alpha Whiskey

Ok saya bisa melihat mengapa sesuatu yang sepertinya bisa menjadi nama host akan merugikan dibandingkan dengan "."
Alpha Whiskey

1
@AlphaWhiskey Ini untuk manusia yang bisa "melirik" sesuatu dan menarik kesimpulan. Komputer membutuhkan instruksi eksplisit.
Michael Hampton

3
Agar adil, tidak sulit untuk memberikan instruksi eksplisit pada komputer dalam kasus khusus ini.
muhmuhten

@res Bahkan lebih mudah untuk tidak memberikan instruksi eksplisit pada komputer.
musiKk

9

Pertanyaan secara keseluruhan menyentuh beberapa aspek berbeda yang semuanya perlu dipertimbangkan untuk menjawab mengapa RFC7505 menambahkan sesuatu yang bermanfaat.


Pertama-tama, definisi pra-RFC7505 tentang bagaimana pengiriman surat harus dilakukan tidak memiliki cara untuk menunjukkan dengan jelas bahwa tidak ada upaya pengiriman surat harus dilakukan untuk nama yang memiliki catatan alamat.

Dari RFC7505 bagian 1 :

Klien SMTP memiliki urutan yang ditentukan untuk mengidentifikasi server yang menerima email untuk domain. Bagian 5 dari [RFC5321] membahas hal ini secara rinci; pada dasarnya, klien SMTP pertama kali mencari DNS MX RR, dan, jika itu tidak ditemukan, ia kembali ke mencari DNS A atau AAAA RR. Karenanya, ini membebani catatan DNS (yang memiliki misi utama yang berbeda) dengan semantik layanan email.

Jika suatu domain tidak memiliki catatan MX, pengirim akan berusaha mengirimkan email ke host di alamat di catatan A atau AAAA domain. Jika tidak ada pendengar SMTP di alamat A / AAAA, pengiriman pesan akan dicoba berulang kali untuk jangka waktu yang lama, biasanya seminggu, sebelum Agen Pengiriman Surat pengiriman (MTA) menyerah. Ini akan menunda pemberitahuan kepada pengirim jika ada surat yang salah alamat dan akan menghabiskan sumber daya di pengirim.

Dokumen ini mendefinisikan MX null yang akan menyebabkan semua upaya pengiriman email ke domain gagal segera, tanpa memerlukan domain untuk membuat pendengar SMTP yang didedikasikan untuk mencegah upaya pengiriman.


Lalu ada masalah bagaimana RFC7505 mengimplementasikan ini ( IN MX 0 .).

Dari RFC7505 bagian 3 :

  1. Catatan Sumber Daya MX Menentukan Null MX

    Untuk menunjukkan bahwa suatu domain tidak menerima email, ia mengiklankan satu MX MX (lihat Bagian 3.3.9 dari [RFC1035]) dengan bagian RDATA yang terdiri dari nomor preferensi 0 dan label panjang nol, ditulis dalam file master sebagai ". ", sebagai domain pertukaran, untuk menyatakan bahwa tidak ada penukar email untuk suatu domain. Sejak "." bukan nama host yang valid, catatan MX nol tidak dapat dikacaukan dengan catatan MX biasa. Penggunaan "." sebagai pseudo-hostname yang berarti tidak ada layanan yang tersedia dimodelkan pada SRV RR [ RFC2782 ] di mana ia memiliki makna yang serupa.

    Domain yang mengiklankan MX null TIDAK HARUS mengiklankan MX RR lainnya.

(penekanan ditambahkan)

Seperti yang disebutkan di sini, detail implementasi untuk "null MX" didasarkan pada pola yang sudah ditetapkan dari SRVtipe RR. Masuk akal untuk meniru ini karena SRVtipe RR kurang lebih adalah versi umum dari MXtipe RR.

Jadi, keputusan itu pada dasarnya sudah diambil ketika mendefinisikan SRVtipe RR .


Jadi, mengapa tidak memanfaatkannya .invalid?

Dari RFC2606 section2 :

".invalid" dimaksudkan untuk digunakan dalam konstruksi daring nama domain yang pasti tidak valid dan sekilas jelas tidak valid.

Seperti dapat dilihat di sini, TLD yang dicadangkan ini adalah untuk konsumsi manusia. Tidak ada preseden mendefinisikan penanganan khusus ini dalam perangkat lunak.

Tentunya itu bisa diimplementasikan dengan cara yang berbeda tetapi mereka memilih untuk pergi dengan pendekatan minimal menggunakan ., yang bukan nama host yang valid dan dengan demikian tidak mengganggu penggunaan normal.


Sejauh yang saya tahu tidak ada alasan teknis yang .tidak dapat digunakan sebagai data MX jika catatan A atau AAAA telah diterbitkan di root. Ketika saya mengetiknya telnet . 25pasti mencari A dan AAAA records di root.
kasperd

1
@kasperd Meskipun protokol DNS pasti dapat mewakilinya, saya tidak percaya memiliki catatan alamat di .atau (pra-RFC7505) yang ditentukan .karena EXCHANGEnilai untuk MXcatatan sebenarnya akan valid. (Ini bukan nama host yang valid.)
Håkan Lindqvist

Valid atau tidak - Saya dapat dengan mudah membayangkan implementasi yang ketika dihadapkan dengan catatan MX yang menunjuk ke domain tanpa catatan A akan mencoba kembali pengiriman selama berhari-hari sebelum menyerah.
kasperd
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.