الخلاصة

  • أبلغت Cloudflare عن حدثين مختلفين في 27 يونيو 2024، ولا يجوز دمج إعلان 1.1.1.1/32 مع تسريب 1.1.1.0/24.
  • قالت Cloudflare إن AS267613 بدأ إعلان المسار /32 عند الساعة 18:51 بالتوقيت العالمي المنسق.
  • بعد دقيقة واحدة، عند 18:52، قالت Cloudflare إن AS262504 سرّب المسار /24 عبر AS1031.
  • كان إعلان /32 غير صالح وفق التحقق من منشأ المسار، بينما احتفظ تسريب /24 بالمنشأ الصحيح AS13335 رغم أن مسار انتشاره لم يكن مصرحاً به.
  • أبلغت Cloudflare أن شبكة من الفئة الأولى، لم تسمّها، قبلت إعلان /32 بوصفه مسار RTBH، فتخلّصت من الحركة التي اتبعت ذلك المسار.
  • يمكن لـRPKI رفض منشأ غير صالح أو طول بادئة يتجاوز الحد المسموح، لكنه لا يثبت صحة جميع العلاقات بين الأنظمة المستقلة الواقعة في المسار.
  • سجلات تخصيص العناوين وبيانات ROA أدلة مهمة، لكنها لا تضبط المرشحات داخل أجهزة التوجيه ولا تضمن وحدها استمرار الوصول.
  • تحفظ RouteViews وRIPE RIS مشاهدات عن ظهور المسارات وانتشارها؛ إلا أنهما لا يمنحان المسارات تفويضاً ولا يثبتان كل نتيجة فعلية لتحويل الحزم.
  • كانت الآثار المبلّغ عنها تعذر الوصول إلى 1.1.1.1 أو ارتفاع زمن الاستجابة لدى بعض المستخدمين، وليست دليلاً على انقطاع عالمي لخدمة DNS.
  • تتبع المساءلة الجهة التي امتلكت سيطرة عملية على الإنشاء، وتصدير العميل، وقبول المزوّد، وانتشار العبور أو خادم المسارات، وتفويض الحجب، والمراقبة، والاحتواء، والتحقق من السحب.

حادثة واحدة في الخدمة وحدثان مختلفان في التوجيه

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

تبدأ الدقة هنا برفض وصف الواقعة كحدث توجيه واحد. وفق رواية Cloudflare، أنشأ AS267613 إعلاناً للبادئة 1.1.1.1/32. هذا حدث متعلق بمنشأ بادئة شديدة التحديد. وفي حدث منفصل، سرّب AS262504 البادئة 1.1.1.0/24 عبر AS1031. احتوى المسار الثاني على منشأ Cloudflare الصحيح، AS13335، لكن المشكلة كانت في طريقة تصديره وانتشاره، لا في هوية المنشأ الظاهرة وحدها.

هذا الفرق ليس لغوياً. إنه يحدد أي ضابط كان قادراً على اكتشاف كل حدث. يستطيع التحقق من منشأ المسار اكتشاف إعلان منشأ يناقض ROA أو يتجاوز الطول الأقصى المسموح. لكنه لا يستطيع، بمجرد تأكيد أن AS13335 منشأ صالح للبادئة /24، أن يقرر أن كل علاقة وسيطة أو تصدير لاحق في المسار مسموح به. ولذلك فإن جمع الحدثين تحت عبارة واحدة مثل «اختطاف BGP» يفقد التحليل أهم معلومة تشغيلية فيه.

الصورة المرافقة لهذا المقال رسم تحريري شبكي عام أُنتج بطريقة حتمية لعرض مسارات توجيه منفصلة تتقارب نحو نظام تحكم. ليست الصورة فوتوغرافية، ولا تُظهر منشأة تابعة لـCloudflare، ولا تعيد بناء الواقعة أو طوبولوجيتها الحقيقية.

التسلسل الزمني المقيّد بما أعلنته المصادر

قالت Cloudflare إن AS267613 بدأ إعلان 1.1.1.1/32 في الساعة 18:51 بالتوقيت العالمي المنسق يوم 27 يونيو 2024. وبعد دقيقة، عند 18:52، بدأ AS262504، بحسب Cloudflare، تسريب 1.1.1.0/24 عبر AS1031. التقارب الزمني لا يجعل الحدثين حدثاً تقنياً واحداً، ولا يثبت وجود تنسيق أو غرض مشترك بينهما.

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

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

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

