ฉันเข้าใจว่าคุณไม่ควรชี้ระเบียน MX ที่ที่อยู่ IP โดยตรง แต่ควรชี้ไปที่A
ระเบียนซึ่งในทางกลับกันชี้ไปที่ที่อยู่ IP ของเซิร์ฟเวอร์อีเมลของคุณ
แต่โดยหลักการแล้วทำไมต้องมีสิ่งนี้
ฉันเข้าใจว่าคุณไม่ควรชี้ระเบียน MX ที่ที่อยู่ IP โดยตรง แต่ควรชี้ไปที่A
ระเบียนซึ่งในทางกลับกันชี้ไปที่ที่อยู่ IP ของเซิร์ฟเวอร์อีเมลของคุณ
แต่โดยหลักการแล้วทำไมต้องมีสิ่งนี้
คำตอบ:
แนวคิดทั้งหมดที่อยู่เบื้องหลังระเบียน MX คือการระบุโฮสต์หรือโฮสต์ที่สามารถยอมรับอีเมลสำหรับโดเมน ตามที่ระบุในRFC 1035เรคคอร์ด MX มีชื่อโดเมน ดังนั้นจึงต้องชี้ไปที่โฮสต์ซึ่งสามารถแก้ไขได้ใน DNS ไม่สามารถใช้ที่อยู่ IP ได้เนื่องจากจะถูกตีความว่าเป็นชื่อโดเมนที่ไม่ผ่านการรับรองซึ่งไม่สามารถแก้ไขได้
เหตุผลของเรื่องนี้ในช่วงปี 1980 เมื่อมีการเขียนรายละเอียดไว้เกือบจะเหมือนกับเหตุผลในปัจจุบัน: โฮสต์อาจเชื่อมต่อกับหลายเครือข่ายและใช้โปรโตคอลหลายตัว
ย้อนกลับไปในยุค 80 ไม่ใช่เรื่องแปลกที่จะมีเกตเวย์จดหมายที่เชื่อมต่อกับอินเทอร์เน็ต (ค่อนข้างใหม่) ซึ่งใช้ TCP / IP และเครือข่ายดั้งเดิมอื่น ๆ ซึ่งมักใช้โปรโตคอลอื่น ระบุ MX ในลักษณะนี้ได้รับอนุญาตให้ระเบียน DNS ซึ่งสามารถระบุวิธีการเข้าถึงเช่นโฮสต์บนเครือข่ายอื่น ๆ ที่นอกเหนือจากอินเทอร์เน็ตเช่นChaosnet ในทางปฏิบัติแม้ว่าสิ่งนี้แทบไม่เคยเกิดขึ้นเลย แทบทุกคนทำการออกแบบเครือข่ายใหม่เพื่อเป็นส่วนหนึ่งของอินเทอร์เน็ตแทน
วันนี้สถานการณ์คือโฮสต์อาจเข้าถึงได้โดยหลายโปรโตคอล (IPv4 และ IPv6) และตามที่อยู่ IP หลายแห่งในแต่ละโปรโตคอล ระเบียน MX เดียวไม่สามารถแสดงรายการที่อยู่มากกว่าหนึ่งรายการได้ดังนั้นตัวเลือกเดียวคือชี้ไปที่โฮสต์ซึ่งที่อยู่ทั้งหมดของโฮสต์นั้นจะสามารถค้นหาได้ (เพื่อเพิ่มประสิทธิภาพการทำงานเซิร์ฟเวอร์ DNS จะส่งเรคคอร์ดที่อยู่สำหรับโฮสต์ในส่วนการตอบสนองเพิ่มเติมหากมีระเบียนที่เชื่อถือได้สำหรับพวกเขาและบันทึกการเดินทางไปกลับ)
นอกจากนี้ยังมีสถานการณ์ที่เกิดขึ้นเมื่อมีการแลกเปลี่ยนจดหมายของคุณโดยบุคคลที่สาม (เช่น Google Apps หรือ Office 365) คุณชี้ระเบียน MX ของคุณไปที่ชื่อโฮสต์ แต่อาจเกิดขึ้นได้ว่าผู้ให้บริการต้องเปลี่ยนที่อยู่ IP ของเซิร์ฟเวอร์อีเมล เมื่อคุณชี้ไปที่โฮสต์ผู้ให้บริการสามารถทำสิ่งนี้ได้อย่างโปร่งใสและคุณไม่ต้องทำการเปลี่ยนแปลงใด ๆ กับบันทึกของคุณ
DNS ในฐานะโปรโตคอลมีค่าชนิดต่างกันค่าเหล่านี้ไม่สามารถแลกเปลี่ยนกันได้
สิ่งสำคัญคือให้สังเกตว่า DNS เป็นโพรโทคอลไบนารีที่มีการแมปที่เข้มงวดระหว่างประเภทของเรกคอร์ดและชนิดของข้อมูลที่เรกคอร์ดนั้นเก็บ
ตัวอย่างเช่น: บันทึกถืออยู่ IPv4 (4 ไบต์ของข้อมูล, ความยาวคงที่) บันทึกถืออยู่ IPv6 (16 ไบต์ของข้อมูล, ความยาวคงที่) A
AAAA
MX
บันทึกบนมืออื่น ๆ ที่ถือเป็นชื่อ (ลำดับของป้ายชื่อบนรูปแบบที่<int number of bytes> <label> <int number of bytes> <label> <int 0>
ยาวตัวแปร)
เป็นไปไม่ได้ที่MX
ระเบียนจะมีที่อยู่ IP เป็นข้อมูล
NXDOMAIN
)
MX
บันทึกที่มีอยู่จริงในโลกสามารถหรือควรใช้
ฉันจะโยนมันออกไปเป็นการเดา แน่นอนว่าฉันอยู่บ้านกับไข้หวัดใหญ่ดังนั้นบางทีฉันอาจจะเป็นวงแหวน
RFC 974 รัฐ:
ขั้นตอนแรกสำหรับจดหมายที่ LOCAL คือการออกแบบสอบถามสำหรับ MX RRs สำหรับ REMOTE ขอแนะนำอย่างยิ่งให้ทำตามขั้นตอนนี้ทุกครั้งที่ผู้ส่งจดหมายพยายามส่งข้อความ ความหวังคือการเปลี่ยนแปลงในฐานข้อมูลโดเมนจะถูกใช้อย่างรวดเร็วโดยผู้ส่งจดหมายและผู้ดูแลโดเมนจะสามารถกำหนดเส้นทางข้อความระหว่างทางสำหรับโฮสต์ที่มีข้อบกพร่องได้โดยเพียงแค่เปลี่ยนฐานข้อมูลโดเมน
ด้วยการกำหนดชื่อแทนที่จะเป็น IP จะเป็นการส่งเสริมการปฏิบัตินี้ ชื่อสามารถคงเดิมและในกรณีที่โหลดบาลานซ์หรือ DR คุณไม่ต้องกังวลเกี่ยวกับการเปลี่ยนแปลงระเบียน MX และรอการเผยแพร่ DNS
เซิร์ฟเวอร์อีเมลบางตัว (เช่น exim) โดยเฉพาะไม่อนุญาตให้ส่งไปยังระเบียน MX ที่ชี้ไปยังที่อยู่ IP จริงดังนั้นคุณต้องใช้ FQDN แทนเพื่อให้เป็นไปตามมาตรฐาน เนื่องจากเซิร์ฟเวอร์ส่วนใหญ่คาดว่าระเบียน MX จะมีชื่อโฮสต์ไม่ใช่ IP (นั่นคือสิ่งที่ระเบียน A ใช้สำหรับ)
แก้ไข: เพื่ออธิบายรายละเอียดใน DNS แต่ละเรคคอร์ดมีข้อกำหนดที่เข้มงวดสำหรับประเภทของข้อมูลที่เรคคอร์ดสามารถเก็บได้ ในกรณีของระเบียน MX มันเป็นชื่อโฮสต์เท่านั้น
MX
ระเบียนไม่สามารถมีที่อยู่ IP เป็นค่าได้
ในระเบียน RFC 1025 MX ให้ชี้ไปที่ RR (ระเบียนทรัพยากร) ของ A Record หรือ CNAME
ดังนั้นเมลเซิร์ฟเวอร์ที่ส่งเมลจะขอ RR ของเรคคอร์ด MX รายการ mx เรคคอร์ด A ของเซิร์ฟเวอร์เมลเซิร์ฟเวอร์จะทำการค้นหาไปข้างหน้าเพื่อรับเร็กคอร์ด A จากนั้นส่งต่อเมลผ่าน smtp ไปยังโฮสต์ของบริการที่แสดงรายการเป็น เซิร์ฟเวอร์จดหมาย 'ยินดี' เพื่อรับจดหมายสำหรับโดเมนนั้น
กฎหลายข้อที่เกี่ยวข้องกับเมลได้รับการพัฒนาเพื่อรักษาความไว้วางใจระหว่างโดเมนว่าข้อความที่ส่งไปมานั้นถูกต้องจริง ทั้งหมดนี้เพื่อลด SPAM ในที่สุด
ส่วนประกอบที่จำเป็นทั้งหมดเหล่านี้สำหรับรากฐานในการสร้างเซิร์ฟเวอร์อีเมลนั้นมีส่วนประกอบเล็ก ๆ น้อย ๆ ที่ก่อตั้งขึ้นในการสร้างการสื่อสารที่น่าเชื่อถือและลดการสื่อสารที่ไม่น่าเชื่อถือ
วัตถุประสงค์ของการMX
บันทึกคือแอปพลิเคชัน (การถ่ายโอนอีเมล) สามารถเรียนรู้เกี่ยวกับโฮสต์ที่จะใช้ ในระดับแอปพลิเคชันชื่อโฮสต์เป็นสิ่งที่ถูกต้องที่จะใช้ (ไม่ใช่ที่อยู่ IP)
นอกจากนี้การเพิ่มจุดซ่อนเร้นของเรคคอร์ดประเภทตัวแปรลงใน DNS จะทำให้เกิดความยุ่งยากและด้วยเหตุนี้จึงเป็นจุดเริ่มต้นของปัญหาการใช้งานผิดพลาดความท้าทายด้านความปลอดภัย ตัวอย่างเช่น1.2.3.4.example.com.
เป็นชื่อโฮสต์ที่ถูกต้อง (ใช่มันคือแม้ในแง่ของ RFC1034, 3.5) การระบุโฮสต์นี้MX
ในไฟล์การกำหนดค่า bind สำหรับ example.com อาจมีลักษณะดังนี้
. MX 10 1.2.3.4
และสันนิษฐานว่าเป็นระเบียน MX ที่เหมือนกันกับ IP อย่างแม่นยำ และแม้กระทั่งการถ่ายโอน informatoin ใน DNS datagram ต้องมี additoins ที่แปลกตา วิธีที่ง่ายที่สุดคือแนะนำประเภทระเบียนทรัพยากรใหม่MXA
สำหรับการแก้ความกำกวม แต่แล้วอีกครั้งทำไมแนะนำภาระเช่นชนิดบันทึกใหม่เมื่อ
. MXA 10 5.6.7.8
อาจถูกแทนที่ด้วย
. MX 10 dummy
dummy A 5.6.7.8
(และจะได้รับการสนับสนุนจากไคลเอนต์ DNS ด้วยซึ่งไม่ทราบเกี่ยวกับMXA
บันทึก)