"لا." سجل DMARC "تم العثور على تحذير" هو نقطة بداية للتشخيص. يمكن أن يعكس سياسة مفقودة بالفعل، أو استعلام عن اسم خاطئ، أو تعديل في حساب DNS غير نشط، أو إجابة قديمة مخبأة أو فشل الحل.
قبل نشر سجل آخر، حدد ما استفسرت عنه الأداة والخوادم الموثوقة التي تتحكم في تلك الإجابة. احتفظ برمز استجابة DNS وأي بيانات TXT تم إرجاعها. هذا يفصل السجل الغائب عن سجل موجود ولكن لا يمكن استرجاعه من خلال مسار بحث معين.
التقاط عملية البحث الفاشلة بالضبط
قم بتسجيل الأداة والمجال الذي تم الاستعلام عنه والطابع الزمني والمحلل واستجابة DNS الكاملة حيثما كان ذلك متاحًا. احفظ سجل السياسة الحالي وتكوين DNS قبل التحرير.
لا يتم تنفيذ أوامر حفر BIND التوضيحية هنا. استبدل أسماء الوثائق بالخادم المستهدف المعتمد والخادم المفوض الفعلي. ال دليل حفر BIND يحدد خيارات الخادم والاسم والنوع والاستعلام. يساعد قسم السلطة في الاحتفاظ بسياق الإجابة السلبية؛ تحتفظ التعليقات بحالة الرأس والأعلام. استعلام بسيط للمجال المرئي example.com يبدأ هنا:
حفر _dmarc.example.com . TXT +رقم +إجابة +سلطة +تعليقاتاحتفظ بحالة الرد وكذلك قسم الإجابة. يمكن أن يؤدي العرض القصير فقط إلى إخفاء التمييز بين الاسم الذي لا يحتوي على بيانات TXT ذات الصلة وخطأ في الدقة.
حدد من يتحكم في إجابة DNS العامة
غالبًا ما تصبح هذه المشكلة مشكلة ملكية. ربما تكون إحدى الشركات قد اشترت النطاق من أحد المزودين، ونقلت موقعها الإلكتروني إلى مكان آخر، وفوضت DNS إلى حساب ثالث. يمكن أن يبدو السجل المضاف في اللوحة الخاطئة مكتملاً دون أن يكون له أي تأثير على عمليات التحقق من البريد الإلكتروني العامة.
اطلب من المشغل تحديد مضيف DNS المعتمد الحالي وإظهار إجابته للاسم المقصود. تجنب الدفع مقابل الإصلاحات المتكررة بدون مسار نشر واضح. اسأل أيضًا عما إذا كان التحذير يتعلق بنطاقك الرئيسي أو نطاق إرسال فرعي أو هوية مختلفة يستخدمها التطبيق.
التحقق من الاسم وحساب النشر
تحقق من التفويض المخوّل للمنطقة، بما في ذلك المنطقة التابعة المفوضة بشكل منفصل في حالة وجودها. الاستعلام عن خادم موثوق ذي صلة مباشرةً، باستخدام اسمه الفعلي:
dig @ ns1.example.net _dmarc.example.com . TXT +norecurse +noall +answer +authority +commentsإذا قام محرر DNS تلقائيًا بإلحاق المنطقة، فسيتم إدخالها _dmarc.example.com قد تنشر عن طريق الخطأ _dmarc.example.com.example.com. في محرر آخر، الدخول فقط _dmarc قد يكون مخطئا. تحقق من اسم المالك المنشور النهائي بدلاً من وصف تنسيق الإدخال نفسه لكل مزود.
وتشمل الأخطاء المتكررة الأخرى أ سجل TXT في جذر المجال، أو تعديل لحساب DNS غير نشط، أو تغيير غير محفوظ، أو بحث عن مجال إرسال خاطئ.
التمييز بين الغياب وفشل البحث
- الملاحظة: NXDOMAIN ؛ ما يجب التحقق منه: تم الإبلاغ عن الاسم الذي تم الاستعلام عنه على أنه غير موجود
- الملاحظة: NOERROR مع عدم وجود بيانات TXT ذات الصلة؛ ما يجب التحقق منه: الاسم الذي تم الاستعلام عنه لا يحتوي على إجابة TXT قابلة للتطبيق في هذا الرد
- الملاحظة: SERVFAIL ؛ ما الذي يجب التحقيق فيه: فشل الحل؛ فحص السلطة والتفويض والتحقق والتبعيات
- ملاحظة: الإجابة الموثوقة موجودة ولكن الإجابة العودية تختلف؛ ما يجب التحقق منه: حالة ذاكرة التخزين المؤقت وعرض المحلل ومسار التفويض والتوقيت
- ملاحظة: العديد من سجلات سياسات المرشحين؛ ما يجب التحقيق فيه: مشكلة في مجموعة السجلات، وليست حالة سجل مفقودة بسيطة
تم وصف حالات DNS وتمييز الإجابة السلبية في RFC 1035 §4.1.1, RFC 2308 §2.1 و RFC 2308 §2.2. لا تعامل SERVFAIL كإذن لنشر سجل آخر. قد يكون السجل موجودًا ولكنه غير متاح من خلال مسار الحل الفاشل. وبالمثل، فإن السجل المفقود في اسم الطفل لا يحدد ما إذا كان بإمكان المتلقي اكتشاف سياسة قابلة للتطبيق في مكان آخر بموجب RFC 9989 §4.10.1.
مثال عملي: السجل في منطقة غير نشطة
النظر في هذا التحقيق التوضيحي. ويضيف المسؤول _dmarc إلى لوحة DNS الخاصة بالمسجل. ومع ذلك، يشير التفويض العام إلى مضيف DNS منفصل تم استخدامه أثناء عملية ترحيل موقع الويب السابقة.
تعرض لوحة المسجل القيمة المقصودة. الاستعلام المباشر إلى السلطة المفوضة حاليًا لا يعيده. الانتظار لفترة أطول لا يمكن أن يجعل المنطقة غير النشطة موثوقة.
ويتم التصحيح بالنشر عن طريق الهيئة الفعلية، بعد الحصول على الموافقة المناسبة. بعد ذلك، احتفظ بالإجابة الموثوقة وقارن الملاحظة العودية. قد يؤدي تغيير خوادم الأسماء فقط لجعل اللوحة السابقة فعالة إلى تعطيل سجلات الويب والبريد غير ذات الصلة، لذا يعد هذا تغييرًا منفصلاً وأوسع نطاقًا.
قارن بين الإجابات الموثوقة والمخزنة مؤقتًا
تحت RFC 2308 §5، يمكن للمحلل تخزين إجابة سلبية سابقة مؤقتًا. وبالتالي يمكن أن يتواجد السجل الرسمي الجديد بشكل مؤقت مع ملاحظة متكررة للإجابة المفقودة. لا يؤدي مسح ذاكرة التخزين المؤقت لجهاز الكمبيوتر المحمول إلى مسح حالة محلل جهاز الاستقبال الخارجي.
قارن السلطة والملاحظات العودية ذات الصلة مع الطوابع الزمنية. إذا لم توافق الخوادم الموثوقة، فتحقق من حالتها المنشورة. إذا كان هناك اختلاف بين DNS الداخلي والعام، فحدد طريقة العرض التي يستخدمها مستلم البريد الخارجي.
تجنب الوعد بأن جميع الإجابات سوف تتقارب بعد عدد محدد من الدقائق. تشخيص المسار الفعلي وأدلة ذاكرة التخزين المؤقت.
تصحيح عملية النشر
تعامل مع النتيجة باعتبارها مشكلة تتعلق بملكية التحكم عندما تكشف عن مسؤولية DNS غير واضحة أو حسابات مهجورة أو تفويض غير مُدار. سجل من يمكنه إجراء التغييرات، والمنطقة النشطة وكيف يتحقق المراجع الثاني من النتيجة.
ملاحظة السياسة المفقودة هي نتيجة للتكوين. ولا يثبت ذلك أ التصيد نجحت الحملة، أو أن كل نطاق فرعي يفتقر إلى سياسة أو أن كل رسالة مستلمة تفشل DMARC. أبقِ هذه الاستنتاجات منفصلة واجمع الأدلة التي يتطلبها كل منها.
التحقق من السياسة ورسالة حقيقية
بعد التصحيح المقصود، تأكد من البحث عن السياسة المعمول بها واختبر رسالة شرعية حقيقية من خلال الخدمة ذات الصلة. التحقق من نتيجة المصادقة الموثوقة و تنسيق.
يستخدم سير عمل إنشاء السجل عندما تكون هناك حاجة إلى سياسة جديدة بالفعل. إذا كانت السياسة مرئية ولكن فشل البريد، فانتقل إلى تشخيص المحاذاة. إذا اختلف الدليل القديم والمستقبل الجديد في الاكتشاف، قم بتضمينه جاهزية DMARCbis في التحقيق.
الوجبات الجاهزة العملية
أغلق النتيجة بمسار النشر المصحح والإجابة الرسمية الناتجة. ثم تحقق من السياسة المعمول بها ورسالة مشروعة حقيقية. وهذا يترك تشخيصًا قابلاً للتكرار بدلاً من نتيجة مدقق غير مفسرة.
أبقِ القرار والأدلة منفصلين
بالنسبة لتركيبات المنطقة غير النشطة، اختر السلطة النشطة كهدف النشر المقترح؛ لا تقم بتغيير التفويض لمجرد جعل لجنة عفا عليها الزمن ذات صلة. افحص علامة الإجابة الموثوقة وسياق الاستجابة الكاملة، وليس فقط النص الذي تم إرجاعه. RFC 8767 §4 يسمح بتأهيل استخدام الإجابات القديمة بعد انتهاء صلاحية TTL، لذا فإن TTL ليس موعدًا نهائيًا للتقارب العالمي. لم يتم تنفيذ أي بحث أو تغيير في التكوين.