سطر زائد عطّل تدفّق مرآة RIPE؛ Ed Shryane يشرح تأخر DNS العكسي 60 ساعة

الخلاصة

• على امتداد يومين و12 ساعة و24 دقيقة، تأخرت تحديثات DNS العكسي التي تمر عبر RIPE NCC. حددت الشركة بداية الخلل عند 00:06 بالتوقيت العالمي في 2 أغسطس ونهايته عند 12:30 في 4 أغسطس 2026؛ وبعد الإصلاح عالجت التحديثات المعلّقة.
• في RIPE 93، شرح Ed Shryane أن فكّ المحارف المهروبة أضاف سطراً إلى كائن RPSL، فاختلّ تركيبه رغم قبوله في قاعدة البيانات. أبقى الإصلاح تلك المحارف كما هي، ثم فحص الفريق أحدث 1,000 كائن وعلامة نهاية التدفق.

تحليل

يحوّل DNS العكسي عنوان IP إلى اسم. أثناء هذا الخلل، تأخر وصول تحديثات هذه الأسماء إلى DNS المنشور؛ فقد بقيت التغييرات في قاعدة RIPE مدة أطول قبل أن تصل إلى المرحلة التالية.

تعتمد هذه المرحلة على NRTM، أي خدمة RIPE NCC لتمرير تغييرات قاعدة البيانات إلى المرايا في وقت قريب من تسجيلها. حددت رسالة الشركة إلى مجموعة عمل قاعدة البيانات فترة التأخير من 00:06 UTC يوم 2 أغسطس إلى 12:30 UTC يوم 4 أغسطس: 60 ساعة و24 دقيقة. وصنّف سجل الحالة الرسمي الحادث بأنه كبير. بعد إصلاح NRTM، عالج الفريق جميع التحديثات التي كانت تنتظر؛ ثم عادت خدمة DNS العكسي إلى التشغيل.

في جلسة Database في RIPE 93، شرح مهندس قاعدة البيانات Ed Shryane سبب توقف التدفق. يحمل كائن RPSL حقولاً مرتبة وفق صياغة محددة. عند فكّ ترميز بعض المحارف المهروبة، أضافت العملية سطرًا جديدًا؛ فتغيّر شكل الكائن وأصبح غير صالح للصياغة، مع أن RIPE NCC كانت قد قبلته.

أوقف الفريق فكّ تلك المحارف وتركها كما وردت. ثم فحص آخر 1,000 كائن في التدفق: هل يستطيع المحلل قراءة كل واحد؟ وهل تنتهي استجابة NRTM بعلامتها المتوقعة؟ القراءة الصحيحة مهمة، لكن على المستهلك أيضاً أن يعرف أن التدفق انتهى بالكامل.

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

المصادر

تفريغ جلسة Database في RIPE 93؛ صفحة جلسة RIPE 93؛ سجل حالة RIPE NCC؛ رسالة RIPE NCC إلى مجموعة عمل Database؛ RFC 2622.