ملخص

  • إن عملية تبديل مفتاح توقيع المفتاح الجذر لـ DNSSEC التي قامت بها ICANN في أكتوبر 2018 غيرت مرساة الثقة العامة التي تستخدمها المحللات المتحققة من DNSSEC للتحقق من جذر DNS. يشير صفحة التبديل الخاصة بـ ICANN إلى أن المحلل الذي ليس لديه مرساة ثقة حالية لجذر DNS لن يتمكن من حل استعلامات DNS بعد التغيير، مما جعل الاستعداد قضية استمرارية وليس مجرد مهمة إدارية تشفيرية ضيقة.
  • أقوى حقيقة للمساءلة هي التأخير. أرجأت ICANN التبديل المقرر أصلاً في أكتوبر 2017 بعد أن أشارت قياسات RFC 8145 الجديدة إلى أن عددًا كبيرًا من المحللات المستخدمة من قبل مقدمي خدمات الإنترنت ومشغلي الشبكات قد لا تكون جاهزة. حوّل ذلك القرار مشكلة استعداد المشغل الخفية إلى سجل حوكمة عام.
  • ثم مضت ICANN في 11 أكتوبر 2018 بعد موافقة مجلس الإدارة والتعليق العام والتواصل المستمر والتحليل الفني وخطة منقحة. أعلنت ICANN بعد الحدث أن المشكلات القليلة التي لوحظت تم التخفيف منها بسرعة ولم تشير إلى فشل منهجي يتطلب التراجع.
  • كانت السيطرة العملية موزعة. سيطرت ICANN وهيئة المعرفات التقنية العامة على عملية حفل مفتاح الجذر والنشر والتوثيق والتواصل وقرار التبديل النهائي؛ وشغلت Verisign دور حافظ منطقة الجذر؛ وتحكم مشغلو المحللات في تكوين مرساة الثقة وسلوك البرنامج؛ وتحكم البائعون في جودة تنفيذ RFC 5011؛ وتحكمت الهيئات العامة والمؤسسات في التخطيط الاحتياطي لشبكاتها.
  • الدرس المستفاد من المساءلة هو أن تغييرات البنية التحتية للإنترنت العالمية تحتاج إلى استعداد ملحوظ ومعايير قرار منشورة ومراجعة مجتمعية وتفكير في التراجع الآمن والتواضع الكافي للتأخير عندما تقوض القياسات الثقة. نجح التبديل لأنه تم التعامل معه كمخاطر تشغيلية عامة، وليس لأن المخاطرة كانت وهمية.

كان مفتاح الجذر صغيرًا، لكن الاعتماد كان عالميًا

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

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

لم تكن KSK موجودة في عزلة. تصف صفحة التبديل الخاصة بـ ICANN التخطيط الأصلي على أنه عمل شركاء إدارة منطقة الجذر: ICANN بصفتها مشغل وظائف IANA، وVerisign بصفتها حافظ منطقة الجذر، وإدارة التجارة الأمريكية NTIA بصفتها مديرة منطقة الجذر قبل انتهاء دور NTIA في 1 أكتوبر 2016. توفر صفحة إدارة منطقة الجذر لـ IANA نقطة الدخول العامة الحالية لإدارة منطقة الجذر، بينما توفر صفحة KSK لمنطقة جذر DNSSEC لـ IANA معلومات عن مرساة الثقة وحفل KSK. لذلك فإن السجل التشغيلي يقع عند تقاطع حوكمة ICANN ووظائف PTI/IANA وعمليات منطقة الجذر لـ Verisign والعديد من مشغلي المحللات المستقلة الذين يستهلكون مرساة ثقة الجذر.

الهندسة التقنية الخاصة بـ DNSSEC تشرح سبب أهمية الحادث. RFC 4033 يعرف مقدمة DNSSEC ومتطلباته، RFC 4034 يعرف سجلات الموارد المستخدمة بواسطة DNSSEC، و RFC 4035 يعرف تعديلات البروتوكول. هذه المعايير ليست دليلاً على حادث خاص بـ ICANN. إنها تشرح سلسلة التحقق التي جعلت مفتاح الجذر ذا أهمية. المحلل المتحقق إما أن يكون لديه مسار ثقة يقبله أو لا. على عكس شهادة موقع ويب يمكن استبدالها بواسطة مشغل واحد لخدمة واحدة، فإن مرساة ثقة الجذر هي بنية تحتية مشتركة.

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

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

كان التأخير هو محور المساءلة

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

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

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

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

خلقت هذه اللغة معيارًا عامًا. لم تكن ICANN تعد بأن كل محلل متحقق سيعمل. كانت تعد بأن الأدلة الجديدة على الجاهزية ستغير القرار. في عمليات البنية التحتية، هذا هو الفرق بين تغيير مدفوع بالتقويم وتغيير مدفوع بالأدلة.

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

كانت أتمتة RFC 5011 مفيدة، وليست سحرية

اعتمد التبديل بشكل كبير على سلوك التحديث التلقائي لمرساة الثقة. RFC 5011 تحدد التحديثات التلقائية لمراسي الثقة DNSSEC. جاذبية RFC 5011 واضحة: يمكن للمحلل المتحقق مراقبة المفتاح الجديد خلال فترة إضافة-احتفاظ وقبوله تلقائيًا كمرساة ثقة. بدون مثل هذه الآلية، سيحتاج كل مشغل محلل متحقق إلى تثبيت يدوي للمفتاح على نطاق الإنترنت.

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

