سؤال لماذا لا تستطيع سجلات MX توجيه عنوان IP؟


أفهمك لا يجب أشر إلى سجل MX على عنوان IP مباشرةً ، ولكن ينبغي بدلا من ذلك أشر إلى A سجل ، والذي بدوره يشير إلى عنوان IP لخادم البريد الخاص بك.

لكن من حيث المبدأ ، لماذا ا هل هذا مطلوب؟


84
2018-01-28 17:13


الأصل


إذا كان بإمكانك إعداد سجل MX ، يمكنك أيضًا إعداد سجل A. لا أرى المشكلة هنا. - joshudson
@ joshudson إنها ليست مشكلة على الإطلاق ، فقط أنا أحاول فهم السبب بدلاً من مجرد اتباع ما يفعله الآخرون. - dayuloli
أنا فقط حاولت في CloudFlare. لا يقبل عنوان IP كقيمة لسجل MX. - LinuxBabe


الأجوبة:


الفكرة الكاملة وراء سجل MX هي تحديد مضيف أو المضيفين والتي يمكن أن تقبل البريد للنطاق. كما هو محدد في RFC 1035، يحتوي سجل MX على اسم مجال. ولذلك يجب أن يشير إلى مضيف يمكن حل نفسه في DNS. لا يمكن استخدام عنوان IP لأنه سيتم تفسيره على أنه اسم نطاق غير مؤهل ، والذي لا يمكن حله.

أسباب هذا في 1980s ، عندما كانت المواصفات في الأصل مكتوبة ، هي تقريبا نفس الأسباب لذلك اليوم: قد يكون متصلا المضيف لشبكات متعددة واستخدام بروتوكولات متعددة.

في الثمانينيات ، لم يكن من غير المألوف وجود بوابات بريدية متصلة بالإنترنت (الجديد نسبيًا) الذي يستخدم بروتوكول TCP / IP والشبكات القديمة الأخرى التي غالبًا ما تستخدم بروتوكولات أخرى. يسمح تحديد MX بهذه الطريقة بسجلات DNS التي يمكنها تحديد كيفية الوصول إلى هذا المضيف على شبكة غير شبكة الإنترنت ، مثل Chaosnet. في الممارسة العملية ، على الرغم من هذا ، لم يحدث هذا تقريبا. أعاد الجميع تصميم شبكاتهم ليصبحوا جزءًا من الإنترنت بدلاً من ذلك.

اليوم ، الوضع هو أنه يمكن الوصول إلى مضيف بواسطة بروتوكولات متعددة (IPv4 و IPv6) وعناوين IP متعددة في كل بروتوكول. لا يمكن لسجل MX واحد أن يدرج أكثر من عنوان واحد ، وبالتالي فإن الخيار الوحيد هو الإشارة إلى المضيف ، حيث يمكن عندئذٍ البحث عن كل عناوين هذا المضيف. (كتحسين للأداء ، سيرسل ملقم DNS على طول سجلات العناوين الخاصة بالمضيف في قسم الرد الإضافي إذا كان يحتوي على سجلات موثوقة لهم ، مما يوفر رحلة ذهابًا وإيابًا.)

هناك أيضًا موقف ينشأ عندما يتم توفير مبادلات البريد الخاصة بك بواسطة طرف ثالث (مثل Google Apps أو Office 365). عند توجيه سجلات MX الخاصة بك إلى أسماء المضيف الخاصة بهم ، قد يحدث أن يحتاج مقدم الخدمة إلى تغيير عناوين IP لخوادم البريد. نظرًا لأنك قد أشرت إلى مضيف ، يمكن لمزود الخدمة القيام بذلك بشفافية وليس من الضروري إجراء أي تغييرات على سجلاتك.


84
2018-01-28 17:36



