الخلاصة

  • حصلت SC100 على 22 صوتا مؤيدا من جهات إصدار الشهادات المشاركة وثلاثة أصوات مؤيدة من مستهلكي الشهادات، من دون رفض أو امتناع. وتنتهي مراجعة الملكية الفكرية المجدولة في 5 سبتمبر 2026؛ وعند تاريخ القطع في 31 أغسطس لم تكن المسودة جزءا من المتطلبات الأساسية الحالية لشهادات TLS.
  • تجمع المسودة قواعد DNSSEC القائمة في موضع واحد. وهي تجعل التحقق واجبا في منظور الشبكة الأساسي لاستعلامات إثبات السيطرة على النطاق وCAA ذات الصلة، مع استثناء جزئي ضيق لوسائل البريد الإلكتروني، في حين يبقى DNSSEC في مناظير الشبكة البعيدة اختياريا.
  • لا يزيل التأييد متعدد المناظير للإصدار، أو MPIC، هذا الفرق. فالمناظير البعيدة تؤيد ما خلص إليه المنظور الأساسي، ويمكن أن تدخل في عملية MPIC من دون أن تجعل القواعد DNSSEC إلزاميا في كل منظور بعيد.
  • تستبعد المسودة مجموعة استعلامات DNS الكاملة من نطاقين محددين للتسجيل والتدقيق الذاتي، لكنها تطلب الاحتفاظ بمعلومات كافية للتحقق. لذا ينبغي أن يصل السجل بين إيصال زمني لضبط المحلل وإيصال خاص بعملية الإصدار يسمّي المنظور الأساسي ويحفظ حالة DNSSEC لكل منظور بعيد على حدة.

رقمان متطابقان لا يعنيان وثيقتين بالحالة نفسها

تسجل صفحة SC100 الرسمية نتيجة تصويت واضحة على نحو نادر. وافقت 22 جهة إصدار شهادات مشاركة، وأضافت Apple وCisco Systems وMozilla ثلاثة أصوات مؤيدة من فئة مستهلكي الشهادات. لم يسجل أي صوت رافض أو ممتنع، وتحقق النصاب المسجل البالغ 15.

لكن نتيجة التصويت ليست نهاية مسار الاعتماد. تقول الصفحة نفسها إن مراجعة الملكية الفكرية بدأت في الساعة 19:00 بالتوقيت العالمي يوم 6 أغسطس، ومن المقرر أن تنتهي في الساعة 19:00 يوم 5 سبتمبر. عند تاريخ البحث كان لا يزال متاحا للأعضاء تقديم إشعارات استبعاد. ووصفت محاضر مجموعة العمل في 13 أغسطس SC100 كذلك بأنها دخلت مراجعة الملكية الفكرية حديثا.

يسهل إساءة قراءة الحالة لأن مرفق التغييرات المقبولة يحمل عنوان الإصدار 2.2.9 وتاريخ 6 أغسطس. وتعرّف صفحة المتطلبات الحالية أيضا المتطلبات الأساسية النهائية لشهادات TLS بأنها الإصدار 2.2.9 المؤرخ في 6 أغسطس. غير أن جدول مراجعات النص الحالي ينتهي عند SC101، ولا يورد SC100 كمراجعة منشورة. ويكشف فهرس الوثائق وإشعار المراجعة الفرق الضروري: الأولى إرشادات نهائية حالية، والثانية مسودة إرشادات صيانة كاملة أنشئت للمراجعة.

ليست هذه ملاحظة كتابية هامشية. يجب أن يحدد بيان الامتثال حالة الوثيقة، لا الرقم المطبوع في رأسها فقط. لا يستطيع قول «الإصدار 2.2.9» وحده أن يخبر المراجع هل يقصد المتطلبات الحالية، أم مسودة SC100 المقبولة، أم إصدارا لاحقا قد يدمجها.

وتضع ورقة الاقتراع قيدا آخر. فهي تقول إن SC100 لا تملك تاريخ نفاذ، لأن غرضها التوضيح والتجميع، لا تعديل الالتزامات القائمة. لهذا لا يعلن هذا المقال ضابطا جديدا. بل يسأل عن الدليل الذي يجعل الضابط الموضح قابلا للتحقق.

الفعل الإلزامي مرتبط بدور، لا بكلمة DNSSEC

جاء الالتزام الأساسي من SC085v2. فمنذ 15 مارس 2026، يجب إجراء DNSSEC، حين تكون سلسلة التوقيع موجودة، للاستعلامات ذات الصلة بالسيطرة على النطاق وCAA التي ينفذها منظور الشبكة الأساسي. ويحمل الإصدار الحالي 2.2.9 ذلك الالتزام موزعا بين أقسام عدة.

تقترح SC100 جمع هذه المادة في القسم 4.2.2.2. وتصف المسودة أولا المحلل الذي يستخدمه منظور الشبكة الأساسي. يجب أن ينفذ ذلك المحلل التحقق وفق القسم 5 من RFC 4035، وأن يدعم NSEC3 وSHA-2، وأن يعالج اعتبارات القسم 4 من RFC 6840.

