نموذج حوكمة خوادم الجذر المقترح يتيح تعليق مشغّل، لكنه لا يعرّف طريق إعادته

الخلاصة

• يجيز النموذج النهائي، في مرحلة Governance مستقبلية مكتملة الصلاحيات، لوظيفة Security Incident Reporting تعليق عمليات RSO عندما يشكل عدم الامتثال في حالة قصوى تهديدا كبيرا لنظام RSS. ولا تنشأ هذه الصلاحية إلا بعد أحد عشر معلما وتقييما علنيا ومشاورة وتصويتا رسميا؛ ولا يثبت السجل العام المدروس أنها قائمة الآن.
• تتبع الإزالة الدائمة مسارا آخر هو DNR: تحقيق، وفرص كافية للتصحيح، وتوصية إلى Council، ثم تنسيق الإزالة المنظمة من مصادر DNS الثلاثة المبينة في RSSAC030. ولا يحدد النموذج ما إذا كان تعليق SIR يمس تلك المصادر، أو مدة التعليق، أو أثر الطعن، أو الجهة التي تعيد المشغّل.
• ينبغي قبل Milestone 12 اعتماد سجل متعاقب الإصدارات للتعليق والعودة. ينشر السلطة والنطاق والمدة والتصحيح والطعن والنتيجة، مع إبقاء الأدلة التي قد تساعد مهاجما في ملحق محمي.

فعل قوي يتبعه فراغ إجرائي

بنى RSS Governance Working Group نموذجه على ثلاث مراحل، وخمس وظائف، وCouncil، وSecretariat، ومجتمعات مشاركة. وهو لا يكتفي بوصف التعاون؛ بل يتصور بنية قادرة لاحقا على اتخاذ قرارات وإنفاذها.

في هذا التصور، تبدأ وظيفة SIR بتعريف الحوادث، وتنظيم الإبلاغ عنها، ومراجعة أسبابها، وتطوير الضوابط، والتدقيق، ومعالجة مواطن الضعف، والتواصل مع أصحاب المصلحة. وعند بلوغ Governance Phase تحصل على صلاحيات أوسع: فتح التحقيق، وطلب البيانات والتعاون، وفرض تحسينات أمنية، وإنفاذ السياسات، واتخاذ إجراءات تصحيحية، والسماح بأعمال طارئة. وفي الحالة الأشد يمكنها «تعليق عمليات RSO» إذا كان عدم الامتثال يهدد RSS تهديدا كبيرا.

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

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

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

هذا ليس اتهاما لأي مشغّل قائم، ولا دليلا على أن ICANN أو RSSAC أو IANA تملك اليوم سلطة التعليق المقترحة. إنه سؤال تصميم ينبغي حسمه قبل تفعيل السلطة.

النموذج لم يصبح سلطة نافذة

يحمي التصميم المرحلي النموذج من القراءة المتعجلة.

تؤسس مرحلة Initiation الـ Council والـ Secretariat، مع نطاق محدود عمدا. أما Establishment فتحدد وظائف SAP وFRM وPME وSIR وDNR، وتكتب مواثيقها، وتضع سياسات الأمن والأداء والتمويل والتعيين والإزالة والإجراءات العادلة والطعن.

ولا يكفي بعد ذلك إعلان الجاهزية. يجب إنشاء كل الوظائف وتشغيلها، وتصديق السياسات الجوهرية، وتوثيق إكمال Milestones 1–11 في تقييم شامل متاح للجمهور. وتسبق الانتقال مشاورة عامة، ويجري التشاور مع المجتمعات المشاركة لتحقيق التوافق، ثم يصوت Council رسميا على الجاهزية. عندئذ فقط يبدأ Milestone 12 الصلاحية الكاملة.

المواد العلنية التي جرى فحصها لا تسجل هذا الانتقال. وافق فريق العمل على التقرير بتوافق في 18 فبراير 2026، وقدمه رئيسه إلى الأطراف المعنية في 20 فبراير. وردت رئيسة Board في ICANN بالشكر والتطلع إلى المسار المقبل. لم تقل الرسالة إن النموذج اعتُمد أو نُفذ. كما أن خطة تشغيلية توقعت اعتماد Board وربطت التنفيذ اللاحق بقرار وأولوية مستقبلين؛ التوقع ليس قرارا نافذا.

لذلك يستخدم هذا المقال صيغة المستقبل: النموذج سيتيح التعليق إذا اكتملت شروطه. ولا ينسب تلك الصلاحية إلى هيئة حالية.

زمن SIR ليس زمن DNR