صفحة تبديل KSK لـ Verisign التقطت هذا التمييز من منظور حافظ منطقة الجذر ومشغل الخادم الجذري. قالت إن كل محلل DNSSEC يحتاج إلى مرساة ثقة وأن RFC 5011 لم يتم اختبارها مطلقًا في الإنتاج لتبديل KSK جذري. قالت أيضًا إن Verisign، بصفتها مشغل خادم أسماء جذري، تلقت بعض بيانات RFC 8145 وحللتها لتحديد المصادر التي يبدو أن لديها تكوين مرساة ثقة قديم. هذا مهم لأنه يظهر أن القياسات لم تكن مجرد لوحة تحكم مركزية لـ ICANN. كان بإمكان مشغلي الخوادم الجذرية أيضًا رؤية إشارات الجاهزية والتصرف بناءً عليها.

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

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

الدرس ليس أن RFC 5011 غير موثوقة. الدرس هو أن آليات التحديث التلقائي الموزعة بحاجة إلى قياسات وتنسيق اجتماعي عندما تحمي بنية تحتية مشتركة. يمكن للمعيار تحديد آلة الحالة. لا يمكنه جعل كل مشغل يفهم ما إذا كانت تلك الآلة تعمل بشكل صحيح في شبكته.

حول التعليق العام التغيير التقني إلى سجل حوكمة

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

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

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

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

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

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

كان التواصل جزءًا من السيطرة، وليس علاقات عامة

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

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

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

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

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

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

قرار المضي قدمًا قبل المخاطر المتبقية

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

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

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

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

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

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

الحدث نفسه كان هادئًا لأن التحضير لم يكن هادئًا

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

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

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

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

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

قوة تفويض DNS حقيقية حتى عندما لا يتم إعادة تفويض أي نطاق

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

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

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

XML مرساة الثقة لـ IANA و موقع نشر مرساة الثقة المرتبط هما أيضًا جزء من تلك القوة. يجعلان مواد مرساة الثقة متاحة للعموم في أشكال قابلة للقراءة آليًا وقابلة للفحص بشريًا. النشر ليس كافيًا لضمان الاعتماد، لكن بدون النشر والتوزيع المستقر، لا يمكن لمشغلي المحللات الاستعداد بشكل موثوق.

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

التباين مع انقطاع منصة خاصة مفيد. مزود خدمة سحابية خاص يمكن أحيانًا التواصل فقط مع العملاء وينشر القليل. ICANN لم يكن لديها هذا الخيار بنفس الطريقة. KSK الجذر هو اعتماد إنترنت عام. قناة المساءلة يجب أن تكون عامة لأن عدد السكان المعتمدين كان عامًا.

مشغلو المحللات كانوا أيضًا مسؤولين

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

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

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

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

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

القياسات خلقت مسؤولية للتفسير، وليس اليقين

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

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

مراجعة التبديل والتحديثات التقنية تظهر هذا العبء التحليلي. صفحة موارد التبديل لـ ICANN جمعت التحديثات التقنية ومواد المراجعة وإرشادات المشغلين في مكان واحد. تحديث 18 ديسمبر 2017 حول مشروع تبديل KSK الجذر وثق حالة التحليل بعد التأجيل. الهدف من هذه المستندات ليس إنتاج ثقة كاملة. إنها لمنع القرار من أن يصبح مدفوعًا بالشائعات.

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

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

ما سيطرت عليه ICANN وما لم تتحكم فيه

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

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

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

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

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

التبديل القادم يجب أن يرث الأدلة، وليس الحظ

صفحة تبديل خوارزمية KSK لجذر المنطقة الحالية لـ ICANN تُظهر أن الصيانة التشفيرية لمنطقة الجذر مستمرة. يختلف تبديل الخوارزمية المستقبلي عن تبديل مفتاح 2018 لأنه يغير الخوارزمية التشفيرية بدلاً من مجرد استبدال مفتاح RSA بمفتاح RSA آخر. هذا العمل المستقبلي يجعل سجل المساءلة لعام 2018 أكثر قيمة، وليس أقل. أنشأ التبديل الأول قالبًا للتخطيط العام، والتواصل، والقياسات، وموافقة مجلس الإدارة، وإرشادات المشغل، والمراجعة بعد الحدث.

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

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

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

الدرس الدائم

سجل تبديل KSK الجذر لـ ICANN من 2016 إلى 2018 هو مثال قوي على المساءلة التشغيلية لأنه يحتوي على الوسط غير المريح: الخطة، إشارة التحذير، التأخير، التعليق العام، الخطة المنقحة، موافقة مجلس الإدارة، التنفيذ، المراقبة، والمراجعة. القصة ليست "غيرت ICANN مفتاحًا ولم يحدث شيء." القصة هي أن ICANN ومجتمع DNS تعاملوا مع تغيير المفتاح كمخاطر تشغيلية عالمية وجعلوا المخاطر مرئية بما يكفي لإدارتها.

نجح التبديل دون تأثير كبير ومستمر على المستخدم النهائي، وفقًا لبيان ICANN العام بعد الحدث. يجب أن يُنسب هذا النجاح إلى الإعداد الموزع بقدر ما يُنسب إلى التنسيق المركزي. ICANN تحكمت في عملية KSK الجذر والقرار. Verisign ومشغلو الجذر الآخرون ساهموا في المراقبة التشغيلية. بائعو المحللات ومشغلوهم جعلوا التحقق يعمل في الميدان. تحمل مالكو الشبكات العامة والخاصة مسؤولية استمراريتهم الخاصة.

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

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