Skip to main content
Resources

تبديل مفتاح توقيع شفرة الدخول الأساسية لمنطقة الجذر

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

للوقوف على مستجدات الحالة، يرجى الاطلاع على صفحة الحالة الراهنة لتبديل المفتاح. وسيتم إرسال التحديثات إلى القائمة البريدية للبريد الإلكتروني https://mm.icann.org/listinfo/ksk-rollover. و إذا كنت تواجه أي حالة طارئة في وحدة حل التصديق الخاصة بك، فيرجى الاطلاع على المعلومات التالية على الفور.

Root Zone KSK Rollover

نظرة عامة
الموارد
المشاركة
الخلفية
الإطار الزمني التمهيدي
الخطط التشغيلية
خطة الاتصالات

الأخبار

1 فبراير/شباط 2018 – إعلان الخطة التمهيدية للمتابعة في تنفيذ عملية تبديل مفتاح توقيع شفرة الدخول الأساسية

18 ديسمبر/كانون الأول 2017 – إحاطة حول مشروع استبدال مفتاح توقيع شفرة الدخول الأساسية لمنطقة الجذر

27 سبتمبر/أيلول 2017 – تأجيل تبديل مفتاح توقيع شفرة الدخول الأساسية

7 سبتمبر/أيلول 2017 – نرجو من مشغلي الشبكات وموفري خدمة الإنترنت الانتباه: حدد استعدادك لاستبدال مفتاح الدخول الرئيسي لمنطقة الجذر!

27 أكتوبر/تشرين الأول 2016 – بدء عمليات تبديل مفتاح توقيع شفرة الدخول الأساسية

شاهد المزيد من الأخبار.

التحديثات الفنية

1 فبراير/شباط 2018 – إعلان الخطة التمهيدية للمتابعة في تنفيذ عملية تبديل مفتاح توقيع شفرة الدخول الأساسية

18 ديسمبر/كانون الأول 2017 – إحاطة حول مشروع استبدال مفتاح توقيع شفرة الدخول الأساسية لمنطقة الجذر

17 أكتوبر/تشرين الأول 2017 – تأجيل تبديل مفتاح توقيع شفرة الدخول الأساسية

27 سبتمبر/أيلول 2017 – ICANN تعلن عن تأجيل لعملية تبديل مفتاح توقيع شفرة الدخول الأساسية

4 سبتمبر/أيلول 2017 – التحقق من مرتكزات الثقة الحالية في وحدات الحل الموثقة لنظام DNS

4 سبتمبر/أيلول 2017 – تحديث وحدات الحل الموثقة لنظام DNS بمرتكز الثقة الأحدث

11 يوليو/تموز 2017 – نشر مفتاح توقيع شفرة الدخول الأساسية-2017 في نظام أسماء النطاقات

نظرة عامة

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

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

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

تم إعداد خطط تبديل مفتاح توقيع شفرة الدخول الأساسية من خلال شركاء إدارة منطقة الجذر؛ ومؤسسة ICANN بدورها مشغلاً لوظائف IANA، وشركة VeriSign بوصفها المشرف على منطقة الجذر، والإدارة الوطنية الأمريكية للاتصالات والمعلومات (NTIA) التابعة لوزارة التجارة الأمريكية بصفتها مدير منطقة الجذر. انتهي دور إدارة NTIA في 1 أكتوبر 2016. نُشرت خطط تغيير مفتاح التوقيع الرئيسي في يوليو/تموز 2016 وتتضمن إعادة تصميم مفاتيح الدخول الرئيسية لمنطقة الجذر الخاصة بالمجتمع توصيات فريق التصميم [ملف PDF، سعة 1.01 ميغابايت].

المصادر

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

المشاركة

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

احضر فعالية
شاهد تقويم الفعاليات للعثور على العروض التقديمية لتبديل مفتاح توقيع شفرة الدخول الأساسية القادمة.

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

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

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

نبذة

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

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

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

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

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

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

الجدول الزمني

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

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

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

  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 حالياً يعرفون بشأن التغيير.

أرشيف الأخبار

3 أكتوبر/تشرين الأول 2016 – في البداية: سوف تنشئ ICANN مفتاح DNSSec جديدًا (InfoWorld)

19 سبتمبر/أيلول 2016 – يجري تغيير المفتاح التشفيري الذي يؤمّن الويب للمرة الأولى (اللوحة الرئيسية)

15 سبتمبر/أيلول 2016 – تُعِد ICANN عالم الويب من أجل إجراء تحديث رئيسي لأمن DNSSEC (الإصدار 3)

25 أغسطس/آب 2016 – يجري تغيير مفتاح DNSSEC الرئيسي الذي يؤّمن الإنترنت. هل يجب أن نقلق؟ (Techworld)

22 يوليو/تموز 2016 – DNSSEC: Rolling the Root Zone Key Signing Key

20 يوليو/تموز 2016 – ICANN على وشك أن تبدّل المفتاح السري للإنترنت (Domain Incite)

21 يونيو/حزيران 2016 – أفضل الممارسات الأمنية: توثيق DNSSEC

9 مايو/أيار 2016 – تغيير المفاتيح الخاصة بمنطقة جذر نظام أسماء النطاقات (DNS)

A note about our terms of service:

We have updated our electronic terms of service to provide greater transparency and align with laws applicable to us. Learn more.

This site uses cookies to deliver an efficient user experience and to help us see how the site is used. Learn more.OK

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."