ثم توزع الأقسام الفرعية السلوك المطلوب. على منظور الشبكة الأساسي تنفيذ DNSSEC في كل استعلامات DNS المرتبطة بوسائل تفويض النطاق أو السيطرة عليه ومعالجة CAA. توجد حدود جزئية للطرق المتبقية القائمة على البريد الإلكتروني: تظل استعلامات CNAME وCAA وTXT المستخدمة لاستخراج اسم نطاق التفويض إلزامية، بينما تستخدم الاستعلامات الأخرى صياغة SHOULD. ولا يمكن لسياسة محلية تعطيل التحقق المطلوب للطرق الأخرى أو لـCAA. كذلك لا يجوز تحويل خطأ DNSSEC يراه المنظور الأساسي، مثل SERVFAIL، إلى إذن بالإصدار ضمن حدود الاستثناء المحددة.

أما قاعدة المناظير البعيدة فمختلفة. يجوز لمناظير الشبكة البعيدة المستخدمة في MPIC إجراء DNSSEC وصولا إلى مرساة ثقة جذر IANA. وكلمة MAY ليست MUST، لكنها ليست MUST NOT أيضا. لا تصف المسودة التحقق البعيد بأنه معيب أو ممنوع؛ بل تضع الحد الأدنى الإلزامي عند الدور الأساسي وتترك لجهة الإصدار إضافة تحقق تشفيري في المواقع البعيدة.

هذه هي الحدود الإثباتية الحقيقية. لا تثبت خانة بيانات تقول dnssec_status=secure الكثير إن لم تحدد منظور الشبكة الذي ولّد الحالة. ولا يمكن لنتيجة سليمة من منظور بعيد أن تحل محل نتيجة أساسية مفقودة لمجرد أن الاثنين استخدما البروتوكول نفسه. وبالمثل لا يجوز نسخ نتيجة المنظور الأساسي إلى سجلات البعيد وكأن كل موقع اتخذ قرار DNSSEC مستقلا.

MPIC يضيف مشاهدات مستقلة ولا يضاعف واجب DNSSEC

قدمت SC067v3 نظام MPIC لجعل هجمات BGP المحددة ضد التحقق من النطاق أصعب. ويصف القسم 3.2.2.9 الحالي العملية بأنها تأييد لنتائج التحقق من النطاق وCAA التي حصل عليها المنظور الأساسي، وذلك من مناظير بعيدة قبل إصدار الشهادة.

يحمي الضابطان حافتين مختلفتين. يسأل DNSSEC إن كان المحلل يستطيع إثبات السلسلة التشفيرية لبيانات DNS والإنكار الموثق للوجود ضمن نموذج الثقة الخاص بالبروتوكول. ويحدد RFC 4035 حالات Secure وInsecure وBogus وIndeterminate. تصف هذه الكلمات حالة التحقق؛ لكنها لا تحدد طريقة الإصدار لدى جهة الشهادات، ولا دور المشاهدة، ولا القرار النهائي.

أما MPIC فيسأل هل تؤيد مشاهدات بعيدة مستقلة بما يكفي ما رآه المنظور الأساسي. وتكرر مسودة SC100 الجدول المرحلي: منذ 15 يونيو 2026 تستخدم التطبيقات المعنية أربعة مناظير بعيدة على الأقل، وتستوفي جدول النصاب، وتحصل على تأييد عبر منطقتي خدمة RIR على الأقل. وفي 15 ديسمبر يرتفع الحد الأدنى إلى خمسة. هذه أعداد للمشاهدات البعيدة، وليست أعدادا لمحللات DNSSEC الإلزامية.

يمكن إذن لمنظور بعيد أن يبلغ بنتيجة تحد أو CAA مؤيدة من دون أن تلزمه المتطلبات بإجراء DNSSEC. ويمكن لجهة إصدار أن تختار التحقق هناك وتسجل حالة أغنى. كلا المسارين يتسق مع المسودة، وعلى الدليل أن يقول أيهما حدث.

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

ترك المنتدى طريقة التسجيل مفتوحة عن قصد

لم تظهر مشكلة الإثبات مصادفة. فقد استثنت SC096 تحقق DNSSEC من متطلبات التسجيل الواسعة الخاصة بالتحقق من السيطرة وCAA. وأشار ملخصها إلى أن المحللات لم تبن للتسجيل الكثيف، وأن سجلات إدارة التغيير قد تبين أن الضوابط المناسبة كانت سارية.

يحافظ القسم المقترح 4.2.2.2.7 من SC100 على استثناء: تبقى المجموعة الكاملة لمعلومات بحث DNS المتعلقة بالتحقق خارج نطاق التدقيق الذاتي في القسم 8.7 والتسجيل في القسم 5.4.1. لكنه يضيف العبارة الجوهرية: رغم تلك الاستثناءات، يجب على جهة إصدار الشهادات الاحتفاظ بمعلومات كافية للتحقق من الامتثال لبقية قسم DNSSEC.

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

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

إيصال للضبط وآخر للإصدار

الإجابة ليست «سجّل كل شيء». الأنسب هو وصل محدود بين إيصالين.

