الخلاصة

  • يتناول تقرير مجموعة ICANN التقنية حالة يخرج فيها اسم DNS من نطاق الحل العالمي، بينما يستمر الاسم المطابق في نظام تسمية بديل. ويعتمد استمرار الاسم الثاني على قواعد ذلك النظام ورغبة المسجل في الاحتفاظ به.
  • يتطلب مبدأ «الاسم نفسه، وصاحب السيطرة نفسه» قواعد لكل انتقال: من يجيز التغيير، وما الذي يؤكد اكتماله في كل نظام، وكيف يُحتوى الخلل قبل إعادة تخصيص الاسم.

ما الذي ينتهي عند انتهاء التسجيل؟

لنفترض أن مسجلاً ترك example.tld ينتهي في DNS، لكنه أراد الاحتفاظ بالاسم ذاته في نظام تسمية آخر. يورد التقرير الأولي لمجموعة Technical Study Group هذا السيناريو بوصفه احتمالاً تشغيلياً، لا حادثة وقعت ولا سياسة موحدة لكل الأنظمة. يُحجب اسم DNS عن الحل العالمي. أما الاسم البديل فيمكن أن يظل نشطاً إذا سمحت قواعد النظام الآخر بذلك وأراد المسجل الاحتفاظ به.

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

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

التقرير التقني ليس موافقة على خدمة

شكلت ICANN المجموعة التقنية لدراسة إمكان ربط نطاق عام أعلى من DNS العالمي بالاسم ذاته في نظام بديل، مع الحفاظ على أمن DNS واستقراره. يحمل التقرير الأولي المؤرخ 10 أغسطس 2026 صفة المسودة. فهو لا يوافق على خدمة بعينها ولا يجعل نموذجاً معمارياً إلزامياً. ويناقش نظام تسجيل مشتركاً (SRS) وحلاً موزعاً يعتمد على «مصدر موحد للحقيقة» (USoT).

توضح صفحة التعليق العام لدى ICANN أن كل مشغل سجل يريد تقديم هذه الخدمة عليه المرور منفرداً بعملية تقييم خدمات السجل (RSEP). سيُسترشد بالتقرير في الطلبات المستقبلية وصياغة الشروط التعاقدية، بينما ستُطرح مسودة التعديلات التعاقدية في إجراء عام لاحق. أُغلق باب التعليقات في 21 سبتمبر، وتذكر الصفحة أن موعد التقرير هو 16 نوفمبر 2026.

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

كل نموذج يحتاج إلى دليل

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

أما USoT فيسمح بتوزيع البيانات والتنفيذ بين أنظمة متعددة. لكنه يثير أسئلة تشغيلية دقيقة: أي حالة تُعتمد عندما يصل التغيير إلى نظام دون الآخر؟ كيف يتلقى المشاركون التحديث؟ ومن يقرر ما إذا كان التأخير فشلاً أم خطوة لم تكتمل؟ لا يكفي وصف مصدر البيانات بأنه موحد إذا لم توجد قواعد للتعامل مع الانقطاع والردود المتعارضة.

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

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

تعليقات تطلب حالة يمكن رؤيتها

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

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

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

لذلك ينبغي أن يجيب كل طلب خدمة عن أسئلة محددة: من يجيز التجديد أو النقل أو التعليق أو الإزالة؟ ما التأكيد الذي يصل من كل نظام؟ كم يمكن أن تبقى المعاملة معلقة؟ ما الذي يمنع منح اسم DNS من جديد ما دام نظيره القديم نشطاً في نظام آخر؟ ومن يصحح السجل عند الاعتراض؟

تسجيل أثر كل انتقال

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

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

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

المصادر