سطح سيطرة سجل النطاقات الأربعة لشركة Beijing Qihu Keji: تفويض DNS وRDAP وتكاليف الاستمرارية

ملخص

• تُدرج ICANN شركة Beijing Qihu Keji Co., Ltd. مشغّلةً لنطاقات.anquanو.shoujiو.xihuanو.yun. يخضع كل منها لاتفاقية سجل أساسية غير مدعومة بتاريخ 8 يناير 2015.[5][6][7][8]
• خطاب تجديد خاص بالشركة من ICANN بتاريخ 18 أكتوبر 2024 يفيد بأن الاتفاقيات الأربع ستدخل فترات متتالية مدتها عشر سنوات تبدأ في 8 يناير 2025. يحافظ الخطاب على شروط الاتفاقيات؛ وهو دليل على استمرارية تعاقدية، لا شهادة جاهزية تشغيلية أو معيار إنتاج.[13]
• تنشر IANA سجلات تفويض منفصلة لنطاقات المستوى الأعلى الأربعة. تكشف تلك السجلات الحدود التشغيلية عبر حقول المنظمة الراعية وجهات الاتصال الإدارية والفنية وخوادم الأسماء المعتمدة وخدمات WHOIS وRDAP ومواد تفويض DNSSEC.[1][2][3][4]
• تحدد الاتفاقيات الموقعة سطح سيطرة دائم حول بيانات السجل، وتزويد المسجلين، وDNS، وخدمات بيانات التسجيل، والأمن، والاستمرارية، والإيداع الضام، والإبلاغ، والانتقال الطارئ. وهي لا تكشف البنية الخاصة لشركة Beijing Qihu ولا تثبت أن الالتزامات جميعها تُنفذ داخليًا.[9][10][11][12]
• التكلفة المتكررة ليست مجرد سعة خوادم. إنها العمل البشري والبرمجي اللازم للموافقة على التغييرات، والحفاظ على هوية الكائن بدقة، والتوفيق بين السجلات المستقلة، والتحقق من دلالات البروتوكولات، وإدارة تبعيات الموردين والمسجلين، والتحقيق في الأعطال الجزئية، واختبار الاستعادة، والاحتفاظ بالأدلة على مدى عمر العقد الطويل.

ملاحظة الصورة:الصورة التحريرية المولّدة المصاحبة تقدم سياقًا عامًا لعمليات السجل والشبكة، ولا تصور Beijing Qihu Keji أو ICANN أو IANA أو Tele-info أو أي منشأة حقيقية أو بنية فعلية أو موثوقية مقيسة أو حادثًا أو نتائج للعملاء.

أربع اتفاقيات تحدد أربعة كائنات تشغيلية

تظهر Beijing Qihu في الأدلة العامة كمشغّل سجل لأربعة نصوص:.anquanو.shoujiو.xihuanو.yun.[5][6][7][8] تعرض صفحات الاتفاقيات المشغّل نفسه، وتاريخ الاتفاقية نفسه، والصيغة الأساسية غير المدعومة. يجمع خطاب التجديد لعام 2024 الاتفاقيات الأربع ضمن إجراء تجديد مشترك، ويحدد لكل منها تاريخ بدء فترة متتالية في 8 يناير 2025.[13] هذا التجميع ملائم تشغيليًا، لكنه لا يحوّل مساحات الأسماء الأربع إلى كائن واحد.

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

هذا يجعل هوية الكائن أول متطلب للموثوقية. ينبغي لنظام مراقبة السجل أن يربط على الأقل:

• الكيان القانوني المحدد في الاتفاقية؛
• نص نطاق المستوى الأعلى الدقيق؛
• الاتفاقية والفترة الحالية؛
• قاعدة بيانات السجل المعتمدة؛
• معرّفات المسجلين والمعاملات؛
• كائن النطاق وحالة دورة حياته؛
• خوادم الأسماء المعتمدة وتفويض الأب؛
• مفاتيح DNSSEC والتوقيعات ومواد DS لدى الأب؛
• هويات خدمات WHOIS وRDAP؛
• ودائع إيداع البيانات وجهات اتصال الاستمرارية؛
• السلطة البشرية التي وافقت على تغيير جوهري.

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

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