سجلت Cloudflare اكتمال معالجة تسريب /24 عند الساعة 02:28 بالتوقيت العالمي المنسق في 28 يونيو. ولا تمنح هذه النهاية الزمنية دليلاً على وقت سحب كل نسخة من المسار من كل شبكة، أو انتهاء كل أثر مخزّن، أو استعادة كل تدفق محتمل في اللحظة نفسها. إنها نقطة الإغلاق التي أبلغت بها Cloudflare للجزء المحدد من الواقعة.

لماذا كان إعلان 1.1.1.1/32 خطيراً

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

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

مع ذلك، أبلغت Cloudflare أن شبكة غير مسمّاة من الفئة الأولى قبلت /32 باعتباره مسار حجب أسود محفزاً عن بعد، أو RTBH. عند تطبيق الحجب الأسود، تُوجّه الحركة المطابقة إلى مسار إسقاط بدلاً من تمريرها إلى وجهتها. النتيجة المقصودة عادة هي حماية الشبكة أو العميل من تدفق مؤذٍ، ولا سيما في مواجهة هجوم حجب خدمة. أما في هذه الواقعة، فقد أدى قبول الإعلان إلى إسقاط حركة تتجه إلى العنوان العام 1.1.1.1 عبر المسار المتأثر.

لا تسمح المصادر بتسمية تلك الشبكة أو استنتاج بنية مجتمع BGP الذي استخدمته أو طريقة تنفيذها الخاصة أو التسلسل الداخلي لقراراتها. ولا تثبت أن RTBH في حد ذاته ضابط غير آمن. ما تكشفه الواقعة هو أن ضابطاً دفاعياً ذا أثر تدميري يصبح خطراً عندما تكون حدود التفويض غير كافية أو عندما يُقبل طلب الحجب لبادئة لا يملك الجار حق حجبها.

تسريب /24: منشأ صحيح ومسار غير مصرح به

اختلف الحدث الثاني جذرياً. حمل المسار 1.1.1.0/24 منشأ Cloudflare الصحيح، AS13335. لذلك يمكن لنظام التحقق من منشأ RPKI أن يصنف المنشأ على أنه صالح، لأن السؤال الذي يجيب عنه هو: هل تسمح ROA لهذا النظام المستقل بإنشاء هذه البادئة ضمن الطول المحدد؟

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

قالت Cloudflare إن AS262504 سرّب /24 عبر AS1031. هذه الصياغة تحدد مساراً رصدته Cloudflare وتجعله جزءاً من التحليل، لكنها لا تثبت كل علاقة ثنائية تالية ولا كل قرار استيراد أو تصدير وقع عبر الإنترنت. كما لا تثبت أن كل شبكة رأت المسار اختارته أو مررت الحركة عبره.

يصف سياق RFC تسريب المسارات بوصفه انتشاراً يتجاوز النطاق المقصود لسياسة التوجيه. وتقدم ممارسات التصفية، والسياسات الصريحة للاستيراد والتصدير، وأدوار BGP، وإشارة Only-to-Customer طبقات مختلفة لتقييد ذلك الانتشار. غير أن وجود المواصفة لا يثبت نشرها في AS262504 أو AS1031 أو أي شبكة أخرى مرتبطة بالواقعة. البروتوكول يحدد إمكانات الضبط؛ أما الحالة التشغيلية فتتوقف على التهيئة المنفذة.

ما تثبته سجلات العناوين وROA وما لا تثبته

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

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

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

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

RTBH بين الدفاع والتفويض التدميري

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

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

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

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

دليل التأثير وحدود الاستنتاج

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

لكن البيانات المتاحة لا تمنح خريطة كاملة للانتشار. لا نعرف من الحزمة المجمّدة كل شبكة قبلت /32، ولا كل شبكة استقبلت /24، ولا أي نقطة مراقبة رأت أي نسخة وفي أي ثانية. كما لا نعرف كل قرار تحويل فعلي على مستوى البيانات، لأن مسار BGP المرصود لا يساوي دائماً المسار الذي اتبعته كل حزمة.

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

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

