انقطاع Cloudflare 1.1.1.1 في 2025: اختبار لمسؤولية سحب المسارات في DNS

ملخص

• تؤكد Cloudflare أن خدمة DNS العودية العامة 1.1.1.1 كانت غير متاحة عالميًا من الساعة 21:52 حتى 22:54 بتوقيت UTC في 14 يوليو 2025. تأثر معظم المستخدمين، وواجهت خدمة Gateway DNS تدهورًا متقطعًا. الآلية المباشرة كانت سحب بادئات الإنتاج الخاصة بالخدمة بعد تعديل طوبولوجيا داخلي، لا هجومًا أو عيبًا في بروتوكول DNS. [1]
• بدأ الخطأ الخامل في 6 يونيو. إعدادٌ لخدمةData Localization Suiteغير مفعَّلة أدرج بالخطأ مرجع خدمة Resolver 1.1.1.1 وبادئاتها. ظل الخطأ خامدًا لأنه لم يولّد تغييرًا مرئيًا في الحركة المرورية. وفي 14 يوليو، أدّى إضافة موقع اختبار إلى تلك الخدمة غير المنتجة إلى تحديث عالمي، خفّض طوبولوجيا Resolver من مواقع الإنتاج العالمية إلى موقع واحد غير متصل، مما أدى إلى سحب المسارات. [1][8]
• نشرت Cloudflare بادئات IPv4 وIPv6 المتأثرة بما فيها 1.1.1.0/24 و1.0.0.0/24 و2606:4700:4700::/48 ومساحات العناوين المرتبطة بالمحوّل. انخفضت حركة UDP وTCP وDNS over TLS بشكل حاد. بقي DNS over HTTPS أكثر استقرارًا نسبيًا لدى كثير من المستخدمين لأن cloudflare-dns.com اعتمد مجموعة عناوين مختلفة. تحدد حدود الانقطاع اختيار نقطة النهاية والمسار، وليس اسم المنتج فقط. [1][16][17]
• بدأت التنبيهات وأُعلن الحادث في 22:01. عكست Cloudflare الإعداد في 22:20. أعاد إعادة الإعلان للمسارات استرجاع الحركة إلى نحو 77 في المئة من المستويات السابقة، لكن نحو 23 في المئة من خوادم الحافة كانت أزالت منها روابط IP مطلوبة مسبقًا. استغرقت استعادة الحركة الكاملة حتى استرجاع تلك الروابط 22:54. [1]
• أصبح الإعلان عن 1.1.1.0/24 من قبل Tata Communications India مرئيًا بعد سحب مسارات Cloudflare. وصفت Cloudflare الملاحظة بأنها تبدو كخطف من منظور نظام التوجيه، لكنها صرحت صراحة أن ذلك لم يكن سبب انقطاع الخدمة. تثبت صلاحية المصدر ومراقبة المسارات أنها ذات قيمة، لكنها لا تُثبت أن المشغّل المفوض يعلن بادئة خدمة من المواقع المطلوبة أو يجيب استعلامات DNS. [1][3][18][19]
• Anycast يوزع عنوان خدمة واحدًا عبر مواقع متعددة. يوضح RFC 4786 قيمة DNS resilience ويحذر أن المراقبة تصبح أكثر تعقيدًا لأن التوافر يعتمد على موقع العميل والتوجيه. [9][12][13]
• تتبّع المساءلة يرتبط بالسيطرة العملية على سجل البادئة-إلى-الخدمة، والطوبولوجيا المفعّلة، والتحديث العالمي، وإعلانات المسارات، وروابط الحافة، وتصميم التنبيه، وسلطة التراجع، وإثبات استعادة الخدمة. التذكرة أو التكوين المقصود دليل نية، بينما التشغيل الفعلي للمسارات وإجابة DNS النهائية دليل الواقع.
• وفقًا لعقيدة Heng.lu، يجب أن تحافظ سجلات الخدمة والبادئات والطوبولوجيا على التفرد والدقة وبيانات الأمان الوصفية والاستمرارية التشغيلية. تظل هذه السجلات أدلة تشغيلية، لا بدائل سيادية لشبكة التشغيل. ينهار «الطرح التحت بنيوي للشبكة» إذا أزيلت حقائق DNS، وبادئات IP، وAnycast، وBGP، وروابط الحافة؛ لذلك تبقى هذه الطبقة جوهرية وليست زخرفية.

يمكن أن يفشل المفسِّر قبل أن يعالج سؤال DNS

عندما يصف المستخدمون انقطاع DNS، تتشكل صورة ذهنية أن المفسّر يستقبل الاسم ثم يفشل في إرجاع العنوان. هذا احتمال ممكن للانقطاع. لكنه لم يكن أول انقطاع في حادثة Cloudflare في يوليو 2025.

لا يستطيع العميل توجيه سؤال للمفسّر إلا بعد وصول الحزم إلى عناوين خدمة المفسر. بالنسبة إلى 1.1.1.1، تُسَلَّم تلك العناوين الشائعة عبر شبكة anycast. تعلن Cloudflare مواقع متعددة نفس البادئات كقابلة للوصول، ويختار التوجيه في الإنترنت مسارًا إلى إحداها. بعد ذلك، ينفّذ برنامج Resolver عمله العودي باستخدام الذاكرة المؤقتة أو الاتصال بخوادم أسماء السلطة عند الحاجة. [5][6][12]