تقسيم الوظائف يحمي الاستجابة السريعة والعدالة في آن واحد.

تنطلق SIR من حادث أمني. قد تصل المعلومات وهي ناقصة، وقد يلزم الاحتواء خلال دقائق. وتدور مهمتها حول سلامة RSS وتوفره وصحة بياناته وسرية ما ينبغي حمايته.

أما Designation and Removal فتنطلق من أداء المشغّل ووضعه. تحقق في المخاوف أو عدم الامتثال، وتعمل معه على المعالجة ضمن آجال محددة، ولا توصي بالإزالة إلا إذا أخفق في بلوغ المعايير بعد فرص كافية للتصحيح. ويملك Council القرار النهائي، ثم تنسق DNR الإيقاف المنظم والإزالة من مصادر DNS بالتواصل مع IANA.

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

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

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

RSSAC030 يكشف ثلاث طبقات مختلفة

يوضح RSSAC030 أين يتحول الوضع المؤسسي إلى أثر تقني. فهو يذكر ثلاثة مصادر رئيسية يديرها مشغّل وظائف IANA: ملف root hints، ومنطقة الجذر، ومنطقة root-servers.net. وتربط تلك المصادر أسماء خدمة الجذر بعناوين IPv4 وIPv6 التي يتحكم فيها RSO. كما أن إدراج معلومات المؤسسة فيها هو ما يعرّفها بوصفها مشغّلا في النظام المشترك.

يحيل النموذج النهائي إلى RSSAC030 في نطاق DNR: تنسق الوظيفة الإيقاف المنظم وإزالة RSO من مصادر الجذر. ولا تستخدم فقرة تعليق SIR الوصف نفسه.

ينبغي لذلك فصل ثلاث طبقات. الأولى حالة الحوكمة: إعلان المشغّل معلقا. الثانية الحالة التشغيلية: تقييد خدمة أو بنية أو مجموعة من النسخ أثناء المعالجة. الثالثة حالة المصادر: تعديل ملف أو منطقة تحت إدارة IANA.

لا يستلزم تعليق مؤسسي حذف مدخل من المصادر. ولا يعني عزل مكوّن أثناء حادث إزالة دائمة. وإذا مس إجراء SIR مؤقت تلك المصادر، وجب أن يبيّن سنده المنفصل، ونطاقه، وطريق عكسه، حتى لا يحقق التعليق أثر الإزالة قبل مسار DNR وقرار Council.

لا يفرض السجل المقترح نتيجة تقنية واحدة لكل حالة. بل يمنع أن تستخدم الجهات كلمة واحدة لنتائج مختلفة.

الطعن لا يعيد الخدمة تلقائيا

يوفر النموذج طعنا أمام Council في قرارات SIR، وطعنا مباشرا في قرارات DNR. كما تخضع توصية الإزالة للموافقة النهائية، وتوجد مراجعات نظراء وتقييمات خارجية وتقارير سنوية.

لكن وجود الطعن لا يحدد الحالة أثناء نظره.

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

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

دون سجل مشترك، قد يفهم SIR وCouncil والمشغّل وIANA العبارة نفسها بطرق مختلفة في أكثر لحظة تحتاج فيها البنية الأساسية إلى اليقين.

يمكن إظهار السلطة من دون كشف الهجوم

يضع RSSAC062 حدا عمليا للشفافية. فهو يعالج الحوادث ذات الأثر المادي في توفر RSS أو سلامته أو سريته، ويؤكد أن الإبلاغ لا ينبغي أن يعرقل المعالجة، وأن حل الحادث يأتي أولا.

يمكن تقييد التفاصيل بعلامات Traffic Light Protocol، ويجب حذف ما قد يساعد في هجوم لاحق. كما ينبغي أن تكون قنوات التسليم موثقة ومحمية. وفي الوقت نفسه، توصى البنية المستقبلية بنشر نسخة عامة TLP:Clear في الوقت المناسب.

يمكن لسجل التعليق والعودة أن يتبع المبدأ ذاته. تُنشر الجهة التي تصرفت، والقاعدة المطبقة، والفئة العامة للسبب، والنطاق، والموعد التالي للمراجعة، والنتيجة الحالية. ويبقى في الملحق المحمي ما يتعلق بالمفاتيح، والبنية الداخلية، والسجلات الخام، ومواطن الضعف، وأدلة التحقيق.

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

أقوى دفاع عن النموذج يقود إلى إكماله

