غالبًا ما تحتوي حادثة المصادقة على عدة ساعات: الفاصل الزمني المغطى للتقرير، ووصول التقرير، وتغيير DNS ، ونشر التطبيق، واختبار متحكم فيه. إن وضعها في جدول زمني واحد يكون مفيدًا فقط إذا احتفظ كل حدث بمعناه الأصلي. يوميا تقرير مجمع لا يمكن عادةً إخبارك بالدقيقة المحددة التي فشلت فيها كل رسالة مضمنة.
إنشاء أساس زمني مشترك
مراجع: RFC 9990 §3.1.1.4, RFC 9990 §3.5.4.
قم بتطبيع الطوابع الزمنية المعروضة لمنطقة زمنية معلنة مع الاحتفاظ بالقيم والدقة الأصلية. سجل مصادر الساعة وعدم اليقين المعروف. قم بتمييز الفاصل الزمني للتقرير عن الطوابع الزمنية للوصول والتناول. لا ينبغي رسم تسليم التقرير المتأخر كدفعة جديدة للإرسال في لحظة وصول المرفق.
قم بتوسيع نطاق التحقيق ليشمل نطاق المؤلف والخدمة التي تم التحقق منها حيثما أمكن ذلك. احتفظ بالمصادر غير السرية منفصلة. الحفاظ على هوية المراسل والتقرير، وأعداد الرسائل، ومجموعات المصدر والهويات التي تم تقييمها، إلى جانب القرارات المكررة والمتداخلة. تحدد هذه التفاصيل الملاحظات التي يمكن مقارنتها بشكل شرعي.
أضف أدلة DNS دون إعادة كتابة التاريخ
مراجع: RFC 1034 §3.6, RFC 8767 §4, RFC 9990 §3.3.
قم بتسجيل التغيير المعتمد ووقت النشر المقصود والملاحظات الرسمية وأي عينات من أدوات الحل، بما في ذلك وقت البحث ومدة البقاء (TTL) التي تم إرجاعها. تحدد إجابة DNS الحالية ما لاحظه هذا البحث الآن؛ إنه ليس تاريخًا كاملاً لما رآه كل متلقي سابقًا.
التخزين المؤقت DNS مهم ضمن RFC 1034 §3.6; تأهيل السلوك الذي لا معنى له بموجب RFC 8767 §4 يمكن أن يمتد استخدام ذاكرة التخزين المؤقت إلى ما هو أبعد من الحداثة العادية. لا تدعي أن جميع أجهزة الاستقبال قد تم تبديلها في لحظة النشر أو أن جهاز واحد فقط يتم عرض TTL لاحقًا. الحفاظ على التكوين المسبق وسجل التغيير وحدود الأدلة. عندما يمتد الفاصل الزمني للتقرير إلى تغيير في السياسة، قم بتسميته على أنه مختلط أو يحتمل أن يكون مختلطًا بدلاً من تعيين كل ملاحظة للسياسة النهائية.
إضافة أدلة الطلب والمتلقي
مراجع: RFC 5321 §4.2.5.
ضع عمليات نشر التطبيقات وتغييرات البوابة وتغييرات التوقيع بجانب أحداث DNS . احتفظ بالاختبارات الخاضعة للرقابة كملاحظات فردية مع مسارها الفعلي وجهاز الاستقبال والنتيجة. قد يُظهر سجل الطلب التقديم أو القبول في مرحلة ما؛ لا يحدد بالضرورة التسليم النهائي.
استخدم أنواع الأدلة هذه لاختبار التفسيرات المتنافسة. قد تتزامن أيضًا زيادة الفشل بعد تحرير DNS مع قالب جديد يغير المحتوى الموقع. الارتباط يضيق التحقيق لكنه لا يحدد السبب دون مزيد من الأدلة.
العمل من خلال جدول زمني محدد
حالة توضيحية: تقرير يغطي الساعة 00:00 إلى الساعة 24:00 بالتوقيت العالمي. يتم تسجيل تغيير السياسة في الساعة 12:00، ويتم محاذاة الاختبار الخاضع للرقابة في الساعة 12:20 DKIM. يحتوي التقرير على 80 ملاحظة ناجحة و20 ملاحظة فاشلة، ويصل في صباح اليوم التالي الساعة 05:00.
يمكنك ذكر إجماليات الفترات والاختبار الناجح في الساعة 12:20. لا يمكنك تعيين جميع حالات الفشل العشرين قبل الظهر لمجرد اجتياز الاختبار لاحقًا. الإجراء التالي هو الحصول على دليل أضيق للمستقبل أو التطبيق، أو إجراء اختبارات تمثيلية إضافية. الوصول الساعة 05:00 هو حدث تحصيل وليس وقت الـ20 فشلاً.
اختتم ببيان سببي للقوة الصحيحة
قم بتسمية الاستنتاجات كما لوحظت أو مؤكدة أو لا تزال افتراضية. قم بتسمية الأدلة التي تدعم السبب المشتبه به ولا يتم استبعاد أي تفسير منافس. إذا كان الارتباط الدقيق مستحيلًا، فاحتفظ بعدم اليقين بدلاً من رسم حدود فشل دقيقة على الرسم البياني.
احفظ الجدول الزمني مع مراجع المصدر ومراجعة الاستعلام والفواصل الزمنية المضمنة وتصنيفات الملكية. قم بتسجيل مشغل التحقق التالي، مثل أول فترة إبلاغ كاملة قابلة للمقارنة بعد الإصلاح. يجب أن يسمح الجدول الزمني القابل لإعادة الاستخدام لمحلل آخر بإعادة بناء الحقائق وحدود الاستنتاج.
مواصلة التحقيق
استخدم إرشادات التقرير المجمع للحقول الأساسية و دليل تشخيص المحاذاة عندما لا يرضي نجاح المصادقة الأولية DMARC.
احتفظ بالرسم التوضيحي ضمن أدلته
بالنسبة للفاصل الزمني الخيالي المكون من 80 تمريرة/20 فشلًا، احتفظ بجميع أوقات الفشل العشرين غير معروفة. اختبار 12:20 هو ملاحظة لاحقة والوصول 05:00 هو حدث تجميع. لم يتم تنفيذ أي بحث حقيقي DNS أو اختبار مصادقة، ولم يحدد المخطط الزمني أي تغيير سببي مثبت.