الحادثة في يوليو عطّلت الخطوة السابقة. توقفت مواقع الإنتاج في Cloudflare عن إعلان البادئات المعنية. لم تعد الحزم المرسلة إلى تلك العناوين قادرة على الوصول إلى مواقع الحافة المفترضة للإجابة. لم يصبح المفسّر أولًا "خاطئًا" بشأن اسم نطاق معيّن؛ أصبح تعريف الشبكة حول مكان وجود خدمة Resolver هو الخاطئ. [1]

هذا التمييز مهم للمساءلة لأنه يحدد الأنظمة المسيطرة.

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

النجاح التشغيلي لا يتحقق إلا باتفاق هذه الطبقات:

1. يرتبط هوية الخدمة بالبـادئات الصحيحة.
2. ترتبط مواقع الإنتاج المقصودة بالخدمة.
3. تعلن منظومة توليد المسارات تلك البادئات من المواقع المقصودة.
4. تحتفظ أنظمة الحافة بروابط IP اللازمة لاستقبال المرور.
5. تقبل عملية Resolver النقليات ذات الصلة وتُنجز الاستعلامات.
6. تكتشف المراقبة الخلل بسرعة كافية للاسترجاع المسيطر.

تُظهر تقرير الحادث أن الخلاف بدأ في أول طبقتين وانتقل إلى الطبقتين التاليتين. فقد اكتسب كائن قبل الإنتاج مرجعًا لبـادئات Resolver إنتاجية، ثم قام تحديث لاحق بإدراج هذا الارتباط في سحب المسارات. أزالت بعد ذلك بعض خوادم الحافة روابط مطلوبة سلفًا. [1]

وصف النتيجة بأنها "DNS معطّل" مفهوم، لكنه مبسّط جدًا للتحليل الرقابي. ففئة الفشل كانت في هوية ووصول الشبكة التحتية: أي خدمة تمتلك عنوانًا، وأين يجب أن تكون قابلة للوصول، وما حالة المسار الناتجة من السجل، وأي نقطة نهاية مادية أو برمجية مستعدة لاستقبال المرور.

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

كان الخطأ الخامل بالفعل مخاطرة تشغيلية

تؤرخ Cloudflare إدخال خطأ الإعداد إلى 6 يونيو 2025. كانت الشركة تُهيئ طوبولوجيا خدمة مستقبلية لخدمةData Localization Suite. الخدمة الجديدة لم تكن في الإنتاج. أدرج هذا الإعداد بالخطأ مرجعًا إلى خدمة Resolver 1.1.1.1 وبالامتداد البادئات التابعة لها. [1]

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

هذا الهدوء لا يعني أن السجل غير مؤذٍ؛ يعني أن النظام لم يفعّله بعد.

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

السؤال المهم هنا ليس فقط: "هل غيّر تغيير يونيو الحركة؟" بل: "ما مقدار السلطة التي حصل عليها سجل يونيو؟"

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

يمكن لجهة تحكم دقيقة أن تجيب:

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

هذه ليست عناصر شكلية. كل سؤال يمكن أن يتحول إلى تحقق حتمي.

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

هدف التحكم ليس حظر التكوينات الخاملة. الهدف منع سلطة التكوين الخامل من تجاوز المراجعة.

تشرح وثائق Cloudflare الحالية حول Data Localization حاجة شرعية للتحكم في مواقع معالجة المرور. تصف منتجات جغرافية ومتوافقة مع الامتثال، لكنها لا تثبت النموذج الخاص بالبيانات الخاصة أو الضبط المُستخدم في يونيو ويوليو 2025. [8] يبقى تقرير الحادثة هو مصدر آلية الحادثة، والوثائق الحالية توفر سياقًا لأهمية إدخال موقع الخدمة كمدخل ضبط مهم.

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

حوّل التحديث العالمي السجل إلى حالة تشغيلية

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

تظهر هذه السلسلة أن مدى الضرر الناتج عن تغيير يجب قياسه عبر المخرجات المترجمة، لا عبر حجم إدخال مفترض.

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

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

وكان المعاين الآمن لهذا النوع من التغييرات يجب أن يبيّن على الأقل:

• كل خدمة يتغير نطاق طوبولوجيتها الفعلي.
• كل بادئة مضافة أو معلنة أو معاد ربطها.
• كل موقع سيبدأ أو يتوقف عن إعلان كل بادئة.
• كل ارتباط حافة سيضاف أو يُزال.
• كل نقطة نهاية بروتوكول متأثرة.
• أقل عدد متبقٍ من المواقع الحية.
• الفرق المتوقع في إعلانات BGP.
• فرق توزيع استعلامات DNS المتوقع.

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

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

وهكذا تتحدى الحادثة مصطلحًا شائعًا: التغيير غير الإنتاجي.

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

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

