الخلاصة

  • غيّر نمو نطاقات gTLD الجديدة والمحافظ التي تضم مئات النطاقات وتحديثات DNSSEC المتكررة حجم العمل الذي كان على RZMS استيعابه.
  • أضافت إعادة البناء عتبات موافقة حسب نوع الطلب وطلبات متزامنة وواجهة API وفحوصًا تقنية مستقلة؛ وظلت على مديري TLD مسؤولية ضبط القواعد واستمرارية الحسابات.

التحليل

ازدياد الطلبات غيّر طبيعة العمل

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

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

إعادة بناء تناسب نطاق عمل جديد

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

يسجل سجل إصدارات IANA أن إصدار ديسمبر 2022 دعم أكثر من معتمدين اثنين، وحدد عتبات حسب نوع الطلب، وأضاف API وطلبات متزامنة. كما فصل الاختبارات الفنية عن نظام إدارة الطلبات حتى يمكن تحسين كل منهما دون ربط التغيير في أحدهما بالآخر.

ولا تعني صلاحية استخدام RZMS أن واجهة النظام تقرر وحدها ما يدخل منطقة الجذر. تشرح IANA أن مسؤولياتها تشمل تعيين مديري نطاقات المستوى الأعلى وتسجيل بيانات التفويض الفنية ونشر سجل للمعلومات ذات الصلة. وتفرق صفحتها التعريفية بين قاعدة بيانات تسجل المديرين والبيانات الفنية وجهات الاتصال، وملف DNS منفصل يحوي بيانات منطقة الجذر. الاعتماد خطوة في مسار الطلب، وليس ملكية للنطاق أو بديلًا عن المراجعة والتنفيذ.

الأمن وخيار استعادة الحساب

لم تكن المصادقة متعددة العوامل (MFA) شرطًا في الإطلاق الأول عام 2022. أشار Davies إلى ضرورة العمل في بلدان مختلفة، وإلى أن بعض العملاء قد لا يستخدمون النظام لسنوات. وإلى جانب منع الدخول غير المصرح به، يجب أن تسمح الضوابط للشخص المخول باستعادة الحساب عندما يفقد جهاز المصادقة أو رموز الاسترداد.

أظهرت دراسة عملية تحديث منطقة الجذر لعام 2022 اختلافًا في آراء المشاركين: رأى 82% أن إجراءات الأمن القائمة كافية، بينما ذكر 18% نقاط ضعف محتملة واقترح بعضهم MFA. هذه أرقام المشاركين في تلك الدراسة وليست إجماعًا حاليًا بين جميع المديرين. كما ناقشت الدراسة أن تقديم الطلبات في ذلك الوقت لم يقتصر على قائمة ثابتة من جهات الاتصال. استند Davies إلى هذه الظروف عندما شرح عدم فرض MFA على الجميع فورًا.

في يناير 2025، أعلن Davies عن MFA والتحقق من الهوية بوصفهما خيارين. أما إرشادات IANA المعدلة في يوليو 2026، فتشترط التحقق لتشغيل MFA أو استخدام API، لكنه ليس مطلوبًا لبقية استخدامات RZMS. لا تسمح API إلا بالأفعال التي يجيزها الحساب. ويوفر دليل API بيئة اختبار OTE التي لا تؤثر تغييراتها في الإنتاج.

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

التوسع ينقل مسؤولية الإعداد إلى المديرين

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

توسّع API نطاق التشغيل البرمجي، لكنها لا تتجاوز صلاحيات المستخدم. وتتيح بيئة Operational Test and Evaluation لدى IANA اختبار التكامل قبل استخدامه في الإنتاج. كما تبقى الفحوص التقنية منفصلة عن التفويض: استيفاء المتطلبات الفنية لا يعني اعتماد الطلب، والاعتماد لا يحل محل المراجعة الفنية أو التنفيذ.

RZMS جزء واحد من إدارة منطقة الجذر. تعيّن IANA مديري TLD وتسجل بيانات التفويض التقنية وتنشر Root Zone Database، وهي منفصلة عن ملف DNS لمنطقة الجذر. ويعرض سجل تغييرات يونيو 2026 الإصدار 3.6.1. تتمثل القيمة الدائمة لإعادة البناء في مسار عمل قابل للتكيف، لا في ضمان حسن ضبط كل مؤسسة له. ويتوقف الأداء على مواكبة قواعد التفويض المحلية واستعادة الحسابات والاختبارات التقنية لحجم العمل الفعلي.

المصادر