هذا لا يمنع حقا التوافق مع عناوين IP. في الواقع ، تعمل معظم خوادم / عملاء SMTP بشكل جيد مع عناوين IP في سجلات MX من الاختبار الصغير الذي قمت به. أعتقد أن النية كانت لتثبيط الصناعة من استخدام عناوين IP بشكل جماعي - وهو على الأرجح ما كان سيحدث ، لو لم يتم ذكر هذه القاعدة - وليس على أساس كل حالة على حدة. ومن ثم ، "ينبغي" ، في مقابل "يجب". +1 للحصول على معلومات كبيرة ، على الرغم من. لم افكر ابدا في معظم ذلك. - Zenexer
Zenexer قوانين المرور ليست هناك لإزعاج بعض السائقين الخبراء نسبيا الذين يعرفون بالضبط ما هو آمن وما هو ليس كذلك. فهي موجودة بسبب مجموعة فرعية أكبر بكثير من البلهاء اللعين يفكر يعرفون ما يفعلونه ولكنهم لا يفعلون. - Shadur
Zenexer قد تجد أن MTA معينة تتسامح معها اليوم ، ولا غدًا. هو ، بعد كل شيء ، ليس سلوكا يسمح به المعيار. وبالطبع ، لن تدعمه كل الاتفاقيات متعددة الوسائط ، لذا فإن القيام بذلك يعني ضمان فقدان البريد. - Michael Hampton♦
MichaelHampton: إذا كان لديك سجل MX ينبغي تحتوي على اسم مضيف بدلاً من عنوان IP ، ثم على MTA MUST قبول عنوان IP. بشكل افتراضي ، إذا كان سجل MX MUST تحتوي على اسم مضيف ثم MTA ينبغي قبول عنوان IP. هذه هي طريقة عمل RFC. قد يقوم الطرف المقابل لنصيحة التنفيذ "ينبغي" بتحسين افتراض أن النصيحة متبعة ، ولكن هذا إلى حد كبير كل ما يمكنك فعله به. - MSalters
MSalters أعتقد أنك مرتبك. لم أقل أبدا أن أفعل شيئًا. في الواقع ، قلت إن سجل MX يجب أن يحتوي على اسم مضيف ، وهو أيضًا ما يقوله RFC. - Michael Hampton♦


يحتوي DNS كبروتوكول على أنواع مختلفة من القيم ، وهذه ليست قابلة للتبادل.

من المهم ملاحظة أن DNS هو بروتوكول ثنائي مع تعيينات صارمة بين نوع السجل ونوع البيانات التي يحتفظ بها مثل هذا السجل.

فمثلا:
ل A سجل يحمل عنوان IPv4 (4 بايت من البيانات ، ثابت الطول).
ل AAAAسجل يحمل عنوان IPv6 (16 بايت من البيانات ، طول ثابت).

ل MX سجل ، من ناحية أخرى ، يحمل اسم (سلسلة من التسميات على الشكل <int number of bytes> <label> <int number of bytes> <label> <int 0>، متغير الطول).

ليست كذلك ممكنل MX سجل للحصول على عنوان IP كبياناته.


17
2018-01-28 17:34



يمكنك جعل التسمية التمثيل النصي لعنوان IP ، ولكن لن يكون من المنطقي القيام بذلك ، لأنه لا يمكن حلها كإسم مضيف. - Michael Hampton♦
MichaelHampton في الواقع ، من الممكن أن يكون لديك اسم يحمل تصنيفات رقمية بالكامل والتي تبدو في التمثيل الطبيعي الصديق للعامل مثل عنوان IPv4 للوهلة الأولى. هذا لا يغير أي شيء عندما يتعلق الأمر بالسؤال ، لأنه سيظل اسمًا ، وبالتالي سيتم التعامل معه كأنه اسم (اسم ، على الأقل على الإنترنت العام ، سيكون فقط NXDOMAIN). - Håkan Lindqvist
هذا لا يجيب حقا سؤال OP. أنت تقول في الأساس "لأن هذا هو الحال". - dr01
@ dr01 وبالنظر إلى أن السؤال يوضح بوضوح عدم إدراك "الطريقة" ("يجب ألا تشير إلى سجل MX على عنوان IP مباشرةً ، ولكن يجب بدلاً من ذلك أن تشير إلى سجل A" عندما يكون في الواقع غير ممكن لديك أي قيمة أخرى غير الاسم) ، لا أعتقد أنه في غير مكانه للإشارة إلى الطريقة التي تسير بها الأشياء ولماذا يجعل ذلك أي خيار آخر مستحيلاً. لدي شعور بأنك تقرأ الكثير في السؤال الذي لا يوجد في الواقع. - Håkan Lindqvist
@ dr01 أي لا تعتقد أن السؤال يقرأ كسؤال أكاديمي حول قرارات التصميم في الأيام الأولى من DNS أو أي شيء من هذا القبيل ، ولكن ببساطة سؤال حول كيفية MX السجلات الموجودة بالفعل في العالم يمكن أو يجب استخدامها. - Håkan Lindqvist


سأرمي هذا كتخمين. بالطبع ، أنا في المنزل مع الانفلونزا لذلك ربما أنا loopy.

ينص 974 RFC:

تتمثل الخطوة الأولى لارسال البريد في LOCAL في اصدار استعلام لمراجع MX      عن REMOTE. يحث بقوة أن يتم اتخاذ هذه الخطوة في كل مرة      يحاول mailer إرسال الرسالة. الأمل هو أن التغييرات في      سيتم استخدام قاعدة البيانات بسرعة من قبل البريد ، وبالتالي المجال      سيكون المديرون قادرين على إعادة توجيه رسائل النقل العام في      المضيفين المعيبة عن طريق تغيير قواعد بيانات المجال الخاصة بهم ببساطة.