يمكن أن يبقى الدليل لهذا التصنيف محدودًا: تذكرة تغيير تحدد المُركب المتأثر، ومعاينة آلية تحدد الموارد الإنتاجية المتأثرة، ونتيجة سياسة تُسجّل فحوص invariants، وتقرير canary يظهر ملاحظات المسار والخدمة. الملف المحتفَظ به أجدى من وعد عام بأن الإنتاج والإختبار منفصلان.

Anycast وزّعت الخدمة وتركّز فيه خطأ التحكم

يُوصف Anycast غالبًا كآلية للمرونة. نفس عنوان الخدمة متاح من مواقع شبكة متعددة، والتوجيه يوجّه المستخدمين نحو أحدها. يصف RFC 4786 هذا النموذج ويحذر أن المراقبة تصبح أكثر تعقيدًا لأن التوافر يعتمد على موقع العميل والتوجيه. [12]

تستخدم Cloudflare Anycast على نطاق واسع، بما في ذلك 1.1.1.1. تشرح وثائقها العامة ومواد شبكتها الحالية خدمة موزعة عالميًا ومجال عناوين معلنًا عبر شبكتها. [4][5][9][10][11]

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

هذا التمييز يفصل بين احتياطيية طبقة البيانات وحرية طبقة التحكم.

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

الأسئلة الملائمة لمتانة المسار هي:

• هل يمكن لارتباط واحد بين الخدمة والبادئة إزالة جميع عقد anycast دفعة واحدة؟
• هل توجد قاعدة حضور دنيا ثابتة أو خاضعة لسيطرة منفصلة للبـادئات الحرجة؟
• هل يتطلب التغير العالمي تحققًا ناجحًا من ملاحظات مستقلة متعددة؟
• هل يمكن لمجموعة فرعية الحفاظ على إعلان آخر نسخة سليمة أثناء عدم يقين طبقة التحكم؟
• هل يمكن استعادة الطوارئ دون الاعتماد على نفس جامع الطوبولوجيا؟
• هل روابط الحافة محمية من الإزالة التلقائية حتى تتوافق فحوص المسار والخدمة؟

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

لذلك يجب أن تشمل الأدلة كلًا من حالة المسار وحالة الخدمة.

إعلان المسار يثبت أن الإنترنت قد يوجه الحزم نحو المشغل؛ لا يثبت أن التطبيق المقصود صحيّ. فحص Resolver يثبت أن عملية واحدة تجيب من منظور نقطة واحدة؛ لا يثبت أن المستخدمين في مجمعات التوجيه الأخرى يستطيعون الوصول إليها. سجل الطوبولوجيا يثبت المقصود من نظام التشغيل؛ لا يثبت ما طُبّق على الموجهات وحواف المضيف.

يحتاج Resolver العالمي لشرط قبول مشترك، مثل:

1. احتفاظ الخدمة المقصودة بعدد معرف من مواقع الإنتاج السليمة.
2. بقاء البادئات المطلوبة مرئية من مراقبي المسارات المستقلين وشبكات عملاء مختارة.
3. وجود روابط الحافة حيث تنتهي المسارات.
4. اكتمال بروابات UDP وTCP وDoT وDoH من مناطق ممثلة.
5. بقاء توزيع حجم الاستعلامات وشفرات الرد ضمن حدود مرعية.

توفر Cloudflare Radar ملاحظات DNS وتوجيه عامة، لكنها تظل سطح قياس تشغّل تديره Cloudflare ولا تمثّل كل مسارات المستخدم. [2][3] ملاحظات خارجية مستقلة وقياسات ISP وتجارب العملاء ستقوي السجل. الهدف ليس إعطاء شهادة على الخدمة من مخطط واحد، بل ملاحقة التكوين العالمي خارج نظام التكوين الذي أنتجه.

مسارات البروتوكول كشفت النطاق الحقيقي للضرر

أفادت Cloudflare عن هبوط مباشر وحاد في استعلامات Resolver عبر UDP وTCP وDNS over TLS عندما سُحبت البادئات. كثير من المستخدمين يضبطون 1.1.1.1 و1.0.0.1 أو بدائل IPv6 مباشرة. فقدت الحزم في تلك العناوين المسار نحو خدمة Cloudflare الإنتاجية. [1]

بقي DNS over HTTPS نسبيًا أكثر استقرارًا لدى كثير من المستخدمين لأنهم استخدموا cloudflare-dns.com، الذي اعتمد على مجموعة عناوين مختلفة. كما بقي جزء من المرور عبر UDP باستخدام عناوين أخرى نسبيًا مستقرًا أيضًا. [1]

هذا الفرق يحتوي دروس مساءلة عدة:

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

ثانيًا، التنويع مفيد فقط إذا كان حقيقيًا وقابلاً للاستخدام. لم يظل DoH متاحًا لأن مصطلح «HTTPS» أكثر مرونة من UDP بطبيعته؛ بقي أكثر استقرارًا في هذه الحادثة لأن كثيرًا من العملاء وصلوا إلى اسم مضيف مرتبط بعناوين أخرى. حدث مستقبلي قد يؤثر على هذه العناوين أو مسار حل اسم المضيف بشكل مختلف.

