يمكن أن يبدو سجل المصادقة محليًا في وحدة تحكم DNS مع الاعتماد على خوادم أو سجلات أسماء مؤسسة أخرى. لتقييم مدى التوفر، اتبع مسار الحل والمصادقة بدلاً من حساب الموردين أو النظر إلى رقم وقت تشغيل لوحة المعلومات. السؤال المفيد هو ما هي التبعية التي يجب الإجابة عليها عندما يقوم المتلقي بتقييم هذه الرسالة بالذات.
التمييز بين آليات التفويض
تقوم منطقة DNS المفوضة بنقل سلطة الأسماء الموجودة أسفل حدود المنطقة إلى خوادم الأسماء المحددة. أ CNAME يشير اسمًا إلى اسم آخر. SPF التضمين وإعادة التوجيه هما علاقات السياسة على مستوى التطبيق، وليس تفويض المنطقة. إنها تخلق مسارات فشل مختلفة ولا يمكن تقييمها كأشكال استضافة قابلة للتبديل. RFC 1034 يشرح الخدمة الموثوقة والحل العودي؛ RFC 7208 يحدد استخدام نظام التعرف على SPF ) لـ DNS .
ارسم اسم المالك الدقيق ونوع السجل لكل خطوة. ل DKIM هذا يبدأ بـ محدد ضمن _domainkey لمجال التوقيع. بالنسبة لنظام التعرف على هوية SPF ، ابدأ بالهوية الموثقة ذات الصلة واتبع شروط السياسة الخاصة بها. ل DMARC، قم بتقييم تبعية اكتشاف السياسة بشكل منفصل. يمكن للمزود تشغيل اثنين من هذه دون تشغيل الثالث.
سجل دلالات الفشل، وليس وقت التشغيل فقط
اسأل عما يحدث إذا لم يُرجع الهدف أي بيانات أو إجابة سلبية صريحة أو سياسة غير صحيحة أو مهلة. تلك ليست متكافئة. لقد حدد SPF نتائج الخطأ الدائمة والمؤقتة. يمكن أن يتأثر التحقق من DKIM بالمعلومات الأساسية غير المتوفرة أو غير الصالحة. يمكن أن تعتمد المعالجة النهائية للرسالة الخاصة بالمستلم أيضًا على مسار مصادقة آخر وسياسة محلية، لذا تجنب الوعد بأن فشل بحث واحد يحظر دائمًا البريد أو يسلمه دائمًا.
يمكن أن يؤدي التخزين المؤقت إلى الاحتفاظ مؤقتًا بإجابة سابقة قابلة للاستخدام، ولكنه ليس نسخة احتياطية غير محدودة. سجل TTL للإجابة ووقت المراقبة. يمكن أيضًا تخزين الإجابات السلبية مؤقتًا بموجب القواعد الموضحة في RFC 2308. إن تقليل TTL الآن لا يؤدي إلى تقصير عمر الإجابات المخزنة مؤقتًا في مكان آخر بأثر رجعي.
قارن بين اثنين من تبعيات الاسترداد
لنفترض أن استعلامًا موثوقًا يُرجع هدف محدد تم تكوينه حديثًا بينما لا يزال أحد المحللين التكراريين يُرجع الهدف المُخزن مؤقتًا مسبقًا. سجل كلاً من المصادر والطوابع الزمنية. تتم ملاحظة التغيير الرسمي في ذلك الخادم؛ لا يثبت أن جميع أجهزة الاستقبال تستخدم الهدف الجديد. لنفترض الآن أن خدمة التوقيع البديلة تفتقر إلى المفتاح الخاص المقابل. حتى بعد تصحيح كل عملية بحث ذات صلة، لا يستطيع DNS وحده جعل هذه الخدمة تسجل بنجاح.
هذه ملاحظات افتراضية، وليست مختبر DNS محلي أو اختبار إنتاج. إنها تؤدي إلى خطوات تالية منفصلة: التحقق من ذاكرة التخزين المؤقت والدقة المستهدفة في نقاط المراقبة المعتمدة، والتحقق من التكوين الفعلي للموقّع البديل ومخرجات الرسالة. احتفظ بالخادم والاسم والنوع ورمز الاستجابة والأعلام وTTL والإجابة الكاملة. هذا المثال لا يمارس DNSSECأو الإحالات أو التخزين المؤقت السلبي؛ اختبار تلك بشكل مستقل حيث تتطلب الهندسة المعمارية لهم.
قرر ما إذا كانت التبعية مقبولة
قم بتعيين مالك لكل هدف خارجي وقم بتوثيق ترتيبات الاسترداد والخروج الفعلية للمورد. ضع في اعتبارك ما إذا كان بإمكانك استبدال السجل، وما إذا كنت تمتلك بيانات التعريف العامة اللازمة، وما إذا كان تغيير التوقيع يتطلب إجراءً داخل خدمة أخرى. لا تؤدي لوحات المعلومات المتعددة الموجودة على نفس البنية الأساسية الموثوقة إلى إزالة تلك التبعية المشتركة.
اختبر بديلاً في بيئة معتمدة وحدد متى يؤدي الانقطاع إلى حدوث تغيير بدلاً من الملاحظة. يمكن أن يؤدي التعديل المتسرع إلى إضافة خطأ في نظام التعرف على هوية SPF أو توجيه محدد إلى المفتاح الخطأ. احتفظ بالسجل السابق وسجل القرارات، ولكن عليك أن تدرك أن الاسترداد مقيد بذاكرة التخزين المؤقت وأي إمكانية وصول مفقودة. يجب أن تكون النتيجة قرارًا يتعلق بالمخاطر الخاصة بالتبعية مع الأدلة، وليس ادعاء بأن جميع عمليات تفويض DNS غير آمنة.