الاستمرارية التعاقدية ليست موثوقية إنتاج

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

قدرة العقد، وموثوقية المنتج، ونتائج الإنتاج طبقات منفصلة.

قدرة العقدتصف ما يحق للمشغّل فعله وما يلتزم به. تعالج الاتفاقيات الموقعة خدمات السجل، والمواصفات الفنية، ومستويات الخدمة، وإيداع البيانات، والإبلاغ، والانتقال الطارئ، والأمن، والامتثال.[9][10][11][12] هذه الوثائق مرجعية للالتزامات والحدود.

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

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

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

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

سلطة السجل وظيفة دفتر أستاذ

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

يمكن التعبير عن التمييز عبر أربع طبقات:

1. طبقة الاتفاقية.تحدد سجلات ICANN المشغّل والعقد والتعديلات والإشعارات والالتزامات.[5][6][7][8]
2. طبقة الجذر والتفويض.تحدد سجلات IANA مدير أو راعي نطاق المستوى الأعلى وجهات الاتصال وخوادم الأسماء المعتمدة ونقاط نهاية الخدمة ومواد DNSSEC.[1][2][3][4]
3. طبقة معاملات السجل.تنشئ سير عمل EPP أو ما يعادلها وتجدد وتنقل وتحدّث وتعلّق وتستعيد وتحذف كائنات النطاق وفقًا للسياسة والتفويض.
4. طبقة التطبيقات.يستخدم حاملو النطاقات ومزودو الخدمات النطاقات للمواقع والبريد وواجهات برمجة التطبيقات والهوية وأنظمة أخرى خارج التشغيل المباشر للسجل.

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

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

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

السجلات المستقلة يجب التوفيق بينها لا تسويتها

صفحات ICANN الأربع وصفحات IANA الأربع تجيب عن أسئلة متصلة لكن مختلفة.[1][2][3][4][5][6][7][8] تنظم صفحات ICANN السجلات التعاقدية، وتعرض صفحات IANA معلومات التفويض والخدمة، وتحتفظ منصة السجل بحالتها الخاصة، وتراقب المراقبة سلوك الشبكة. يمكن أن تتغير هذه الدفاتر بجداول مختلفة وتستخدم تسميات أدوار مختلفة.

ينبغي لنظام مراقبة ناضج ألا يسوّيها في مؤشر «نشط» واحد، بل يحفظ المصدر والطابع الزمني والسلطة والدلالات لكل حقل:

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

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

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

تفويض DNS هو حدود الكود المشغّل

تجعل سجلات IANA تفويض DNS مرئيًا لكل من نطاقات المستوى الأعلى الأربعة.[1][2][3][4] تنشر معلومات خوادم الأسماء المعتمدة وحقول الاتصال والخدمة المرتبطة. هذه السجلات دليل أقوى على ما تم تكوين DNS العام لاستخدامه من صفحة تسويقية أو بيان مؤسسي عام.

لموثوقية التفويض مكونات مميزة عدة:

• تحتوي منطقة الأب على مجموعة خوادم الأسماء المقصودة؛
• عناوين glue المطلوبة صحيحة؛
• تصل مسارات IPv4 وIPv6 إلى الخدمة المعتمدة؛
• يخدم كل خادم معتمد المنطقة المقصودة؛
• تتفق الخوادم على حالة المنطقة ذات الصلة؛
• الاستجابات تتمتع بسلطة صحيحة وسلوك إجابة سلبية صحيح؛
• تشكل مواد DNSSEC سلسلة صالحة عند التمكين؛
• تميز المراقبة الاستجابات المعتمدة عن الإجابات التكرارية المخزنة مؤقتًا؛
• تُعزى التغييرات إلى حالة معتمدة؛
• يشمل التراجع كلا من التفويض وبيانات الأمان.

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

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

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

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

يجب أن تكون RDAP وWHOIS صحيحتين دلاليًا

تنشر صفحات IANA معلومات خدمة بيانات التسجيل لنطاقات المستوى الأعلى الأربعة.[1][2][3][4] القابلية للوصول أسهل خاصية للاختبار ومن أقلها كفاية. يمكن للخدمة أن تعيد نجاح HTTP بينما تقدم الكائن الخطأ أو حالة دورة حياة قديمة أو أحداثًا مشوهة أو بيانات خوادم أسماء غير متسقة أو معالجة خصوصية لا تطابق السياسة.

ينبغي أن يستخدم الاختبار الدلالي مجموعة مراقبة تتضمن:

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

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

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

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

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

EPP وتكامل المسجلين يحولان السياسة إلى معاملات

لا يخدم سجل نطاق المستوى الأعلى حاملي النطاقات عبر موقع ويب وحده. يحتاج المسجلون إلى واجهة معاملات مضبوطة لفحص الأسماء وإنشاء النطاقات وتجديدها وتغيير جهات الاتصال وخوادم الأسماء ونقل الرعاية وتطبيق أكواد الحالة والاستجابة للحالات الاستثنائية. يجعل إطار اتفاقية السجل هذه العلاقة التشغيلية جوهرية، رغم أن الوثائق العامة لا تكشف التنفيذ الخاص لشركة Beijing Qihu.[5][6][7][8][9][10][11][12]

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

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

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

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

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

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

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

تحتاج DNSSEC وبيانات الأمان إلى ضبط دورة الحياة

تتضمن سجلات IANA معلومات DNSSEC للمناطق المفوضة.[1][2][3][4] هذا يجعل بيانات الأمان جزءًا من سطح السيطرة القابل للملاحظة لا ميزة زخرفية. السلسلة الصالحة في لحظة ما دليل مفيد، لكن الثقة التشغيلية تعتمد على كيفية إدارة المفاتيح والتوقيعات وسجلات موقّع التفويض والتوقيت وإجراءات الطوارئ عبر تغييرات متكررة.

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

ينبغي أن تحدد خطة التغيير:

1. حالة المفتاح الحالية والمقصودة؛
2. السجلات الدقيقة المتوقعة لدى الطفل والأب؛
3. افتراضات الانتشار والمخازن المؤقتة؛
4. نقاط المراقبة وأوامر التحقق؛
5. عتبة الاستمرار أو الإيقاف المؤقت؛
6. المالك لكل تسليم خارجي؛
7. حالة التراجع وأحدث وقت آمن للإلغاء؛
8. الأدلة المحتفظ بها بعد الإنجاز.

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

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

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

يُظهر خطاب تجديد نطاقات المستوى الأعلى الأربعة أن العلاقة التعاقدية تجددت لفترات تبدأ في يناير 2025.[13] وهو لا يثبت وجود أي مراسم مفاتيح محددة أو منصة مراقبة أو تصميم أجهزة أو اختبار استعادة. تلك ادعاءات تنفيذية ينبغي تقييمها بأدلة تنفيذية.

الإيداع والاستمرارية وأدلة الاستعادة

استمرارية السجل مختلفة عن النسخ الاحتياطي العادي لموقع ويب. الكائن القيّم ليس مجرد مجموعة ملفات، بل سجل متماسك مصرح به لكائنات النطاق وعلاقات المسجلين وحالات دورة الحياة وتاريخ المعاملات وتهيئة DNS وجهات الاتصال وبيانات الأمان وغيرها من البيانات اللازمة لاستعادة الخدمة أو نقلها. تؤطر اتفاقيات السجل التزامات الاستمرارية على مستوى عام، بينما لا تكشف الوثائق العامة بنية الاستعادة الخاصة لشركة Beijing Qihu.[5][6][7][8][9][10][11][12]

ينبغي فصل ثلاثة أسئلة:

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

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

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

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

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

تكاليف الإشراف والتكامل والصيانة والاستثناءات

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

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

تكلفة التكامل.يتبادل المسجلون وأنظمة DNS والعمليات المتجهة إلى IANA وخدمات بيانات التسجيل وأدوات الأمان والفوترة والإبلاغ وأنظمة الدعم الحالة. تحتاج كل واجهة إلى تحكم بالإصدار وتركيبات اختبار وإدارة بيانات اعتماد وملاحظة وتسوية فشل. ترتفع تكلفة التكامل عندما تختلف المعرّفات أو تكون الدلالات ضمنية أو تنجح عملية في نظام وتفشل في آخر.

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

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

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

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

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

سجل أوضاع الفشل

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

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

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

اقتصاديات الوحدة والبدائل الواقعية

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

يمكن لنموذج العناية الواجبة تقسيم التكلفة إلى:

• عمل الحوكمة والامتثال الثابت؛
• عمل التفويض وDNSSEC والسياسة والإبلاغ لكل نطاق مستوى أعلى؛
• عمل إدراج ودعم لكل مسجل؛
• تكلفة معالجة لكل معاملة؛
• تكلفة الاستثناءات والحوادث؛
• التزامات الموردين والبنية التحتية؛
• اختبار الاستمرارية وقدرة الاستعادة المحتفظ بها؛
• تكلفة الترحيل والخروج.

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

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

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

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

إطار مراجعة قابل للتكرار

يمكن لمشترٍ أو منظم أو مسجل أو مالك مخاطر داخلي مراجعة سطح سيطرة Beijing Qihu في سبع مراحل.

1. تحديد الهوية والنطاق.تأكيد الكيان القانوني والتشغيلي الدقيق ونطاقات المستوى الأعلى الأربعة والاتفاقيات وأدوات التجديد المطبقة والتمييز بين أدوار السجل والمسجل وحامل النطاق ومشغّل DNS ومنطقة الجذر.[1][2][3][4][5][6][7][8][13]

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

3. التوفيق بين السجلات العامة والخاصة.قارن سجلات العقود وبيانات تفويض IANA وحالة السجل وملاحظات البروتوكول وأدلة الاستعادة دون معاملة أي مصدر كامل. احفظ المصدر والوقت لكل مقارنة.

4. اختبار العمليات المتكررة.جرب إجراءات دورة حياة EPP تمثيلية وتغييرات DNS وانتقالات DNSSEC ودلالات RDAP وWHOIS وتدوير بيانات الاعتماد وإنذارات المراقبة والتوفيق بعد نتائج غير مؤكدة. حدد معايير النجاح قبل الاختبار.

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

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

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

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

الخلاصة

يوفر السجل العام لشركة Beijing Qihu كائنًا محدودًا واضحًا بشكل غير معتاد لأبحاث شركات التقنية: أربعة نطاقات مستوى أعلى مفوضة وأربعة سجلات اتفاقية سجل وأربع اتفاقيات موقعة وأداة تجديد تغطي فترات تبدأ في 2025.[1][2][3][4][5][6][7][8][9][10][11][12][13] تثبت تلك السجلات هوية المشغّل والاستمرارية التعاقدية وأسطح سيطرة مساحات أسماء قابلة للملاحظة، ولا تثبت البنية الخاصة أو جاهزية التشغيل أو السعة أو تاريخ الحوادث أو نتائج العملاء.

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

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

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

المصادر

1. قاعدة بيانات منطقة جذر IANA:.anquan
2. قاعدة بيانات منطقة جذر IANA:.shouji
3. قاعدة بيانات منطقة جذر IANA:.xihuan
4. قاعدة بيانات منطقة جذر IANA:.yun
5. اتفاقية سجل ICANN:.anquan
6. اتفاقية سجل ICANN:.shouji
7. اتفاقية سجل ICANN:.xihuan
8. اتفاقية سجل ICANN:.yun
9. اتفاقية سجل.anquan الموقعة، 8 يناير 2015
10. اتفاقية سجل.shouji الموقعة، 8 يناير 2015
11. اتفاقية سجل.xihuan الموقعة، 8 يناير 2015
12. اتفاقية سجل.yun الموقعة، 8 يناير 2015
13. خطاب تجديد أربعة نطاقات مستوى أعلى لشركة Beijing Qihu Keji، 18 أكتوبر 2024