الملخص

  • قرر رئيسا DNSOP في 1 سبتمبر 2026 أن الردود تُظهر دعماً واضحاً لتبنّي draft-huque-dnsop-multi-alg-rules-08، مع إحالة مخاوف التعقيد إلى العمل اللاحق.
  • يقترح المشروع حالتي UNIVERSAL وFORMERLY-UNIVERSAL، ويتيح في تركيب محدد للجهة الموقّعة أن تحذف بعض تواقيع الخوارزميات المُعلنة.
  • تؤثر الحالة نفسها في قرار المدقّق الذي عطّل خوارزمية محلياً؛ ومن ثم فهي مدخل تشغيلي وليست بطاقة وصف.
  • يقترح Daniel Kade إيصال دليل نشر مستقل لكل تغيير تصنيفي مستقبلي. تبنّي المشروع يحدد موضوع العمل، أما Standards Action فهي التي يمكن أن تأذن بقيمة في سجل IANA.

قرار واحد بحدّين واضحين

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

بدأت الدعوة في 13 أغسطس وانتهت في 31 منه. ويعرض Datatracker حالياً المشروع بوصفه Internet-Draft نشطاً وحالته في المجموعة Adopted by a WG. أما حالة IESG فهي I-D Exists، ولا يظهر راعٍ للوثيقة أو Area Director مسؤول أو موعد telechat. انتقلت النسخة 08 إلى عهدة التعديل داخل DNSOP؛ ولم تصبح RFC أو قاعدة معتمدة من IETF.

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

لماذا تتطلب القاعدة الحالية المجموعة الكاملة

يفرض RFC 4035 وجود RRSIG لكل RRset باستخدام مفتاح واحد على الأقل من كل خوارزمية ظاهرة في DNSKEY عند قمة المنطقة، كما يفرض توقيع DNSKEY بكل خوارزمية تظهر في DS لدى الأب. ويعيد RFC 6840 بيان واجب الجهة الموقّعة، بينما يطلب من المدقّق قبول أي مسار صحيح.

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

تحاول النسخة 08 تخفيف هذا القيد. وتشمل حالات الاستخدام تشغيل عدة موقّعين بصورة دائمة، ونقل المنطقة بين مزودين مختلفين، وتغيير KSK وZSK في مرحلتين، ونشر trust anchor مسبقاً، وتجربة خوارزمية جديدة لدى مزود واحد من دون فرضها فوراً على الجميع. تبنّت DNSOP الحاجة إلى معالجة هذه الحالات؛ ولم تحسم بعد الآلية النهائية.

كلمة في سجل IANA ستغيّر الاستجابة

يقترح المشروع إضافة عمود Validation support status إلى سجل IANA، بقيم UNIVERSAL أوFORMERLY-UNIVERSAL أو خانة فارغة. ويقترح أن تبدأ الخوارزميتان 8 و13 في الحالة الأولى. لا يحتوي سجل خوارزميات DNSSEC لدى IANA حالياً على هذا العمود، وإن كان يسجل 8 و13 بوصفهما MUST للتنفيذ في التحقق.

إذا احتوت مجموعة DS أو trust anchors على خوارزمية UNIVERSAL واحدة على الأقل ولم تحتو على أي FORMERLY-UNIVERSAL، تسمح الصيغة المقترحة للموقّع بتقديم توقيع بخوارزمية عالمية واحدة فقط. تصبح التواقيع الأخرى اختيارية. وفي التركيبات الأخرى يبقى توقيع كل الخوارزميات مطلوباً.

ويحصل المدقّق على فرع جديد في القرار. إذا لم يدعم خوارزمية معلنة وهي UNIVERSAL أو كانت كذلك سابقاً، فعليه اعتبار المنطقة غير موقعة حتى إن كان يدعم خوارزمية أخرى معلنة. وفي بقية الحالات يقبل أي مسار صحيح. وعند تعطيل خوارزمية بسياسة محلية، يجب أن يحتفظ بتاريخ حالتها.

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

يوفر RFC 9904 فصلاً مهماً: نقل توصيات الاستخدام ومتطلبات التنفيذ إلى سجلات IANA، وميّز ما يلزم للتوافق عما يختاره المشغّل للنشر. ويتوقع أن تتغير القيم تدريجياً مع الزمن. العمود الجديد يؤدي وظيفة أخرى؛ ولا يرث مبررات الأعمدة القائمة لمجرد مجاورته لها.

التبنّي أبقى الاعتراضات داخل العمل

تكشف الردود العامة مضمون التحفظ. عارض Mark Andrews المشروع وشكك في افتراضه بشأن دعم المدقّقين حول العالم. وأيّد Paul Hoffman تخفيف قاعدة «كل خوارزمية»، لكنه رفض تصميم حالتي دورة الحياة بصورته الحالية. وأيّد Paul Wouters التبنّي مع طلب تبسيط كبير وفصل أوضح بين السيناريوهات.

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

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

إيصال مستقل لكل تغيير حالة

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

ويعرض أيضاً النتائج المتوقعة Secure وInsecure وBogus في أوضاع نموذجية للتوقيع المتعدد ونقل المزود، والتفاعل مع تفضيلات الخوارزمية المحلية، ونافذة السريان، واعتماديات الموقّعين، وصاحب قرار الانتقال أو التراجع الطارئ. يمكن حماية هويات المحللات وبيانات الأساطيل التجارية؛ أما نطاق الادعاء العالمي فلا ينبغي إخفاؤه.

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

تبنّت DNSOP مشكلة تستحق العمل، وتبنّت مسؤولية تعديل نصها. لم تتبنّ بعد سلطة كلمة UNIVERSAL. الفصل بين إيصال التبنّي وإيصال التصنيف يحافظ على هذا الفرق حتى يصل العمل، إن تقدم، إلى السجل والبرمجيات.

المصادر