ثالثًا، يجب على تقارير الأثر تسمية المسار. قول «1.1.1.1 كانت معطلة» يعكس التجربة العامة للعملاء لكنه يخفّي لماذا استمرّت بعض الطلبات. و«كل DNS كانت معطلة» سيكون وصفًا غير دقيق. تمييز التقرير بين النقل والبروتوكول في postmortem يجعل السرد أكثر فائدة. [1][16][17]

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

إذًا، سؤال مساءلة جهة العميل ليس «لماذا لم ينتقل الجميع؟» بل «هل فهم العملاء الحرجين اعتمادهم على Resolver، وتوفر لديهم مسار بديل متوافق، وهل اختُبِر هذا المسار دون مخالفات أمان أو سياسات؟»

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

ينبغي أن تحافظ الأدلة على:

• معدلات الاستعلامات حسب نقطة النهاية والنقل.
• قابلية الوصول من شبكات ممثلة.
• معدلات نجاح Resolver، ومؤشرات المهلة، وأخطاء الاستجابة.
• سلوك إعادة المحاولة لدى العميل.
• تفعيل Resolver احتياطي أو بديل.
• سمات الأمان والخصوصية للممر الاحتياطي.
• توقيت الاستعادة بحسب المسار.

تُجعل هذه السجلات حدود الأثر قابلة للاختبار، كما تمنع استخدام مسار ناجٍ لتقليل تقدير فشل آخر.

الإعلان غير المتعلق كان دليلًا لا سببًا

في 21:54، بعد بدء اختفاء إعلانات Cloudflare، أعلن Tata Communications India نطاق 1.1.1.0/24 ضمن AS4755. وصفت Cloudflare أن نظام التوجيه جعل الحدث يبدو كاختطاف بادئة من منظور الرصد، لكنها أكدت أيضًا أن هذا الإعلان لم يكن سبب الانقطاع. [1]

يجب الحفاظ على هذا التمييز.

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

دمج الحدثين كان سيُنتج مقالة أكثر درامية لكنه أضعف، وسيوجه الإصلاح نحو جهة سيطرة خاطئة.

يتحقق RPKI كما في RFC 6811، حيث يتيح الموجه تصنيف ما إذا كان AS أصلًا مصرحًا له بالبادئة وفق بيانات تفويض أصل المسار. وتُعالج إرشادات تشغيل BGP التصفية والنظافة التشغيلية. [18][19] هذه الضوابط تقلل جزءًا من مخاطر الأصل غير المصرّح.

لكنها لا تثبت التوافر.

يمكن لCloudflare مصرحًا أن يسحب مساره. ومسار صحيح يمكن أن ينتهي على حافة بلا Resolver عامل. وأصل صحيح قد يعلن من مواقع قليلة جدًا. وحافة قد تحتفظ برابط IP بينما الخدمة غير سليمة. وبالمقابل، مسار يبدو شاذًا قد يكون غير مرتبط ببدء الفشل الأولي.

تجسد الحادثة إذن دورًا محدودًا لسجلات الأمان.

سجلات أصل المسار تجيب سؤالًا محددًا: هل هذا الأصل مصرح له بهذه البادئة؟ لكنها لا تجيب: هل يجب إعلان البادئة الآن؟ كم موقعًا إنتاجيًا يجب أن يكون حاضرًا؟ هل يقود المسار للخدمة المقصودة؟ هل موجود رابط الحافة؟ هل يجيب Resolver بشكل صحيح؟ هل حذف تغيير طوبولوجيا المسار المصرح به للمرخّص نفسه؟

هذا يتسق مع معالجة عقيدة Heng.lu للسجلات والدفاتر. السجل قد يجعل الهوية والتفويض وسجل التغييرات قابلة للتدقيق. لكنه لا يفرض على الطبقة البينية تنفيذًا. المسار والخدمة لا يزالان بحاجة إلى التشغيل الفعلي.

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

بدأ الاكتشاف بعد خسارة المسار

تقول Cloudflare إن حركة DNS بدأت بالتراجع في 21:52. وبدأت تنبيهات Resolver الداخلية في 22:01 عندما أُعلن الحادث. [1]

الفاصل البالغ 9 دقائق قد يكون قصيرًا في بعض السياقات التشغيلية، لكنه طويل نسبيًا لمُعرّف عالمي. النقطة الأهم هي ما ولّد الإشارة.

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

مراقبة النتائج ضرورية، لكن تحتاج طائرة تحكم التحكم أيضًا إشارات قبل النشر ومرتبطة بارتباط التغيّر.

يمكن فصل ثلاث طبقات للكشف:

كشف سلامة الحالة

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

كشف أثر التغيير

ترصد هذه الطبقة فرق المسار المترجم والمُنشر. ويمكنها مقارنة إعلانات BGP والروابط الحافة ومجموعات المواقع خلال نافذة Canary.

كشف أثر الخدمة

تقيس هذه الطبقة ما يراه المستخدمون: قابلية الوصول، اكتمال استعلام DNS، زمن الاستجابة، المهلات، وأخطاء البروتوكول.

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