المراقبة ليست تفويضاً

توفر RouteViews وRIPE RIS سجلات مشاهدة قيّمة لمسارات BGP. تستطيع هذه الأنظمة إظهار أن إعلاناً ظهر عند جامع أو نظير معين، وتسمح للباحثين بمقارنة الزمن والمسار والمنشأ والبادئة. وهي ذات قيمة كبيرة في التحقيقات اللاحقة وفي بناء تنبيهات للمسارات الأكثر تحديداً أو التغيرات غير المتوقعة.

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

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

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

الوقاية: ضوابط مختلفة لحدود فشل مختلفة

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

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

تضيف أدوار BGP وإشارة Only-to-Customer وسيلة لنقل توقعات العلاقة وتقليل احتمالات تصدير مسار في اتجاه غير مناسب. غير أن فائدتها مشروطة بالنشر الصحيح والمتبادل. ولا يجوز تحويل ذكرها في RFC إلى ادعاء بأنها كانت مفعلة لدى أي شبكة في الواقعة.

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

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

الكشف: من تغير المسار إلى تغير الخدمة

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

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

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

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

الاحتواء: إيقاف الانتشار من دون توسيع الضرر

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

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

ينبغي تجنب «حل» حدث /32 بإجراءات واسعة تؤثر في /24 كله إذا كان من الممكن استهداف المسار الدقيق. وبالمثل، لا ينبغي حذف كل طريق يمر عبر AS معين من دون فهم النطاق، لأن ذلك قد يخلق فقد وصول جديداً. الاحتواء الجيد يزيل الحالة غير السليمة بأضيق نطاق يمكن التحقق منه.

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

التعافي: السحب ليس نهاية التحقيق

أفادت Cloudflare بأن تسريب /24 حُل بالكامل عند 02:28 في 28 يونيو. ومع ذلك، يتطلب التعافي التشغيلي أكثر من تلقي سحب BGP. يجب التحقق من أن المسار غير السليم لم يعد ظاهراً عند نقاط رصد مستقلة، وأن الطريق المتوقع عاد، وأن زمن الاستجابة ومعدلات نجاح DNS رجعا إلى المستوى الطبيعي في المناطق المتأثرة.

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

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

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

خريطة المساءلة بحسب السيطرة العملية

الجهة أو الحد التشغيلي السيطرة العملية سؤال المساءلة
AS267613 إنشاء إعلان /32 وفق رواية Cloudflare ما التفويض الذي سمح بإعلان عنوان لا يملكه النظام المستقل، وما القيود التي كان ينبغي أن تمنعه؟
AS262504 تصدير /24 وفق رواية Cloudflare لماذا خرج المسار في علاقة لم يكن ينبغي أن ينتشر عبرها، وما سياسة التصدير المطبقة؟
AS1031 مسار انتشار سمّته Cloudflare ما قواعد قبول مسارات العميل وإعادة تصديرها، وهل كانت علاقة الجلسة وحدودها موثقة؟
مزودو العبور أو خوادم المسارات قبول المسار وتمريره إلى جيران آخرين هل فُحصت البادئة والمنشأ والدور والعلاقة قبل إعادة النشر؟
الشبكة غير المسماة من الفئة الأولى قبول /32 بوصفه RTBH هل كان المرسل مخولاً بحجب البادئة، وهل ضُبط الطول والنطاق والتسجيل والسحب؟
حامل البادئة ومشغل ROA الحفاظ على سجلات المورد والمنشأ والطول هل كانت البيانات دقيقة ومتاحة ومهيأة لتقديم إشارة قابلة للتطبيق؟
مشغلو الشبكات المستقبلة تطبيق RPKI وسياسات الاستيراد هل تحولت الإشارة إلى قرار رفض فعلي في الموجّه؟
RouteViews وRIPE RIS حفظ مشاهدات التحكم ما الذي ظهر عند نقاط الرصد، وما حدود التغطية التي يجب إعلانها؟
Cloudflare مراقبة الخدمة والتوجيه والتواصل والاستجابة متى اكتشفت الأثر، وكيف ربطته بالمسارات، وكيف تحققت من الاحتواء والتعافي؟

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