الخلاصة

  • نشر RIPE NCC عند 15:03 CEST في 13 أغسطس تقرير ما بعد حادثة NRTM وملفات split.
  • يقول التقرير إن كائناً غير صالح من RPSL أوقف تيار المرآة وجعل العملاء خارج التزامن مع RIPE Database بعده.
  • أعلن RIPE NCC تعديلات في الكتابة ومعالجة التيار والمراقبة، على أن تأتي إصلاحات Whois 1.124 في 27 أغسطس وفق الجدول المنشور.

أين انقطعت سلسلة البيانات

تقول RIPE NCC إن خدمة نسخ NRTM تأثرت تقريباً من 00:06 UTC في 2 أغسطس إلى 12:30 UTC في 4 أغسطس. يحدد التقرير السبب المباشر في كائن RPSL غير صالح أضيف إلى RIPE Database. وعندما وصل NRTM إلى الكائن، توقف عن العمل؛ ومن تلك النقطة فقد العملاء تزامنهم مع قاعدة البيانات.

وتوثق صفحة الحالة أثراً تابعاً محدداً، لا استنتاجاً عاماً: يعتمد توفير DNS العكسي على NRTM، ولذلك لم تكن تحديثات كائنات domain تظهر في DNS العالمي أثناء التحقيق. ثم أفادت RIPE NCC بأن التحديثات المعلّقة عولجت ونشرت. لا تسمي المادة عملاء المرآة أو النطاقات أو جميع المستهلكين، ولذلك لا يصح توسيعها إلى حكم شامل على كل مسار لاحق.

منع الإدخال الخاطئ لا يغني عن تجاوز آمن

يربط التقرير ظهور الكائن غير الصالح بتغيير في Whois 1.122 أُدخل في أبريل. فقد سمحت المنظومة من غير قصد بأسطر جديدة إضافية في سمتَي descr: وremarks:، فكتبت RPSL غير صالح في القاعدة. وتقول RIPE NCC إنها عدلت استبدال نقاط ترميز UTF-8 كي لا يكتب تلك الأسطر الإضافية.

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

افحص جزءاً حديثاً من التيار

أضافت RIPE NCC مراقبة تطلب نطاقاً حديثاً من تحديثات NRTM وتتحقق من الاستجابة. الفرق مهم: إتاحة الاتصال لا تثبت أن البيانات الحديثة ما زالت تتدفق بصورة قابلة للاستخدام.

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

المصادر