لا ينبغي الثقة في أي طبقة وحدها.

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

لـResolver العالمي، قد يشمل بوابة تغيّر مفيدة:

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

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

إعادة الإعلان أعادت جزءًا فقط من الخدمة

عكست Cloudflare الإعداد المسبب في 22:20. تقول الشركة إن هذا أعاد تقريبًا فورًا الإعلانات المنسحب عنها وأعاد مرور Resolver إلى نحو 77 في المئة من مستواه السابق، لكنه لم يعيد كل شيء. إذ كانت نسبة تقريبا 23 في المئة من أسطول الحافة قد أُعيد تكوينها تلقائيًا لإزالة روابط IP المطلوبة. [1]

بقيت بقية العمل لها بروفايل تشغيل مختلف.

كانت عملية استرجاع الربط العادي تستخدم تحديثًا تدريجيًا على مدى ساعات. صُمّم هذا الإيقاع لتقليل احتمال إدخال مشكلة ثانية خلال التغيير نفسه. خلال الحادثة، اختبر Cloudflare إجراءً يدويًا متسارعًا في مواقع محدودة ثم وسّعه أوسع. عادت الحركة إلى مستويات شبه طبيعية في 22:54. [1]

تكشف هذه السلسلة نموذج استرجاع مفيد لأنه يبرز ثلاث حالات منفصلة:

1. تم عكس سجل الطوبولوجيا الخدمي.
2. أُعيد الإعلان عن بادئات BGP.
3. استعادت خوادم الحافة روابط IP المطلوبة لاستقبال الخدمة وإيصالها.

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

ينبغي إذن أن تكون أدلة الاسترجاع طبقية:

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

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

توتر التوازن بين النشر التدريجي الآمن والاسترجاع العاجل يجب أن يكون له حوكمة واضحة.

التحديث التدريجي يخفض مدى التأثير خلال تغيير عادي. وفي انقطاع بسبب فقدان الروابط، قد يطيل التدريجي من مدة عدم التوافر. والتسريع في الاسترجاع يعيد الخدمة أسرع لكن قد يزيد خطر تغيير عالمي غير مختبر. توضح Cloudflare أنها تحققت من الإجراء اليدوي في مواقع تجريبية قبل التسريع. [1]

يجب أن تحدد عملية الطوارئ المسؤولة:

• من يملك حق تجاوز سرعة النشر العادية.
• أي اختبارات يجب أن تبقى إلزامية.
• أي مواقع تمثل Canary الأولي للاسترجاع.
• أي مقاييس توقف التسارع.
• كيف تؤكد الملاحظات المستقلة التحسن.
• كيف يتم تثبيت التغييرات المتزامنة.
• كيف يعود النظام إلى ضوابط النشر العادية.

مسار الطوارئ يجب أن يكون مُمَرَّنًا قبل وقوع الطوارئ، وإلا تكتشف الصلاحيات والأدوات والاعتماديات بينما المستخدمون بالفعل غير متصلين.

المساءلة يجب أن تتبع سلسلة التحكم الكاملة

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

كانت السيطرة العملية موجودة على عدة طبقات:

ملكية الخدمة

حدد شخص 1.1.1.1 من حيث الحرجية والبـادئات ونقاط النهاية ومتطلبات الموقع. هذا المالك يجب أن يعرّف invariants وشروط الاسترجاع المقبولة.

ملكية المورد الرقمي والشبكة

سيطر شخص آخر على البادئات الإنتاجية وإعلانات BGP والعلاقات peering ونظم التوجيه. هذا المالك يجب أن يحافظ على سجلات هوية وحالة مسار دقيقة ومراقبة مستقلة.

ملكية نظام الطوبولوجيا

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

ملكية منصة الحافة

تحكم شخص آخر في كيفية ربط وعزل عناوين الخدمة على خوادم الحافة. هذا المالك يحدد متى يمكن للمسار والربط على الحافة التغيّر وكيف تثبت التسوية بينهما.

ملكية Resolver

شغّل شخص آخر برامج DNS العودية والنقليات وفحوص الصحة وأهداف الخدمة. هذا المالك يقيس إجابات الاستعلام النهائية بدل استنتاجها من وجود المسار.

قيادة الحادث

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

ملكية العملاء والتبعية لدى الشبكات

تُدار المؤسسات التي عرّفت العملاء أو شبكات المشتركين على الاعتماد المباشر على 1.1.1.1 تصميمات احتياطي وفحوص خصوصية وسياسة أمان بديلة. مسؤوليتهم لا تلغي مسؤولية المشغل عن فشل الخدمة المتسبب.

يمكن تقاسم المسؤولية دون أن تصبح غير واضحة: يجب أن يكون لكل مالك واجب اختباري قابل للثبوت ودليل محتفظ به.

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

هذا النهج يتجنب حدّيّتين ضعيفتين.

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

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

طبقة الواقع في عقيدة Heng.lu: هوية الخدمة في التشغيل

