Skip to main content

القصة وراء قرار ICANN بتأجيل تبديل مفتاح التوقيع الرئيسي

الغالبية من الناس الآن على دراية بالقرار الذي أعلنته ICANN لتأجيل تغيير مفتاح التشفير الذي يساعد على حماية نظام أسماء النطاقات (DNS). حيث كان من المقرر تنفيذ هذا التغيير أو "التبديل" في 11 أكتوبر/تشرين الأول.

وأود أن أقدم بعض التفاصيل الإضافية حول ما جرى بخصوص قرارنا بتأجيل عملية التبديل. ولكم أن تقولوا بأن هذه هي القصة وراء القصة.

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

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

ولم يتم الانتهاء من البروتوكول إلا في أبريل/نيسان 2017، على الرغم من أنه مدعوم فقط من خلال الإصدارات الأحدث لبعض برامج تحويل اسم النطاق إلى عنوان IP المقابل له (BIND 9.10.5b1 وإصدار 9.11.0b3 والأحدث منه بالإضافة إلى Unbound 1.6.4 والأحدث منه). وفي البداية، لم يكن من المتوقع لهذا البروتوكول أن يُنشر على نطاق واسع بما يكفي لتوفير معلومات مفيدة من أجل أول عملية تبديل لمفتاح التوقيع الرئيسي للجذر.

وعلى الرغم من ذلك، اكتشفت بعض الأبحاث الأولية (من خلال شركة VeriSign وبعد ذلك ICANN) عددًا متناميًا من جهات التوثيق تبلغ عن تكوين مرتكز الثقة إلى خوادم الجذر. وتشيل البيانات القدامة من ستة عناوين لخوادم الجذر إلى أنه بالنسبة لشهر سبتمبر 2017، أرسل حوالي 12,000 عنوان مصدر IP فريد تقارير حول تكوين مرتكزات الثقة. وعدد من يقدمون تقارير في تزايد والآن يصل إلى 1400 عنوان فريد لكل يوم.

وتشير تلك التقارير القادمة إلى أن حوالي 5% من جهات التوثيق الإجمالية وحوالي 6%-8% في أي يوم محدد يبلغون بأنها يستخدمون KSK-2010، وهو مفتاح الجذر الرئيسي الذي يوقع حاليًا DNSKEY RRset لمنطقة الجذر. ومن الأهمية بمكان أن هذه الجهات المعنية بالتوثيق لن تقوم بتحويل اسم النطاق إلى عنوان بروتوكول الإنترنت المقابل له بشكل صحيح بعد عملية تبديل مفتاح التوقيع الرئيسي للجذر المخطط لها.

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

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

وثمة أسباب عدة وراء قيام جهة التوثيق بالإبلاغ فقط عن KSK-2010: تكوين قديم مع مرتكز ثقة مكوّن من الناحية الثابتة (على سبيل المثال بيان "المفتاح المعتمد" لبرنامج BIND) أو فشل في التحديث التلقائي لمرتكز الثقة باستخدام بروتوكول التحديث التلقائي RFC 5011 بسبب عيب برمجي، أو خطأ من المشغل أو سبب آخر.

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

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

Comments

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