ทำไม RFC 7505 (Null MX) จึงมีความจำเป็น

IETF RFC 7505อธิบายระเบียน MX สำหรับโดเมน / โฮสต์ที่ไม่ควรรับอีเมลอย่างชัดเจน สิ่งนี้สามารถทำได้โดยการชี้ MX ที่รูทของระบบชื่อโดเมน ตัวอย่างเช่น,

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

ทำไมถึงจำเป็น ในความเข้าใจของฉันพิสูจน์อย่างชัดเจนสามารถใช้ได้โดยการใช้โดเมนภายใต้ invalidTLD ตัวอย่างเช่น,

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

ฉันเห็นว่า RFC 2782, DNS SRV เช่นเดียวกันระบุว่า "A Target of '.' หมายความว่าบริการนี้จะไม่สามารถใช้งานได้ในโดเมนนี้ " ดังนั้นฉันคิดว่าคำถามของฉันคือ:

ทำไมเราควรใช้รูท DNS เพื่อหมายถึง "ไม่พร้อมใช้งาน" เมื่อinvalidทำหน้าที่ฟังก์ชั่นนี้แล้ว?

เพราะนั่นไม่ใช่สิ่งที่คุณควรจะใช้.invalidสำหรับ ชอบ.exampleมันมีไว้สำหรับการทดสอบในท้องถิ่นและเอกสาร

นอกจากนี้การใช้.invalidยังทำให้เกิดสิ่งเพิ่มเติมเกิดขึ้น - การค้นหา DNS เพิ่มเติมและการจัดคิวบนเซิร์ฟเวอร์อีเมลเพื่อลองใหม่หนึ่งครั้งที่ด้านบนของหัวของฉัน

การใช้"."รูปแบบควรทำให้เกิดความล้มเหลวทันที ทำให้ MTA หยุดการพยายามส่งมอบทันที อย่างน้อยนั่นเป็นวิธีที่คำนำของ RFC อ่าน

คำถามโดยรวมสัมผัสกับแง่มุมที่แตกต่างกันเล็กน้อยซึ่งทุกคนจะต้องนำมาพิจารณาเพื่อตอบว่าทำไม RFC7505 จึงเพิ่มบางสิ่งที่มีประโยชน์

ก่อนอื่นคำจำกัดความก่อน RFC7505 ของวิธีการส่งจดหมายควรไม่มีวิธีที่จะบ่งบอกได้อย่างชัดเจนว่าไม่ควรพยายามส่งจดหมายสำหรับชื่อที่มีบันทึกที่อยู่

จากRFC7505 ส่วนที่ 1 :

ไคลเอ็นต์ SMTP มีลำดับที่กำหนดไว้สำหรับการระบุเซิร์ฟเวอร์ที่รับอีเมลสำหรับโดเมน ส่วนที่ 5 ของ [RFC5321] ครอบคลุมรายละเอียดนี้ โดยพื้นฐานแล้วไคลเอนต์ SMTP จะค้นหา DNS MX RR เป็นอันดับแรกและหากไม่พบก็จะย้อนกลับไปค้นหา DNS A หรือ AAAA RR ดังนั้นการทำเช่นนี้จึงทำให้โอเวอร์โหลดระเบียน DNS (ที่มีภารกิจหลักแตกต่างกัน) ที่มีความหมายของบริการอีเมล

หากโดเมนไม่มีระเบียน MX ผู้ส่งจะพยายามส่งจดหมายไปยังโฮสต์ตามที่อยู่ในระเบียน A หรือ AAAA ของโดเมน หากไม่มีผู้ฟัง SMTP ที่ที่อยู่ A / AAAA การส่งข้อความจะพยายามซ้ำ ๆ กันเป็นเวลานานโดยทั่วไปหนึ่งสัปดาห์ก่อนที่จะส่ง Mail Transfer Agent (MTA) การทำเช่นนี้จะทำให้การแจ้งเตือนล่าช้าไปยังผู้ส่งในกรณีที่ส่งเมลผิดและจะใช้ทรัพยากรที่ผู้ส่ง

เอกสารนี้กำหนด MX null ที่จะทำให้การส่งจดหมายทั้งหมดพยายามโดเมนล้มเหลวทันทีโดยไม่ต้องมีโดเมนเพื่อสร้างฟัง SMTP โดยเฉพาะเพื่อป้องกันการพยายามจัดส่ง

ถ้าอย่างนั้น RFC7505 จะนำสิ่งนี้ไปใช้ ( IN MX 0 .)

จากRFC7505 ส่วนที่ 3 :

3. ระเบียนทรัพยากร MX ระบุ Null MX

   หากต้องการระบุว่าโดเมนไม่ยอมรับอีเมลจะทำการโฆษณา MX RR หนึ่งรายการ (ดูหัวข้อ 3.3.9 ของ [RFC1035]) ด้วยส่วน RDATA ซึ่งประกอบด้วยหมายเลขการกำหนดค่า 0 และป้ายกำกับที่มีความยาวเป็นศูนย์ซึ่งเขียนในไฟล์ต้นแบบเป็น " "เป็นโดเมนแลกเปลี่ยนเพื่อแสดงว่าไม่มีตัวแลกเปลี่ยนเมลสำหรับโดเมน ตั้งแต่ "." ไม่ใช่ชื่อโฮสต์ที่ถูกต้องเรคคอร์ด MX ไม่สามารถสับสนกับเรคคอร์ด MX ทั่วไป การใช้ "." ในฐานะที่เป็นชื่อเทียมโฮสต์หมายถึงไม่มีบริการที่มีอยู่ใน SRV RR [ RFC2782 ] ซึ่งมีความหมายคล้ายกัน

   โดเมนที่โฆษณา MX ปลอดค่าต้องไม่โฆษณา MX RR อื่นใด

(เน้นเพิ่ม)

ดังที่ระบุไว้ที่นี่รายละเอียดการใช้งานสำหรับ "null MX" จะขึ้นอยู่กับรูปแบบที่กำหนดไว้แล้วจากSRVประเภท RR มันสมเหตุสมผลที่จะเลียนแบบสิ่งนี้เพราะSRVประเภท RR มากหรือน้อยเป็นรุ่นทั่วไปของMXประเภท RR

ดังนั้นการตัดสินใจที่ถูกนำมาเป็นหลักแล้วในขณะที่การกำหนดประเภทSRV RR

ดังนั้นทำไมไม่ใช้ประโยชน์จาก.invalid?

จากRFC2606 section2 :

".invalid" มีไว้สำหรับใช้ในการสร้างชื่อโดเมนออนไลน์ที่แน่ใจว่าไม่ถูกต้องและเห็นได้อย่างรวดเร็วว่าไม่ถูกต้อง

ดังที่เห็นที่นี่ TLD ที่สงวนไว้นี้มีไว้สำหรับการบริโภคของมนุษย์ ไม่มีแบบอย่างของการกำหนดการจัดการพิเศษนี้ในซอฟต์แวร์

แน่นอนว่าอาจมีการใช้งานในลักษณะที่แตกต่างกันบ้าง แต่พวกเขาเลือกที่จะใช้วิธีการใช้งานน้อยที่สุด.ซึ่งไม่ใช่ชื่อโฮสต์ที่ถูกต้องและไม่รบกวนการใช้งานปกติอย่างไรก็ตาม