تعامل عقيدة Heng.lu السجلات كسجلات وحراس حقائق بدلًا من مُنشئات سياديين للتنفيذ الفعلي. وتعطي الأولوية للكود التشغيلي وتعتبر موارد الأرقام ككيانات تحتاج تفردًا ودقة وبيانات أمان واستمرارية.

الحادثة في يوليو تقدم مثالًا مباشرًا في الشبكة.

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

إلا أن السجل نفسه لم يجعل Resolver متاحًا أو غير متاح.

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

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

لفرود إنتاجي ببادئة خدمة، يجب أن تحتفظ السجلات:

• البادئة وعائلة العنوان.
• مالك الخدمة الرسمي.
• المواقع الإنتاجية المقصودة.
• بيانات المسار والتفويض.
• متطلبات روابط الحافة.
• نقاط نهاية البروتوكول.
• تاريخ التغييرات.
• الحد الأدنى للوجود والحساسية والتعافي.
• التبعية ومالك الاسترجاع.
• آخر تحقق مرصود للمسار والخدمة.

يجب أن تكشف السجلات تعارض المطالبات. ولا يحق لها إعلان النجاح لمجرد امتلاء الحقول.

يجب أن تشمل إثباتات التشغيل:

• المخرجات المترجمة للمسار.
• حالة إعلانات الراوتر.
• رؤية مراقب مستقل.
• حالة الواجهة أو الارتباط على الحافة.
• صحة Resolver.
• إكمال استعلامات DNS من مسارات ممثلة.
• نتائج تمارين الاسترجاع.

السجل كوثيقة لا يعني توثيقًا سلبيًا. فهو قد يقود التحقق والتفويض والتدقيق ويمنع تملكًا مزدوجًا أو نقصًا في الميتاداتا. لكنه لا يبدّل تصريحًا بإيصال الحزم.

المبدأ يقيد أيضًا لغة المقال.

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

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

ينبغي وجود شرط يمنع خدمة عالمية من الوصول إلى صفر مواقع حيّة

تقول Cloudflare إن طوبولوجيا Resolver كانت خُفضت من جميع المواقع إلى موقع واحد غير متصل. [1] وهذه النتيجة توحي بهدف سيطرة مباشر: لا ينبغي نشر خدمة شبكة عالمية ببـادئات إنتاجية عند عدم وجود أي مواقع إنتاجية حية، إلا عبر مسار إيقاف طارئ مُصرّح به صراحة.

ينبغي تصميم هذا القيد بدقة.

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

يمكن تعزيز القيد بأبعاد متعددة:

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

ينبغي تطبيق القيد على المرشح المترجم وعلى الحالة الحالية المرصودة.

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

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

يمكن أن يتضمن تقرير شرط قابلية التنفيذ:

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

مطالبات التصحيح تحتاج أدلة تشغيلية دائمة

تذكر Cloudflare أن postmortem يتضمن تدابير لمنع التكرار: إزالة النطاق العالمي القديم لنظام التكوين، إضافة حماية ضد سحب مسارات 1.1.1.1 العالمي، تحسين التحقق والتنبيه، ومراجعة الأنظمة القديمة. [1]

تلك الإجراءات تستهدف طبقة الفشل الصحيحة.

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

السجل العام لا يثبت اكتمال كل بند أو فعاليته المستمرة.

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

• الالتزام المقترح.
• التحكم المطبّق.
• التحكم المختبر.
• التحكم المُمَرَّن.
• تشغيل التحكم مع استثناءات موثقة.

لهذا النوع من الفشل، يمكن أن تكون الأدلة المستمرة:

اختبارات تعارض ملكية البادئات

اختبار يحاول ربط بادئة Resolver إنتاجية بخدمة غير إنتاجية غير مرتبطة. يرفض النظام ذلك ويسجل تعارض المالك.

اختبارات الموقع الحي الصفري

مرشح طوبولوجيا محتمل يترك Resolver بلا مواقع إنتاجية حيّة. الcompiler يرفضه قبل توليد المسار.

مراجعة دلتا مترجمة

إضافة موقع اختبار تنتج قائمة قابلة للقراءة الآلية لكل بادئة وموقع إنتاجي متأثر. يرى المراجع النطاق العالمي حتى لو كان الإدخال يبدو محليًا.

Canary لسحب المسار

تمرين مضبوط يتحقق من أن سحبًا غير متوقع في عروض BGP عامة مختارة يوقف التقدم ويحفظ وصول الاسترجاع.

توفيق روابط الحافة

يقارن النظام الروابط المقصودة، وحالة المضيف، وحالة المسار قبل التغيير وبعده. يكشف حالة 77 في المئة إعلانًا فقط و26 في المئة روابط غير مكتملة.

فحوص مسارات البروتوكول

تمارين UDP وTCP وDoT وDoH تستخدم نفس اختيارات نقاط النهاية لدى العملاء الحقيقيين. يسجل التمرين أي المسارات البديلة مستقلة حقًا.

تمرين التسريع الطارئ

يسترجع المشغل الروابط عبر مسار الطوارئ، ويثبت نجاح Canary، ويقفل تغييرات متزامنة ويعود إلى سير العمل التدريجي الطبيعي.

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

حزمة الأدلة العملية

المجالس، العملاء، الجهات التنظيمية، والمراجعين التقنيين لا يحتاجون كل أوامر الإعداد الخاصة. يحتاجون أدلة مرتبطة بالآلية.

كل عنصر يميز بين السجل والنتيجة.

سجل البادئات ضروري لكنه غير كافٍ. الرسم الطوبولوجي ضروري لكنه غير كافٍ. رؤية BGP ضرورية لكنها غير كافية. والإجابة عبر DNS ضرورية لكنها لا تكفي لكل مسار مستخدم.

تكتسب سلسلة الأدلة مصداقيتها عندما تتوافق الحالات:

1. السجل الموافق له مالك مسؤول واحد.
2. المخرج المترجم يحفظ القاعدة الحاسمة.
3. المسارات المعلن عنها تطابق المخرج المترجم.
4. روابط الحافة تطابق إنهاء المسار.
5. عمليات Resolver تجيب عبر النواقل المتوقعة.
6. المستخدمون المُمَثّلون يصلون الخدمة.
7. يغلق الاسترجاع كل طبقة متأثرة.

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

أسئلة على المشغلين والجهات المستفيدة والمراجعين

ينبغي أن يسأل مشغّلو الشبكة والمنصات:

• أي نظام هو المرجع الرسمي لملكية خدمة-بادئة؟
• هل يمكن أن تشير خدمة غير إنتاجية إلى بادئة إنتاجية أو تضيقها؟
• هل تظهر المراجعة الدلتا العالمية للمسارات والروابط؟
• ما القاعدة التي تمنع الوصول إلى صفر مواقع إنتاجية سليمة؟
• من يملك المراقب المستقل القادر على إيقاف النشر؟
• هل تتسق بيانات المسار وروابط الحافة وصحة Resolver؟
• هل يمكن الاسترجاع دون الاعتماد على نظام الطوبولوجيا الفاشل؟
• من يملك قفل تغيير الحالة أثناء الحادث؟
• كيف يُسرّع مسار الطوارئ ثم يعود للضبط الطبيعي؟
• متى تمّ تمرين هذه الفئة من فشل آخر مرة؟

وينبغي أن تسأل العملاء ومشغلو شبكات التمرير:

• أي خدمات حرجة تستخدم 1.1.1.1 بشكل مباشر؟
• أيهم يستخدم cloudflare-dns.com أو مسارًا بديلًا؟
• هل تم تصميم بديل Resolver وتوافقه واختباره؟
• هل يستمر الإجراء الاحتياطي مع المحافظة على الخصوصية والتصفية وأمن السياسة؟
• هل يمكن للذاكرات المحلية أو تصميم الخدمة تقليل التبعية دون إنتاج إجابات قديمة أو غير آمنة؟
• أي سجلات تُظهر الأثر الحقيقي بدل افتراض عام للمزود؟
• هل تواصل التواصل التشغيلي إذا تعذر Resolver المختار؟

وينبغي أن يسأل المراجعون:

• هل كان لسجل يونيو سلطة إنتاجية كامنة؟
• هل كشف معاينة يوليو سحوبات البادئات Resolver؟
• هل تمرين Canary فعلًا نشر التحديث العالمي؟
• هل سياسة الحماية من البادئات تعتمد صحة مواقع حديثة؟
• متى عادت المسارات؟ ومتى عادت الروابط؟ ومتى عادت الاستعلامات؟
• هل فُصلت إشعارية Tata غير السببية عن سبب الجذر؟
• أي التزامات التصحيح ارتبطت بنتائج اختبار فعالة؟
• ما القيود التي لا تزال حساسة أو غير معروفة؟

الأسئلة لا تطلب توفر اتاحة مثالية. تطلب علاقة محددة وقابلة للفحص بين التحكم والعاقبة.

تحديد حدود المقارنة مهم

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

حادث يونيو 2022 تضمن ترتيب سياسة تصدير BGP، ومعمارية Multi-Colo PoP، وتمهيدًا ممثَّلًا للتغييرات. وهو مذكور بالفعل في مقالة منفصلة لـDaniel Kade. وأما حادث يوليو 2025 فهو سوء ارتباط في نظام طوبولوجيا قديم أدى إلى سحب بادئات Resolver على نحو عالمي.

حادث 1.1.1.1 في يونيو 2024 كان نتجًا عن اختطاف المسار وتسرّبها. [20] هذا المسار مختلف عن سحب داخلي من يوليو 2025.

إعلان Tata Communications India الذي ظهر في يوليو 2025 كان متزامنًا وغير سببي وفق Cloudflare. لا ينبغي دمجه مع المقارنات السابقة أو عرضه كسبب اختفاء Resolver.

فشل الميزات الملفي الذي أصاب Cloudflare يتعلق بخدمة ومسار تحكم مختلف. استخدام عبارة «تكوين عالمي» واسعة لا يجعل الأحداث نسخًا مكررة.

حدود المقال في 2025 دقيقة جدًا: ملكية خاطئة لخدمة إلى بادئة، وتحديث طوبولوجيا عالمي، وسحب مسار، وفقدان روابط الحافة، واسترجاع متعدد الطبقات لخدمة DNS عودية عامة.

