الخلاصة

  • لم يعتبر RFC 3008 توقيع البيانات دليلاً مادياً لـDNSSEC إلا بعد اجتياز قيود الحقول وارتباطه بمفتاح منطقة مناسب؛ نجاح الحساب وحده لم يكن كافياً.
  • بقيت مفاتيح المضيف والمستخدم قادرة على مصادقة معاملات SIG(0)، بينما وقّع مفتاح المنطقة الحالة العامة، ففصل هوية طالب التغيير عن سلطة الشهادة على محتوى المنطقة.

قد يكون التوقيع صحيحاً تماماً وصادراً عن الشاهد الخطأ. يطابق المفتاح العام، وتبقى البايتات سليمة، وتنجح الخوارزمية، لكن المفتاح لا يملك حق تمثيل منطقة DNS. تلك هي الفجوة التي وضعها RFC 3008 في صلب قرار المفسّر عند نشره في نوفمبر 2000.

سمت الوثيقة بعض التوقيعات «مادية» وبعضها «غير مادي». يغطي data SIG عادة RRset ويمكن أن يدخل في تحقق DNSSEC. وقد يؤدي توقيع آخر وظيفة خاصة بتطبيق، أو لا يرتبط بأي RRset، أو يحمي رسالة DNS كاملة بصفته SIG(0). لا يعني عدم المادية أن التوقيع مزور، بل أنه ليس جزءاً من سلسلة الدليل العام التي تقبل بها بيانات المنطقة.

ضيّق هذا التصنيف نموذج RFC 2535. كان الجيل السابق يسمح في بعض الحالات لمفاتيح المنطقة والمضيف والمستخدم بتوقيع البيانات. بدت المرونة مفيدة للتحديث الديناميكي: يوقع المضيف السجلات التي يضيفها، ويبقى المفتاح الخاص الأكثر حساسية للمنطقة خارج الاتصال.

لكن بقية المسار لم تسمح بهذا الفصل الكامل. تغيير منطقة آمنة يقتضي إعادة توقيع مجموعات SOA وNXT. ولذلك احتاج التحديث الآمن في RFC 3007 أصلاً إلى قدرة توقيع منطقة متصلة. إذا كان مفتاح المنطقة موجوداً وقادراً على توقيع البيانات المقبولة، فلن يؤدي اعتبار توقيع المضيف دليلاً عاماً إلى إزالة التعرض المقصود. إنما يضيف لكل مفسّر مهمة استنتاج علاقة سلطة أكثر تعقيداً.

اختار RFC 3008 قاعدة مشتركة أضيق: بيانات المنطقة الآمنة يوقعها مفتاح منطقة. يتجاهل المفسّر الأنواع الأخرى عند تقييم data SIG مادي، إلا إذا وضعت سياسة محلية صريحة استثناء. قلّت المرونة، لكن طول سلسلة التحقق صار محدوداً بعمق تسميات الاسم، وأصبحت السلطة قابلة للقراءة من بنية المناطق الظاهرة.

لم تكن صفة zone بطاقة تعفي من بقية الاختبارات. يجب أن يطابق type covered نوع RRset المرتبط. وينبغي أن يعرف العميل الخوارزمية وأن يكون لها تنسيق SIG محدد. لا يجوز أن يتجاوز عدد labels تسميات اسم مالك التوقيع. ويلزم أن تكون original TTL مساوية على الأقل لـTTL الحالية لأن الخادم الوسيط لا يستطيع زيادتها. ويجب أن يقع وقت التحقق بين inception وexpiration.

بعد ذلك يبحث signer name وkey tag والخوارزمية عن KEY مرشح. إذا لم يوجد، يصبح التوقيع غير مادي. وإذا طابقت المعرفات أكثر من KEY، تبقى كلها مرشحة حتى يحدد التحقق الحسابي أيها أنشأ التوقيع. لا يستطيع المفسّر رؤية نتيجة ناجحة ثم اختراع دور مؤسسي للمفتاح بأثر رجعي.

يحمل KEY نفسه حدوداً أخرى. يجب أن تسمح type flags بالمصادقة. وفي توقيع بيانات مادي ينبغي أن يكون name type هو zone. ويجب أن يعلن protocol عن DNSSEC أو ALL. كما يلزم أن تتطابق خوارزمية KEY مع SIG. وهكذا قد تنجح المادة العامة نفسها في العملية الحسابية، ثم تُستبعد لأن السجل أعلنها لبروتوكول أو فاعل آخر.