من المعقول أن يترك Functional Model التفاصيل إلى Establishment Phase. فمن سيكتب مواثيق SIR وDNR سيكون أقدر على دمج خبرة الاستجابة، واستقلال المشغلين، وحماية الأدلة، والتنسيق مع IANA.

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

وقد تجعل وفرة RSS وتنوعه عزل عنصر خطر مؤقتا وسيلة لحماية الخدمة الجماعية. رفض أي أداة طوارئ قد يكون بدوره مخاطرة.

لكن ترك التفصيل للمستقبل يكون سليما فقط إذا أصبح اكتماله شرطا للتفعيل. Milestone 7 يضع سياسة الأمن والاستجابة والتصعيد. Milestone 8 ينظم التعيين والإزالة والإجراءات والطعن. Milestone 10 يستكمل المساءلة والمراجعة. وينبغي للتقييم العام قبل Governance أن يثبت أن هذه العناصر تشكل سلسلة واحدة من التعليق إلى العودة أو إلى DNR.

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

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

سجل متعاقب من التعليق إلى العودة

ينبغي للـ Council أن يعتمد قبل Milestone 12 سجلا مشتركا لكل تعليق. يفتح فور الإجراء بحد أدنى من البيانات، ثم يستكمل بعد استقرار الوقائع، من دون تأخير الاحتواء.

وتتضمن طبقته العامة:

• معرفا ثابتا للقضية ولـ RSO؛
• الوظيفة صاحبة القرار، والسند، وإصدار السياسة، والدور المسؤول؛
• فئة غير حساسة للسبب واستخدام المسار الطارئ من عدمه؛
• النطاق الدقيق على الوضع والخدمة والبنية ومصادر الجذر؛
• وقت النفاذ، والمدة الأولية القصوى، والمراجعة الإلزامية التالية؛
• وسائل حماية استمرارية RSS الجماعية؛
• الإجراءات التصحيحية وحالتها العامة؛
• أمين الأدلة المحمية وتصنيفها؛
• الطعن، وطلب وقف التنفيذ، والقرار فيه؛
• سلطة العودة ومعاييرها واختبار الجاهزية؛
• مراجعة النظراء أو المراجعة المستقلة؛
• كل تمديد مع قرار جديد وتاريخ وسبب؛
• الخاتمة: عودة، أو تضييق، أو استبدال، أو إحالة رسمية إلى DNR؛
• أي فعل منفصل من IANA أو RZM وحالة عكسه.

يجب ألا تختصر المصطلحات بعضها. قُدم طعن لا يعني أوقف التنفيذ. اكتمل التصحيح لا يعني أجيزت العودة. أحيل إلى DNR لا يعني أقرت الإزالة. أقرت الإزالة لا يعني عُدلت المصادر.

حتى الحالات السلبية ينبغي كتابتها: لا فعل في المصادر، لا طعن، قرار العودة قيد الانتظار. فالخانة الفارغة لا تميز بين عدم وقوع الحدث وتأخره وغياب المسؤول.

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

حدود الأدلة

لا تثبت المصادر المدروسة اعتماد Board الرسمي للنموذج، أو بدء Governance Phase، أو تعليق أي RSO وفقه. كما لا تسمح بالحكم على مشغّل حالي بأنه غير آمن أو غير ممتثل.

غياب كلمة إعادة لا يعني أن مواثيق المستقبل عاجزة عن إنشاء الإجراء. بل يعني أن إنشاءه ينبغي أن يسبق التفعيل. ولأن الأثر الفني لعبارة «تعليق العمليات» غير معرّف، لا يزعم المقال أنها تغير بالضرورة root hints أو منطقة الجذر أو root-servers.net.

موضوع النشر هو السلطة والحالة. أما الأدلة التي تساعد مهاجما أو تكشف سرا تشغيليا مشروعا فيمكن أن تبقى محمية.

المصادر

1. ICANN — The Root Server System Governance Structure، 18 فبراير 2026
2. ICANN — Governance Principles for the Root Server System
3. Brad Verd — تسليم تقرير GWG النهائي
4. Tripti Sinha — رد رئيسة Board في ICANN
5. ICANN Public Comment — Functional Model for Root Server System Governance
6. RSSAC030 — Statement on Entries in DNS Root Sources
7. RSSAC058 — Success Criteria for the RSS Governance Structure
8. RSSAC062 — Security Incident Reporting
9. RSSAC055 — Principles Guiding the Operation of the Public Root Server System
10. ICANN — مسودة الخطة التشغيلية والمالية FY2027–2031
11. Heng Lu — Running-Code Primacy
12. Heng Lu — The Registry Continuity Fallacy
13. Heng Lu — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile