Skip to main content
Resources

نقل منطقة الجذر KSK

هذه الصفحة متوفرة باللغات:

Root Zone KSK Rollover

نظرة عامة
الموارد
المشاركة
خلفية
مسودة الجدول الزمني
الخطط التشغيلية

نظرة عامة

تخطط ICANN لنقل مفتاح توقيع لمفتاح تنفيذ امتدادات أمان لنظام اسم النطاق لمنطقة الجذر (DNSSEC) كما هو مطلوب في بيان ممارسات منطقة جذر KSK مشغل DNSSEC [TXT, 99 كيلو بايت].

ويقصد بتدوير KSK استخراج أزواج مفاتيح تشفيرية جديدة سواء عامة أو خاصة بالإضافة إلى توزيع المكون العام الجديد على الأطراف التي تشغِّل وحدات حل التوثيق، بما في ذلك: مزودو خدمات الانترنت؛ ومديرو شبكة المؤسسة ومشغلو وحدات حل نظام اسم النطاق (DNS) الآخرون؛ ومطورو برمجيات وحدات حل DNS؛ والقائمون على تكامل النظام؛ وموزعو الأجهزة والبرمجيات الذين يقومون بتثبيت "مرتكز الثقة" أو شحنه." ويستخدم مفتاح التوقيع الرئيسي KSK في التوقيع المشفر لمفتاح الدخول لمنطقة الجذر (ZSK) والذي تستخدمه الجهة القائمة على صيانة منطقة الجذر من أجل توقيع DNSSEC لمنطقة جذر نظام أسماء النطاقات DNS الخاص بالإنترنت.

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

تم إعداد خطط نقل KSK بواسطة شركاء إدارة منطقة الجذر؛ ICANN بدورها بوصفها مشغل IANA، و Verisign بوصفها المشرف على منطقة الجذر، والإدارة الوطنية الأمريكية للاتصالات والمعلومات (NTIA) التابعة لوزارة التجارة الأمريكية بصفتها مدير منطقة الجذر. سوف تشمل الخطط دمج نقل مجتمع منطقة الجذر KSK تصميم توصيات الفريق [PDF, 1.01 ميجابايت] مع تعديل هذه التوصيات لتلبي المتطلبات التشغيلية والمعوقات. الآن تم وضع هذه الخطط بشكل جماعي، سوف يتم تنفيذ نقل KSK المستقبلي بواسطة ICANN وفقًا لهذه الخطط.

المصادر

يمكن العثور على المزيد من المعلومات والمصادر الإضافية على:

بادر بالمشاركة

اطرح سؤال، أرسل رسالة بريد إلكتروني إلى globalsupport@icann.org مع كتابة "نقل KSK" في العنوان لتقديم أسئلتك.

احضر حدثا
شاهد تقويم الفعاليات للعثور على عروض نقل KSK القادمة.

المشاركة في وسائل الاعلام الاجتماعية
استخدم وسم #KeyRoll للانضمام للمحادثة: https://twitter.com/icann

انضم لقائمة حادثة نقل KSK
قم بالتسجيل في القائمة البريدية للمناقشات العامة في القضايا ذات الصلة: https://mm.icann.org/listinfo/ksk-rollover

انشر الكلمة
شارك صفحة الويب هذه مع الآخرين لمساعدتهم في معرفة المزيد عن نقل KSK وكيف يمكن أن تتأثر.

الخلفية

تعاون شركاء إدارة ملفات منطقة الجذر RZM عام 2009 لنشر DNSSEC في منطقة الجذر، والتي بلغت ذروتها في أول نشر لمنطقة الجذر الموقعة والقابلة للمصادقة في يوليو 2010.

المتطلبات [PDF، 116 كيلو بايت] لتوليد والحفاظ على منطقة الجذر KSK بالإضافة إلى تحديد المسؤوليات المنوطة بكل من شركاء إدارة ملفات منطقة الجذر RZM من خلال NTIA. تم نشر الإجراءات حيث استوفى مشرف منطقة الجذر (Verisign) ومشغل وظائف IANA (ICANN) هذه المتطلبات في بيان ممارسة وسياسة الامتدادات الأمنية لنظام اسم النطاق DNSSEC (DPS) المنفصلة. Verisign DNSSEC توقيع اتفاقية خدمات [PDF، 138 كيلو بايت] مشغل KSK منطقة الجذر DPS [TXT, 99 كيلو بايت].

تم تعديل عقد وظائف IANA ما بين NTIA وICANN في يوليو 2010 لإدراج المسؤوليات المرتبطة بإدارة مفتاح الدخول الرئيسي KSKفي منطقة الجذر، وتم تنفيذ تلك المتطلبات المرحلة في المراجعات اللاحقة من ذلك العقد.

وتم تعديل الإتفاقية التعاونية ما بين NTIA وVerisign كذلك في يوليو 2010 لتعكس مسؤوليات مشغل مفتاح تسجيل منطقة الجذر ZSK لـ Verisign.

يتطلب عقد وظائف IANA من ICANN إجراء تغيير مفتاح الدخول الرئيسي لمنطقة الجذر KSK إلا أنه لا يحدد الجدول الزمني المفصل أو الخطة التنفيذية. يحتوي DPS مشغل مفتاح الدخول الرئيسي KSK لمنطقة الجذر على هذا البيان، بوضع متطلب للتغيير في قسم 6.5:

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

الخط الزمني للمسودة

هذه الأوقات قابلة للتغيير بناء على الاعتبارات التشغيلية.

  • 27 أكتوبر، 2016: تبدأ عملية تغيير KSK مع توليد KSK الجديد.
  • 11 يوليو، 2017: نشر KSK جديد في DNS.
  • 19 سبتمبر، 2017: زيادة حجم استجابة DNSKEY من خوادم أسماء الجذر.
  • سوف يتم الإعلان عن تواريخ أخرى عند تحديث خطط مشروع تبديل مفتاح التوقيع الرئيسي للجذر

الخطط التشغيلية

  1. خطة التنفيذ التشغيلية لتغيير مفتاح التوقيع الرئيسي لعام 2017 [ملف PDF، بسعة 741 كيلوبايت] - تصف بالتفصيل الخطوات التشغيلية لتنفيذ مشروع تغيير مفتاح التوقيع الرئيسي لعام 2017، وتشمل الجدول الزمني لعملية مكونة من ثماني مراحل. - يجري الآن تحديث هذا المستند من أجل إظهار التأجيل المعلن عنه في 27 سبتمبر/أيلول 2017.
  2. خطة إعادة تبديل مفتاح التوقيع الرئيسي لسنة 2017 [ملف PDF، سعة 506 كيلوبايت] - يصف الانحرافات المتوقعة من خطة التنفيذ التشغيلية بناء على الحالات الشاذة التي حدثت أثناء تنفيذ الخطة التشغيلية.- يجري الآن تحديث هذا المستند من أجل إظهار التأجيل المعلن عنه في 27 سبتمبر/أيلول 2017.
  3. خطة الاختبار الخارجية لتغيير مفتاح التوقيع الرئيسي لعام2017 [ملف PDF، بسعة 516 كيلوبايت] - تغطي الإعداد لبيئات الاختبار التشغيلية، التي يتم الوصول إليها بواسطة جمهور الإنترنت العام، لتقييم ما إذا كانت النظم الخارجية معدة للمشاركة في تغيير مفتاح التوقيع الرئيسي أم لا.
  4. خطة مراقبة تغيير مفتاح التوقيع الرئيسي لعام 2017 [ملف PDF، بسعة 480 كيلوبايت] - تصف خطة مراقبة تأثيرات تغيير مرتكز الثقة لمنطقة الجذر في حركة مرور البيانات تجاه خوادم الجذر.
  5. خطة اختبار نظم تغيير مفتاح التوقيع الرئيسي لعام 2017 [ملف PDF، سعة 519 كيلوبايت] - تصف الإجراءات المطلوبة لاختبار التغييرات التي حدثت على بنية ICANN التحتية المشاركة في تغيير مفتاح التوقيع الرئيسي.

خطة الاتصالات

تقوم ICANN بتنفيذ حملة توعية واسعة لضمان أن أولئك الذين يستخدمون KSK حالياً يعرفون بشأن التغيير.

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."