من خلال طلب اسم بدلا من الملكية الفكرية ، فإنه يشجع بقوة هذه الممارسة. يمكن أن تظل الأسماء كما هي ، وفي حالة موازنة الحمل أو DR لن تضطر إلى القلق بشأن تغيير سجل MX نفسه وانتظار نشر DNS.


6
2018-01-28 17:40



الإجابة على أسئلة تبادل المكدس في يومك أثناء إصابتك بمرض الإنفلونزا ... أنا تلميح قبعتي لك ، يا سيدي الجيد! - Mike B
MikeB شكرا ... - TheCleaner


بعض خوادم البريد الإلكتروني (مثل exim) لا تسمح على وجه التحديد بالإرسال إلى سجلات MX التي تشير إلى عنوان IP خالص ، لذلك يجب عليك استخدام FQDN بدلاً من أن تكون متوافقة. ويرجع ذلك إلى أن معظم الخوادم تتوقع أن يحتوي سجل MX على اسم مضيف ، وليس عنوان IP (وهو ما تمثله سجلات A).

تحرير: لوضع ، في DNS كل سجل لديه متطلبات صارمة لنوع البيانات يمكن لكل سجل عقد. في حالة سجلات MX ، يكون اسم المضيف فقط.


2
2018-01-28 17:29



إذن لماذا لم يسمح exim بسجل MX إلى عنوان IP في المقام الأول؟ يبدو غريبا بالنسبة لي! أنا أفهم أنا لا ينبغي بسبب الاتفاقية ، لكنني لا أفهم لماذا ا صنعت من غير شرعي. - dayuloli
لا أرى كيف يمكن لأي MTA دعم هذا باعتباره MX لا يمكن أن يحتوي السجل على عنوان IP كقيمة له. - Håkan Lindqvist
@ HåkanLindqvist إجابتك أعلاه توضح هذه النقطة بالنسبة لي! شكرا لكم! - dayuloli


في سجلات RFC 1025 MX ، أشر فقط إلى RR (سجل المورد) لسجل A أو CNAME.

لذا فإن خادم البريد الذي يرسل البريد يسأل عن سجل RR لسجل MX ، يسرد سجل mx سجلات الخوادم ، يقوم خادم البريد بإجراء بحث إلى الأمام للحصول على سجل A ، ثم يعيد توجيه البريد عبر بروتوكول smtp إلى مضيف الخدمة المدرج كـ خادم البريد "على استعداد" لتلقي البريد لهذا المجال.

سؤالك - لماذا لا يمكن إرسال البريد إلى عنوان IP

استجابة - بسبب الثقة

لقد تطورت العديد من القواعد المطبقة فيما يتعلق بالبريد من أجل الحفاظ على الثقة بين النطاقات التي تكون الرسائل المرسلة للخلف وللأمام صالحة بالفعل. كل هذا هو تقليل الرسائل الاقتحامية (SPAM).

  • عكس بحث IP
  • A Forward Name lookup for that matter

كل هذه المكونات الأساسية لمؤسسة لإنشاء خادم بريد عليها على الأقل مكون صغير مؤسس على إنشاء اتصالات جديرة بالثقة وتقليل الاتصالات غير الموثوق بها.

المرجع - RFC 1035 و 974

https://www.ietf.org/rfc/rfc1035.txt35

https://www.ietf.org/rfc/rfc974.txt


2
2018-01-28 17:42





الغرض من MXالسجلات هي أن الوضعية (نقل البريد) يمكن التعرف على المضيف الذي سيتم استخدامه. على مستوى التطبيق ، المضيف أسماء هي الشيء الصحيح لاستخدام (وليس عناوين IP).

أيضا ، إضافة conceot من نوع السجل المتغير إلى DNS يقدم leverl من التعقيد ، وبالتالي نقطة دخول للمشاكل ، والتنفيذ المؤسف ، والتحديات الأمنية. فمثلا، 1.2.3.4.example.com. اسم مضيف صالح (نعم ، هو ، حتى في ضوء RFC1034 ، 3.5). تحديد هذا المضيف باسم MX في ملف تكوين الربط ل example.com قد يبدو

.  MX 10  1.2.3.4

ويفترض أن هذا هو بالضبط نفس سجل MX مع IP ينبغي أن تبدو. وحتى لنقل المعلومات في نظام بيانات DNS يتطلب بعض الإضافات الغريبة. أبسط طريقة هي تقديم الجديد نوع سجل المورد ، MXA قل ، من أجل توضيح. ولكن مرة أخرى ، لماذا تقديم مثل هذا النوع الجديد من السجل عندما

. MXA 10 5.6.7.8

يمكن دائما الاستعاضة عنها

. MX 10 dummy
dummy A 5.6.7.8

(وسوف يدعمها أيضا عملاء DNS لا يعرفون عنه MXA السجلات)؟


2
2018-01-31 21:49