الخلاصة

  • أخفقت تحديثات RIPE Database بصورة متقطعة قرابة ثماني ساعات في 28 أكتوبر، وشملت الطلبات المتصلة بـ DNS العكسي.
  • خلصت RIPE NCC لاحقاً إلى أن الطلبات الفاشلة لم تكن ستغيّر تفويضاً: بعضها لم يحمل تعديلاً، والبقية لم تجتز فحوص Zonemaster.

أظهر سجل الحادث مرحلتين. في 28 أكتوبر، قالت RIPE NCC إن بعض التحديثات لا تُعالَج وإن كائنات نطاق معينة أثرت في خدمة DNS العكسي. وفي 30 أكتوبر أضافت النتيجة التي تحدد الأثر: أظهر التحقيق المفصل أن أياً من الطلبات الفاشلة لم يكن سيؤدي إلى تغيير التفويض العكسي.

وقعت الإخفاقات المتقطعة بين 11:42 و19:40 بالتوقيت العالمي المنسق. نُشر إشعار التحقيق عند 20:04 بتوقيت وسط أوروبا، ثم قالت RIPE NCC عند 20:23 إنها تطبق إصلاحاً وتراقب نتائجه. وأُغلق الحادث عند 20:32. وفي التحديث اللاحق، قسمت RIPE NCC الطلبات إلى نوعين: طلبات لم تتضمن تغييرات، وطلبات أخفقت في فحوص ما قبل التفويض التي يجريها Zonemaster.

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

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

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

لم تنشر RIPE NCC عدد الطلبات الفاشلة أو السبب التقني؛ وهاتان المعلومتان ستحددان حجم الانقطاع وتفسران سببه.

المصادر