حدود السندات

يُعد postmortem لدى Cloudflare المصدر العام الأوضح لآلية الحادث والجدول الزمني والبَادئات ومسارات المرور ومرحل الاسترجاع والتصحيح. إنه حساب طرف أول. السجل العام لا يكشف الرسم الكامل للتكوين أو المترجم أو حالة الراوتر الخاصة، ولا كل عُقَد الحافة، ولا موافقات التغييرات، ولا كل التنبيهات، ولا جرد أثر العملاء، ولا سجل القرار الداخلي. [1]

يوفّر Cloudflare Radar منظورات DNS وتوجيه عامة. وهو تشغيل Cloudflare ويعتمد مصادر مختارة وشبكة Cloudflare. وهو لا يغطّي كل مسار أو Resolver أو مزوّد إنترنت أو مسار مستخدم. [2][3]

تشرح وثائق Cloudflare الحالية Resolver العام، والحل العلوي، واستخدام الشبكة للمشغّلين، وData Localization Suite، وعناوين IP، وسياق PEERING. يتم تحديثها مع الزمن ولا تثبت بنية يوليو 2025 الخاصة أو حالة التصحيح الداخلية. [4]-[11]

مستندات RFC تعرف DNS وAnycast وBGP وDNS المشفّر وorigin validation والممارسات التشغيلية. لكنها لا تُثبّت تنفيذ Cloudflare الخاص، ولا الالتزامات التعاقدية، ولا المعيار القانوني للعناية الواجبة. [12]-[19]

تقرير يونيو 2024 هو مقارنة لحدود الحدث، لا دليلًا على نفس الفاعلين أو أنظمة التحكم التي سببت حادث يوليو 2025. [20]

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

نسبة 77 في المئة تمثل مستوى حركة بعد إعادة الإعلان بحسب حساب Cloudflare، ليست نسبة المستخدمين المستأنفين. ونسبة 23 في المئة تعني خوادم الحافة التي أزالت روابط مطلوبة، لا عدد المستخدمين.

هذه القيود لا تمنع التحليل المسؤولي؛ بل تحدد الأدلة اللازمة للانتقال من تقرير مشغّل غني بالتفاصيل إلى برهان متين على السيطرة.

النتيجة

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

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

المساءلة العملية ليست دعوة عامة لمراجعة التكوين أكثر. إنها سلسلة أدلة محددة:

• مالك واحد مسؤول عن كل بادئة إنتاجية.
• معاينة مترجمة للدلتا العالمية للمسار والربط.
• قاعدة حتمية ضد وصول صفر مواقع إنتاجية سليمة.
• Canary تمثيلية لمسار التنفيذ والتحديث العالمي الحقيقي.
• ملاحظة مستقلة للمسارات ومسارات العملاء.
• توفيق حالة المسار وروابط الحافة وResolver.
• مالك تقيّد التغيير الواحد ومسار استرجاع طارئ مجرَّب.
• أدلة حالية على بقاء التصحيح ساريًا.

تساهم RPKI، ومراقبو BGP، وسجلات الطوبولوجيا، وتذاكر التغيير، وصفحات الحالة في ذلك. لكن أي منها لا يمكن أن يحل محل الخدمة التشغيلية. تصريح المسار لا يثبت جواب Resolver. ومسار صحيح لا يثبت أن الطلب تم الإجابة عنه. وعمليات صحيّة لا تثبت سهولة الوصول. والطوبولوجيا المقصودة لا تثبت حالة الراوترات ونقاط الحافة المطبقة.

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

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

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

المصادر

1. https://blog.cloudflare.com/cloudflare-1-1-1-1-incident-on-july-14-2025/
2. https://radar.cloudflare.com/dns?dateEnd=2025-07-15&dateStart=2025-07-14
3. https://radar.cloudflare.com/routing/prefix/1.1.1.0/24?dateEnd=2025-07-15&dateStart=2025-07-14
4. https://blog.cloudflare.com/announcing-1111/
5. https://developers.cloudflare.com/1.1.1.1/
6. https://developers.cloudflare.com/1.1.1.1/upstream-resolution/
7. https://developers.cloudflare.com/1.1.1.1/infrastructure/network-operators/
8. https://developers.cloudflare.com/data-localization/
9. https://developers.cloudflare.com/fundamentals/concepts/cloudflare-ip-addresses/
10. https://www.cloudflare.com/peering-policy/
11. https://www.peeringdb.com/net/4224
12. https://www.rfc-editor.org/rfc/rfc4786
13. https://www.rfc-editor.org/rfc/rfc4271
14. https://www.rfc-editor.org/rfc/rfc1034
15. https://www.rfc-editor.org/rfc/rfc1035
16. https://www.rfc-editor.org/rfc/rfc7858
17. https://www.rfc-editor.org/rfc/rfc8484
18. https://www.rfc-editor.org/rfc/rfc6811
19. https://www.rfc-editor.org/rfc/rfc7454
20. https://blog.cloudflare.com/cloudflare-1111-incident-on-june-27-2024/