يصف إيصال الضبط إعداد المحلل والمنظور الأساسي خلال فترة محددة. ينبغي أن يحفظ، في الحد الأدنى:

معرف إيصال الضبط + معرف المنظور الأساسي + معرف المحلل أو الخدمة + البرنامج والبناء + تجزئة الإعداد أو السياسة + مجموعة مرساة الثقة وإصدارها + حالة تحقق RFC 4035 + مراجع قدرات NSEC3 وSHA-2 وRFC 6840 + حالة استثناء السياسة المحلية + معرفات الاختبارات + بداية ونهاية الصلاحية + سجل التغيير المعتمد

يمكن للإيصال استخدام التجزئات والمراجع المضبوطة بدلا من كشف الأسرار أو الإعداد الكامل. غايته تحويل عبارة عامة، مثل «كان DNSSEC مفعلا»، إلى حالة ضبط زمنية منسوبة إلى منفذها. وهنا تفيد أدلة إدارة التغيير في بيان ما وافق عليه المشغلون والاختبارات المرتبطة بإصدار المحلل.

أما إيصال الإصدار فيصف ما حدث في محاولة تحقق واحدة، وينبغي أن يربط:

معرف المحاولة والشهادة أو الشهادة المسبقة + وقت الطلب والقرار + الاسم المطلوب ونطاق التحقق + طريقة التحقق + نطاق CAA + إصدار المتطلبات أو المسودة + معرف المنظور الأساسي + معرف المحلل وإيصال الضبط + عائلات الاستعلام + حالة DNSSEC + الخطأ وقرار الإغلاق الآمن + معرفات المناظير البعيدة + علم تنفيذ DNSSEC وحالته لكل منظور بعيد + مراجع مناطق RIR + مشاهدات MPIC ونصابه + سلسلة إعادة المحاولة + تجزئة سجل غير قابلة للتغيير

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

إذا لم ينفذ منظور بعيد DNSSEC، فينبغي للسجل أن يقول ذلك بحياد: لم ينفذ ضمن حالة اختيارية مسموحة. ولا يصح اختراع حالة Insecure، لأن لها معنى بروتوكوليا. وإذا نفذ منظور بعيد التحقق، فنتيجته تخص ذلك المنظور ومحلله. ولا ينبغي نسخ النتيجة الأساسية إلى صفوف البعيد من أجل السهولة.

لا يحتاج إيصال الإصدار إلى الحزم الكاملة، أو كل سجل موارد، أو سجل تصحيح كامل للمحلل. يكفيه ما يعيد بناء القضية محل المراجعة: استخدم الدور الأساسي المطلوب ضبطا متوافقا على مجموعة الاستعلامات ذات الصلة؛ ولم يتحول خطأ التحقق إلى إذن بالإصدار؛ واستوفى MPIC المستقل نصابه.

هذا التصميم ذو الإيصالين اقتراح تحليلي من Daniel Kade. لا تسرد SC100 هذه الحقول، ولا ينسب المقال الاقتراح إلى DIGICERT أو مقدمي الاقتراع أو المصوتين أو مدقق أو محرر RFC. اختار المنتدى معيار الكفاية، والإيصال طريق واحد لجعل الكفاية قابلة للاختبار.

إشارة نجاح لا تصل السياسة بالتنفيذ والقرار

لنفترض صحة العبارات الأربع الآتية:

  1. تقول سياسة CP/CPS لدى جهة الإصدار إن DNSSEC مفعل.
  2. نجح إعداد محلل في اختبار مطابقة.
  3. أعادت محاولة تحقق حالة Secure.
  4. صدرت شهادة بعد تحقق نصاب MPIC.

يمكن أن تكون كلها صحيحة من دون أن تثبت أن المنظور الأساسي المطلوب استخدم الإعداد المختبر للاستعلامات المطلوبة في تلك المحاولة. ما ينقص هو الوصل.

سياسة CP/CPS إعلان ممارسة وليست مشاهدة على مستوى الاستعلام. يثبت الاختبار السلوك في ظروفه، لا كل استدعاء لاحق. وتصف Secure حالة DNSSEC ولا تقول إن النتيجة جاءت من الدور الأساسي. وتثبت الشهادة وقوع الإصدار لا المسار الذي قاد إليه. ويسجل نصاب MPIC التأييد، لا DNSSEC الإلزامي لدى كل عضو.

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

حدود ما يمكن أن تثبته المصادر العامة

لا تكشف المصادر العامة هل نفذت أي جهة إصدار مسودة SC100 بالفعل، ولا كيف تنظم محللاتها الداخلية، ولا ماذا تحفظ سجلات الإصدار. لا يثبت التصويت بالإجماع النشر التشغيلي، وغياب التفاصيل العلنية لا يثبت عدم الامتثال. ولا يحدد المقال أي إصدار خاطئ أو تسميم DNS أو إخفاء سجل.

كذلك لا تستطيع المصادر توقع تقديم إشعار استبعاد قبل 5 سبتمبر، أو تغير النص المقبول، أو رقم الإصدار اللاحق. تبقى الصياغة الدقيقة للحالة: اجتاز التصويت، والمراجعة مفتوحة، والإصدار الحالي لم يتغير.

المصادر