تقوم سجلات A وAAAA بتعيين اسم مضيف لعناوين IPv4 و IPv6 . إنها تبعيات لخدمة البريد، وليست إعلانات بأن الخدمة جاهزة أو مصرح لها بإرسالها. يمكن أن يؤدي نشر عنوان إلى الكشف عن المسار الذي يحاوله العملاء فعليًا، لذا تحقق من كل عائلة ونقطة نهاية مُعلن عنها.
اتبع الاسم المستخدم بواسطة البروتوكول
مراجع: RFC 5321 §5.1, RFC 7208 §5.3, RFC 7208 §5.4.
بالنسبة لـ SMTP الوارد، قم بحل أسماء مضيفي التبادل التي يتم إرجاعها بواسطة MX . لا يعد عنوان موقع الويب الخاص بمجال المستلم بديلاً عندما تكون عمليات التبادل الصريحة غير قابلة للاستخدام. في حالة عدم وجود MX ، يمكن لقاعدة MX الضمنية لـ SMTP أن تجعل سجلات A أو AAAA الخاصة بمجال المستلم ذات صلة بدلاً من ذلك.
للخارج SPF، وفحص السياسة الفعلية والهوية المقيّمة. ان a يمكن للآلية أن تسمح بالعناوين التي يتم إرجاعها لاسمها المحدد؛ سهل سجل لا يأذن بأي شيء في حد ذاته. وبالمثل، تغيير اسم المضيف الذي يستخدمه نظام التعرف على SPF مكس يمكن لآلية تغيير العناوين التي تم تقييمها على النحو المصرح به. قم بتسجيل هذه المراجع قبل التعامل مع تعديل عنوان DNS كتغيير لموقع الويب فقط.
تعامل مع المكدس المزدوج كمسارين للتشغيل
مراجع: RFC 1035 §3.4.1, RFC 3596 §2.1, RFC 3596 §2.3.
يمكن أن يحتوي اسم المضيف على عدة سجلات A والعديد من سجلات AAAA. إن وجودهم لا يضمن إمكانية الوصول أو خدمة SMTP أو الشهادة الصحيحة أو السياسة المكافئة. لا تثبت نقطة نهاية IPv4 السليمة أن IPv6 يعمل. وعلى العكس من ذلك، فإن الفشل في مسار عميل واحد لا يثبت أن كل مرسل يستخدم هذا المسار.
التقط عنوان الوجهة الذي تمت محاولته بالفعل، وعنوان العائلة، ونتائج الاتصال، واستجابة SMTP . في حالة التحقيق في حركة المرور الصادرة، التقط عنوان المصدر الذي تمت ملاحظته خارجيًا بدلاً من افتراض أنه يطابق العنوان المستخدم داخل التطبيق. يمكن لـ NAT وتجمعات خروج الموفر أن تجعل هذه القيم مختلفة.
إعادة إنتاج خطأ عائلة العنوان
تركيبات اصطناعية: example.com. MX 10 mx.example.com.; mx.example.com. A 192.0.2.10; mx.example.com . AAAA 2001:db8::10. في التمرين المعملي، قم بتكوين نقطة نهاية IPv4 لقبول اتصالات TCP على المنفذ 25 وترك نقطة نهاية IPv6 غير قابلة للوصول. تنجح عمليات فحص DNS المتوقعة لكلا النوعين من السجلات، بينما ينجح اختبار الاتصال الخاص بالعائلة فقط لـ IPv4 .
استفسار حفر @AUTH mx.example.com . + لا لعنة ثم نفس الأمر مع AAAA. استبدل AUTH بالسلطة المعزولة. سجل كلا الإجابتين. استخدم عميل SMTP المعملي المعتمد لديك لتثبيت كل وجهة بشكل مستقل، وتسجيل نتائج الاتصال والبروتوكول. توضح المباراة لماذا لا يعد نجاح DNS بمثابة نجاح للخدمة؛ ولا يقدم أي ادعاء بشأن التوقيت الاحتياطي لمرسل معين.
المباراة الثانية تغير فقط العنوان A من 192.0.2.10 ل 192.0.2.20 في حين أن سياسة SPF هي v=spf1 a:mx.example.com -all. بالنسبة لتقييم IPv4 SPF مع عمليات البحث الناجحة، فإن العنوان المؤهل لمطابقة a تغييرات الآلية. صريحة ip4:192.0.2.10 ستظل الآلية بدلاً من ذلك مرتبطة بتلك الشبكة الحرفية حتى تتغير السياسة نفسها.
جعل تغييرات العنوان قابلة للعكس
مراجع: RFC 8767 §4.
جرد جميع عملاء اسم المضيف، بما في ذلك توجيه البريد ومراجع نظام التعرف على هوية SPF والمراقبة وتوقعات الشهادة. قم بإعداد نقطة النهاية قبل الإعلان عنها. احتفظ بالخدمة القديمة بينما لا يزال بإمكان ذاكرات التخزين المؤقت المناسبة توجيه حركة المرور هناك، استنادًا إلى خطة الترحيل الفعلية بدلاً من فترة الانتظار العامة.
بعد التغيير، قارن الإجابات الموثوقة بالملاحظات المتكررة والأدلة على مستوى الرسالة. يجب إصلاح نقطة نهاية IPv6 الفاشلة أو إزالتها من خلال تغيير معتمد، وليس إخفاؤها عن طريق إضعاف سياسات المصادقة غير ذات الصلة. أغلق العمل فقط عندما تتطابق العناوين ومسارات التشغيل المقصودة مع تصميم الخدمة الموثق.
أبقِ نطاق الأدلة واضحًا
بالنسبة لسيناريو العائلتين، احتفظ بنجاح IPv4 المتوقع وفشل IPv6 كملاحظات معملية مقترحة حتى يتم اختبارهما. يفترض مثال تغيير عنوان نظام التعرف على هوية SPF عمليات البحث الناجحة والسياسة المعلنة؛ ولا ينشئ ترخيصًا حاليًا لأي مرسل حقيقي.