تنتج الخطوات إيصالات مختلفة. يربط التحقق المشفر المفتاح والتوقيع والمدخل. تثبت أهلية الحقول أن الجسم قابل للمعالجة. يمنح نوع المفتاح سلطة على فئة بعينها. تصل سلسلة الثقة المنطقة بنقطة معروفة. يحدد الزمن صلاحية الشهادة. وحتى اجتماعها لا يثبت أن الخدمة خلف العنوان تعمل أو أن كل معنى خارجي للبيانات صحيح؛ إنها تحمي عبارة DNS المنشورة.

احتفظت SIG(0) بمسار منفصل. حين يكون type covered صفراً يحمي SIG رسالة أو معاملة DNS، كما فصل RFC 2931. يبدأ المستخدم أو المضيف المعاملة، ولذلك كان user أو host/entity نوع المفتاح المتوقع. وحتى خادم الأسماء يوقع هنا كمضيف لا كتجسيد لمنطقة. ولهذا لا ينبغي عادة لمفتاح المنطقة إنشاء SIG(0).

لم يفقد مفتاح المضيف وظيفته؛ بل تحدد موضوع دليله. يستطيع مصادقة principal الذي أرسل طلب التحديث. ثم يطبق الخادم الأولي سياسة RFC 3007 المحلية على الأسماء وأنواع RR والعمليات، مع المنع كحالة افتراضية. إذا قبل التغيير، يوقع مفتاح المنطقة الحالة العامة. بقي الاقتراح والقبول والشهادة العامة سلطات مستقلة.

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

لم يتحول حقل signatory القديم في KEY إلى بديل. لم يخصص RFC 3008 له قيماً ولم يطلب وجوده. قد تبدو بتات قليلة طريقة محمولة لتمثيل السلطة، لكنها تجمد السياسات المستقبلية في تعداد ثابت وتخلط قبول الكتابة بالتحقق العام. كانت السياسة المحلية عند المدخل وقاعدة مفتاح المنطقة عند القراءة سطحين أوضح للمسؤولية.

ظل النموذج مرحلة تاريخية. أوضح RFC 3090 حالة أمن المنطقة في النظام القديم. وأضاف RFC 3658 سجل DS وغير صلة التفويض. ثم حلت RFC 4033 وRFC 4034 وRFC 4035 محل جيل KEY/SIG في RFC 2535 وRFC 3008.

لذلك لا يجوز تقديم RFC 3008 كدليل إعداد حالي، ولا إسقاط حقول KEY بلا شرح على DNSKEY وRRSIG الحديثة. سجل تقرير RFC 3130 أن DNSSEC كان يُفهم عام 2001 كصندوق أدوات تتطور مكوناته بسرعات مختلفة. هذا دليل على مرحلة تصميم، لا على انتشار شامل أو مكسب أمني مقاس سببه هذا النص وحده.

الباقي تاريخياً هو ترتيب القرار. لا يحمل الدليل كامل تفويضه معه. يجب أن يجمع البرنامج العامل في المفسّر دور الموقع والجسم المغطى والغرض المعلن والوقت ومسار الثقة. وإلا منحت دقة الرياضيات لحائز المفتاح سلطة عامة لم تمنحها البنية.

من منظور Running-Code Primacy عند Lu Heng، لا تسكن السلطة داخل جسم التوقيع، بل تظهر عندما ينفذ المفسّر التصنيف والتحقق الكاملين. قاعدة مفتاح المنطقة هي الحد الأدنى المشترك. يمكن للاستثناء المحلي أن يوجد، لكنه يبقى مسؤولية من اختاره ولا يعيد كتابة قاعدة الجميع بصمت. يعتمد الاستقرار على الإيصالات المنفصلة لا على ضوء أخضر واحد.

جعل RFC 3008 التوقيع أقل سحراً وأكثر قابلية للمساءلة. تثبت العملية التحكم بالمفتاح، ويعلن KEY الغرض، ويعطي موقع المنطقة الدور، وتقدم السلسلة مصدر الثقة، وتحدد الساعة المدة. لا يصبح التوقيع الصحيح دليلاً مخولاً على RRset إلا عند التقاء هذه العناصر.

Sources