الخلاصة

  • استبدل RFC 3655 وصفاً واسعاً لسياسة الخادم بإشارة أضيق: مجموعات سجلات الموارد المعنية في الإجابة خضعت للمصادقة وفق القواعد المعدّلة.
  • بت AD تقرير يصدره المحلّل، وليس توقيعاً لحزمة DNS أو دليلاً على موثوقية المحلّل أو المسار أو سياسة الثقة التي اختارها المستخدم.

التحليل

يبدأ المشهد باستعلام عادي: يطلب تطبيق اسماً عبر محلّل محلي من نوع stub، فيحوّله هذا إلى محلّل تكراري يستطيع تتبّع سلسلة المفاتيح وجلب التوقيعات والاستفادة من الذاكرة المؤقتة. وعند عودة الإجابة، يمكن لبت في الترويسة أن يخبر التطبيق بما أنجزه المحلّل upstream. السؤال الحاسم ليس عدد البتات في الترويسة، بل من يملك حق إصدار هذا التقرير وما الأدلة التي يلخّصها.

أعطى RFC 2535 بت البيانات الموثقة (AD) معنى واسعاً: يعلن الخادم أن بيانات قسمي Answer وAuthority موثقة وفق سياسته. ورأى RFC 3655، المنشور في نوفمبر 2003، أن هذه الإشارة لا تفيد عملياً بما يكفي. فالخادم المطابق للمواصفة ينبغي أصلاً ألا يعيد بيانات أخفقت في اجتياز سياسته الأمنية. لذلك كان البت يصف في الأغلب موقف الخادم العام ولا يوضح للتطبيق الحالة الأمنية لهذه الإجابة بعينها.

جعل التعديل هذا التمرير أدق. لا ينبغي للخادم التكراري ضبط AD ما لم تستوفِ مجموعات RR المعنية في قسمي Answer وAuthority شروط المصادقة. ويُضبط البت عندما تكون سجلات الإجابة، والسجلات ذات الصلة التي تسند إجابة سلبية، موثقة. لا يعني ذلك أن كل حزمة DNS أصبحت موقعة بذاتها؛ فـDNSSEC يصادق مجموعات سجلات الموارد، بينما يختصر AD حكماً محلياً أصدره المحلّل بشأن هذه الإجابة.

يوضح ذلك أيضاً اختلاف DO وCD عن AD. يطلب DO إدراج سجلات DNSSEC؛ واشترط RFC 3655 طلب تلك السجلات وإرجاع سجلات SIG ذات الصلة قبل ضبط AD. أما CD فيعطّل الفحص لهذا الاستعلام. لكنه لا يمحو AD تلقائياً: فقد يستطيع الخادم الإشارة إلى بيانات سبق التحقق منها تشفيرياً أو وافقت سياسته المحلية. كل بت يصف مرحلة مختلفة: طلب الأدلة، والتحكم في الفحص، والإبلاغ عن النتيجة.

وهكذا جعل RFC 3655 المحلّل التكراري وسيطاً للثقة. لا تحتاج التطبيقات كلها إلى تضمين مدقّق كامل، ويمكن إعادة استخدام عمل التحقق من الذاكرة المؤقتة. لكن لا يجوز لـstub اعتبار AD دليلاً يصادق نفسه. ينبغي إعداد الثقة بالمحلّل صراحة وحماية الاتصال، عبر قناة آمنة أو مصادقة الرسائل مثل TSIG أو SIG(0). من دون ذلك، يظل ضبط AD من مستجيب على المسار ادعاءً بحدوث التحقق، لا دليلاً وصل بأمان.

كشفت قاعدة الخوادم السلطوية حداً آخر. يجوز إعداد خادم أساسي لمنطقة آمنة كي يضبط AD، لكن يجب أن يكون ذلك اختياراً صريحاً وأن يكون معطلاً افتراضياً. أقرّ النص بأن الخادم السلطوي غير ملزم بالتحقق من بيانات منطقته؛ وقد يترتب على فحص التوقيعات عند تحميل المنطقة أو مع كل استعلام كلفة تشغيلية. لذلك لا يضمن AD في إجابة سلطوية مباشرة، افتراضياً، إجراء تحقق مماثل لما يجريه محلّل تكراري.

ومن السهل أيضاً إساءة تفسير AD=0. منع RFC 3655 ضبط AD لإجابة غير آمنة، لكن البت المطفأ وحده لا يبيّن إن كانت البيانات غير آمنة، أو أن المحلّل لم يفحصها، أو أن سجلات DNSSEC المطلوبة لم تصل، أو أن الخادم اختار عدم تأكيد الحالة. يحمل AD=1 معنى ضمن علاقة ثقة؛ أما AD=0 فليس تشخيصاً كاملاً.

في 2005، أعادت RFC 4033 وRFC 4034 وRFC 4035 تنظيم إطار DNSSEC وألغت RFC 3655. بقي تمرير الحالة عبر AD، لكنه أصبح جزءاً من وصف أشمل للمدقّقات وstubs والخوادم السلطوية ومسارات المصادقة. تكمن أهمية RFC 3655 التاريخية في إصلاح واجهة ضيقة: نقل تقييم المحلّل التكراري إلى التطبيق من دون الإيحاء بأن بت الترويسة نفسه دليل تشفيري.

تتكون سلسلة الأدلة من طبقات. يمكن لسجل RRSIG أن يدعم مصادقة مجموعة RR عبر سلسلة مفاتيح ومرتكز ثقة. ويتخذ المحلّل المدقّق قراراً محلياً بشأن الحالة. ويمكن لـAD الإبلاغ عن هذا القرار. ثم قد تربط قناة آمنة مع محلّل موثوق الإجابة بالخدمة التي اختارها المستهلك. لا يثبت أي من هذه الوقائع منفرداً أمانة مالك الاسم أو حداثة المعلومات بالنسبة إلى التطبيق أو سلامة تصرف التطبيق.

المصادر