انقطاع Akamai Edge DNS 2021 ومساءلة التهيئة

ملخص

قالت Akamai أنه في الساعة 15:45 UTC يوم 22 يوليو 2021، تسبب تحديث تكوين برمجي في حدوث خلل في مكون DNS من شبكة توصيل المحتوى Secure Edge. أصبحت بعض مواقع العملاء غير متاحة لمدة تصل إلى ساعة. قامت Akamai بتراجع التحديث، وقالت إن الخدمة عادت إلى طبيعتها، وأكدت أن الحادث لم يكن هجومًا إلكترونيًا. [1]
صحت Akamai نطاق بيانها الأولي في اليوم التالي. وصفت الشركة في البداية تأثيرًا على خدمة DNS الخاصة بها، لكن التحقيقات الإضافية ضيقت النظام المتأثر إلى مكون DNS من Secure Edge CDN. هذا التصحيح مهم: الأدلة العامة لا تثبت أن كل خدمة DNS موثوقة أو منطقة أو عميل Akamai فشل. [1]
لاحظت ThousandEyes فشل DNS وتطبيقات من حوالي 15:38 UTC واستعادة واسعة نحو 16:45 UTC. شهدت اختباراتها مهلات واستجابات SERVFAIL للنطاقات المتأثرة. يعكس الفرق البالغ سبع دقائق بين وقت بدء ملاحظتها ووقت التحديث المعلن من Akamai حدود أدلة مختلفة، وليس طابعًا زمنيًا يجب إدراجه قسريًا في رواية واحدة. [2][3]
أظهر الحادث أن إمكانية الوصول إلى الشبكة تعتمد على أكثر من مجرد وصلات عاملة وخوادم قابلة للوصول. لا يمكن للمستخدم إنشاء اتصال التطبيق المقصود إذا لم تتمكن طبقة التحكم في التسمية من إعادة عنوان قابل للاستخدام، حتى عندما يمكن للحزم السفر إلى حافة CDN. [2][10][11]
يصف توثيق Akamai الحالي لـ Edge DNS أي كاست عالمي ومناطق أولية وثانوية وقوائم تغييرات واختلافات الإصدارات وحالة النشر وإعادة تنشيط الإصدارات السابقة. تحدد هذه الضوابط الأدلة التي يمكن لمنصة ناضجة إنتاجها، لكن توثيق المنتج الحالي لا يثبت أي مسار داخلي تعامل مع تحديث 2021. [5][6][7][8]
تصف ورقة أنظمة Akamai قبل الحادث 24 سحابة أي كاست وخوادم أسماء ذات إدخال مؤجل مصممة للحفاظ على البيانات الأقدم أثناء بعض حالات الفشل الناتجة عن الإدخال. إنها سياق معماري، وليس تحليلاً لاحقًا للحادث. لا تثبت الحزمة العامة ما إذا كان المكون المتأثر استخدم هذا التصميم أو لماذا لم يحتوي هذا الحدث. [9]
المساءلة تتبع التحكم العملي. سيطرت Akamai على المكون المشترك وخط أنابيب التحديث والتحقق والنشر والمراقبة والتراجع وأدلة الإصلاح. سيطر العملاء على أجزاء من تنوع DNS وCDN والشهادات والأصول واختبارات الاستمرارية. سيطرت المحللات العودية على التخزين المؤقت وسياسة خدمة البيانات القديمة. هذه المسؤوليات متعددة الطبقات، لكنها ليست قابلة للتبادل.

الخلل حدث قبل اتصال التطبيق

غالبًا ما يوصف انقطاع الإنترنت كما لو كانت الشبكة عبارة عن مفتاح واحد بحالتين: نشطة أو معطلة. حادثة Akamai مفيدة لأنها تدحض هذه الصورة.

لطلب ويب عادي، يبدأ المستخدم باسم وليس عنوان IP. يتبع المحلل العودي معلومات مخزنة مؤقتًا وإحالات حتى يتمكن من الحصول على إجابة موثوقة للنطاق. يمكن للعنوان المرتجع بعد ذلك توجيه الاتصال نحو حافة CDN أو موازن تحميل أو أصل. إذا فشلت الخطوة الموثوقة، قد لا يحاول المستخدم اتصال التطبيق أبدًا. يمكن لأجهزة التوجيه حمل الحزم. يمكن للخوادم أن تعمل. يمكن للألياف أن تكون سليمة. الخدمة لا تزال غير قابلة للوصول لأن طبقة التحكم في التسمية لم تنتج الوجهة القابلة للاستخدام التالية. [10][11][17]

لاحظت ThousandEyes هذا الفصل خلال حادثة يوليو 2021. أفادت أن الاتصال ببنية حافة CDN الخاصة بـ Akamai يمكن أن يظل متاحًا بينما يفشل تحليل DNS للنطاقات المتأثرة. تلقت الاختبارات استجابات SERVFAIL أو لا استجابة من الخوادم الموثوقة. أظهرت المتصفحات والتطبيقات بعدها حالات فشل بدت كأنها انقطاعات عامة للموقع، على الرغم من أن الخلل المقاس حدث في مرحلة مبكرة من سلسلة التبعيات. [2]

هذا التمييز هو أكثر من مجرد مفردات تقنية. إنه يحدد سطح التحكم.

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

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

لهذا الحادث، يوفر بيان Akamai الخاص المحفز عالي المستوى. قالت الشركة إن تحديث تكوين برمجي تسبب في خلل. لم تنشر التكوين الدقيق أو مسار الشيفرة أو السكان المتأثرين أو الهيكل الداخلي. هذا يعني أن المقال يمكنه تحليل سلطة التكوين وأدلة الوصولية. لا يمكنه تحديد تفاصيل تنفيذ خاصة أو إلقاء اللوم على مهندس فردي أو الادعاء بأن ميزة Edge DNS حالية مسماة فشلت في 2021. [1]

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

التسلسل الزمني يتطلب ساعتين وتصحيح نطاق واحد

تضع ThousandEyes بداية المشكلات المرصودة خارجيًا عند حوالي 15:38 UTC يوم 22 يوليو. تقول Akamai أنه عند 15:45 UTC تسبب تحديث تكوين برمجي في الخلل. تشير هذه الأوقات إلى أشكال مختلفة من المعرفة.

يسجل منصة قياس خارجية عندما تبدأ الاختبارات في الفشل من مواقعها. يسجل مشغل وقت حدوث تغيير أو إطلاق عتبة داخلية أو إعلان حادث. يمكن أن يسبق أول استعلام فاشل للمستخدم تحديث الحالة العامة. يمكن للتكوين أن ينتشر مع مرور الوقت. يمكن للساعات أن تختلف. الطريقة المسؤولة هي ذكر كلا الطابعين الزمنيين ومصدرهما، وليس اختيار الطابع الذي يجعل السرد أنظف. [1][2][3]

لاحظت ThousandEyes زيادة في انقطاعات الويب والتطبيقات بين الخدمات التي تستخدم Akamai. وجدت اختبارات DNS حالات فشل في تحليل النطاقات المستضافة في بيئة CDN. تلقى بعض المستخدمين SERVFAIL؛ والبعض الآخر مهلة زمنية. تفاوتت التأثيرات عبر العملاء والمناطق الجغرافية. تضع شركة القياس الاستعادة الواسعة عند حوالي 16:45 UTC. تقول Akamai إن الاضطراب استمر حتى ساعة وأن الخدمة استؤنفت بعد التراجع. هذه الروايات متوافقة عند المستوى الذي تدعمه الأدلة العامة. [1][2]

بيان Akamai يحتوي على تسلسل زمني أساسي آخر: البيان نفسه تغير.

أضافت الشركة تصحيحًا في 23 يوليو. كان المنشور الأولي وصف تأثيرًا على "خدمة DNS الخاصة بـ Akamai". أظهر التحقيق الإضافي، كما قالت Akamai، أن التأثير كان معزولًا إلى مكون DNS من شبكة توصيل المحتوى Secure Edge الخاصة بها. [1]

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

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

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

أي مكون DNS من Secure Edge CDN تلقى التحديث؟
أي خصائص العميل أو مسارات التسمية اعتمدت عليه؟
هل شارك المكون حالة التكوين عبر مواقع خدمة مستقلة؟
ما مجالات الخلل التي بقيت متاحة؟
كيف انتشر التراجع؟
ما الأدلة التي أثبتت عودة الإجابات العادية؟

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

تنوع DNS ليس نفس تنوع التكوين

يتوقع بنية DNS أكثر من خادم موثوق لمنطقة. يشرح RFC 2182 السبب مباشرة: يجب أن تظل معلومات المنطقة متاحة عندما يكون أحد الخوادم غير متاح أو غير قابل للوصول. يجب وضع الخوادم الثانوية مع وضع أنماط الفشل المحتملة في الاعتبار، بما في ذلك فشل الشبكة والطاقة. [12]

تضيف الخدمات التجارية الكبيرة شكلاً آخر من التوزيع. يصف توثيق Akamai لـ Edge DNS أي كاست IP، حيث يتم الإعلان عن عنوان خدمة منطقي من مواقع فعلية متعددة. يتم توجيه استعلام المحلل نحو مثيل متاح وفقًا لهيكل الشبكة والسياسة. تصف Akamai آلاف خوادم الأسماء عبر شبكات وقارات متعددة. [5]

يشرح RFC 4786 لماذا يعتبر الأي كاست جذابًا لـ DNS الموثوق. يوزع الخدمة ويحسن إمكانية الوصول ويتجنب جعل إحالات DNS تنمو مع كل موقع فعلي. كما يحذر من أن المراقبة تصبح أكثر تعقيدًا: التوفر يعتمد على مكان العميل، ويتغير عدد العملاء الذين يصلون إلى عقدة معينة مع التوجيه. [13]

التنوع الفعلي والتوجيهي قيم. لا يوفران تلقائيًا تنوع التكوين.

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

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

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

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

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

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

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

تحديث التكوين هو تفويض لسلطة الشبكة

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

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

وحدة المخاطر الصحيحة ليست نوع الملف. إنها السلطة الفعلية.

يجب أن يجيب خط أنابيب التغيير على أربعة أسئلة قبل التوزيع.

أولاً،ماذا يعني التحديث بعد التحليل والتطبيع؟صحة الصيغة ليست أمانًا دلاليًا. يمكن أن تكون القيمة جيدة التكوين ومع ذلك تختار حالة مستحيلة أو غير آمنة أو غير متسقة عالميًا.

ثانيًا،أي مستخدمين ومناطق وخدمات ومواقع يمكن أن يؤثر عليهم؟يجب حساب النطاق من النتيجة المترجمة، وليس استنتاجه من اسم طلب التغيير.

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

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

يوفر توثيق Akamai الحالي لـ Edge DNS أمثلة على قطع أثرية تحكم مفيدة. تتراكم تغييرات المنطقة الأولية في قائمة تغييرات. يمكن للمشغل مراجعة الإضافات والحذف وتنشيط المنطقة أو تجاهل التغييرات. يسرد API إصدارات المنطقة ويظهر الاختلافات ويبلغ حالة النشر ويمكنه إعادة تنشيط إصدار سابق. [7][8]

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

للمساءلة العامة، أكثر الأدلة فائدة بعد الحادث ستكون رسم خريطة تحديث 2021 الفعلي إلى قطع أثرية مكافئة:

الغرض المقصود والنطاق المعتمد؛
التكوين المعياري؛
الاختبارات التي أجريت قبل التنشيط؛
عدد سكان الكاناري الأول؛
تسلسل ونسبة المستلمين؛
التنبيهات التي أطلقت؛
قرار وسلطة إيقاف الانتشار؛
الإصدار المعروف بأنه جيد والمختار؛
إقرارات المستلمين بعد التراجع؛
اختبارات خارجية تؤكد إجابات DNS وإمكانية وصول التطبيق.

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

ورقة الهندسة المعمارية لـ Akamai تبلغ الأسئلة، لا الحكم

قبل الحادث، نشر باحثو Akamai ورقة تصف كيف يجيب نظام DNS الخاص بالشركة على حجم كبير من الاستفسارات الموثوقة. تناقش الورقة 24 سحابة أي كاست ومراقبة النظام وآليات معالجة الإدخال القديم أو الخطير. وضع أحد التصاميم خوادم أسماء ذات إدخال مؤجل في كل سحابة. تلقت تلك الخوادم المدخلات مع تأخير مصطنع ويمكنها الاستمرار في الإجابة بالبيانات الأقدم أثناء استجابة المشغلين لفشل ناتج عن الإدخال. [9]

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

لا تقدم الإجابة.

يحدد منشور الحادث للمشغل مكون DNS من Secure Edge CDN. تصف الورقة بنية DNS لـ Akamai على مستوى النظام. لا تثبت المصادر العامة في هذه الحزمة أن المكون المتأثر استخدم تصميم الإدخال المؤجل للورقة، أو أن التحديث المحفز كان أحد المدخلات المؤجلة، أو أن التصميم تم تمكينه لمسار العميل المتأثر، أو أنه فشل.

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

الاستخدام الدفاعي هو افتراضي وأدلّي.

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

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

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

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

سرعة التراجع مهمة، لكن أدلة التراجع أهم

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

التراجع ليس إجراءً واحدًا. إنه سلسلة من الادعاءات.

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

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

هذا الدليل متعدد الطبقات مهم في أنظمة الأي كاست. قد يصل اختبار ناجح من موقع واحد إلى مثيل أي كاست بينما يصل المستخدمون في مكان آخر إلى مثيل آخر. ينطبق تحذير المراقبة في RFC 4786: يمكن أن تبدو الخدمة صحية أو غير صحية اعتمادًا على مسار توجيه المراقب. [13]

لذلك، يجب على المشغل تعريف اكتمال التراجع قبل وقوع حادث:

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

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

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

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

سلوك المحلل غير تجربة المستخدم لكن ليس السبب الجذري

يجلس الحلالون العوديون بين المستخدمين والخوادم الموثوقة. يمكن لذاكرة التخزين المؤقت الخاصة بهم الحفاظ على الإجابات حتى انتهاء صلاحية TTL. تختار خوارزميات إعادة المحاولة الخاصة بهم بين الخوادم الموثوقة. تؤثر معالجتهم لـ SERVFAIL والمهلات والبيانات القديمة على سرعة ظهور الفشل ومدة استمراره.

يعرف RFC 2308 سلوك التخزين المؤقت السلبي. يوثق RFC 4697 أنماط إعادة المحاولة الضارة والحمل الذي يمكن أن ينتج عندما تكون الخوادم الموثوقة غير قابلة للوصول أو تعيد فشل الخادم. يسمح RFC 8767 للمحلل بخدمة البيانات القديمة تحت شروط محددة عندما لا يستطيع تحديث إجابة. RFC 9520، الذي نُشر بعد حادثة Akamai، يحسن التخزين المؤقت السلبي لحالات فشل الدقة بما في ذلك SERVFAIL. [14][18][19][20]

تشرح هذه الآليات لماذا يمكن للمستخدمين تجربة نفس الاضطراب الموثوق بشكل مختلف.

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

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

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

ينتج عن هذا نموذج مساءلة متعدد الطبقات.

تتحمل Akamai مسؤولية المكون الموثوق المشترك وخط أنابيب التحديث. يتحمل مشغلو المحلل مسؤولية معالجة الفشل المتوافقة مع المعايير والقابلة للمراقبة والتواصل بشأن مفاضلة الاستمرارية/الحداثة. يتحمل العملاء مسؤولية خيارات TTL والهندسة التي يمكنهم التحكم فيها. المستخدمون ليس لديهم واجب عملي لتشخيص أي محلل أو مكون موثوق فشل قبل توقع أن تعمل خدمة رئيسية.

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

تكرار العميل يجب أن يكون مستقلاً حتى الأصل

أفادت ThousandEyes أن التأثير تفاوت بين عملاء Akamai. المنظمات التي تعتمد على مسار DNS وCDN المتأثر يمكن أن تظل غير متاحة، بينما حافظت بعض تصاميم CDN المتعددة على خدمة أكثر. تستشهد مراجعتها اللاحقة بأمازون كمثال تم إنقاذه إلى حد كبير بفضل نهج CDN المتعدد. [2][4]

الدرس ليس مجرد "اشترِ CDN ثانِ".

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

يصف RFC 8901 نماذج DNSSEC متعددة المزودين والتنسيق المطلوب لضمان أن المحللين المدققين يمكنهم مصادقة إجابات من مزودين مختلفين. يظهر أن التنوع يقدم طبقة التحكم الخاصة به. يجب أن تظل المفاتيح وسجلات DNSKEY وسجلات DS وخوارزميات التوقيع والتوقيت متسقة. يمكن لنشر متعدد المزودين غير صحيح أن يخلق حالات فشل لا يسببها مزود واحد. [16]

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

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

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

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

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

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

المراقبة يجب أن تربط التكوين وDNS وحالة التطبيق

تمكنت ThousandEyes من إظهار أن حالات فشل التطبيق تزامنت مع مشكلات تحليل DNS. تمكنت Akamai من تحديد تحديث التكوين وعكسه. يحتاج سجل الحادث الكامل إلى ربط هذه الآراء.

خمس طبقات أدلة على الأقل مهمة.

طبقةالتغييرتسجل التكوين المطلوب والتمثيل المعياري والفرق والمراجع ووقت التنشيط ونطاق التوزيع والإصدار السابق.

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

طبقةDNSتسجل نجاح الاستعلام الموثوق والكمون وSERVFAIL والمهلة واتساق الإجابة عبر الأسماء وأنواع السجلات ومسارات الأي كاست والشبكات.

طبقةالمحللتسجل حالة التخزين المؤقت وسلوك الإجابة القديمة وإعادة المحاولة وتأثيرات التخزين المؤقت السلبي.

طبقةالتطبيقتسجل ما إذا كانت الإجابات المرتجعة أدت إلى معاملات TLS وتطبيق ناجحة.

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

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

يوضح السجل العام الفائدة. وقت تحديث Akamai 15:45 وحالات الفشل التي رصدتها ThousandEyes عند 15:38 ليسا متطابقين، لكن معًا يكشفان عن حد يستحق التحقيق. هل بدأ بعض الانتشار قبل المحفز المسجل؟ هل عكس الطابع الزمني للقياس عرضًا مبكرًا؟ هل اختلفت الساعة أو دقة النشر؟ الحزمة المصدر لا تجيب. سجل داخلي مرتبط يمكنه.

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

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

المساءلة تتبع التحكم والقدرة والأدلة

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

هندسة منصة وشبكة Akamai

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

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

مالكو المنتج والتغيير في Akamai

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

هذا الدور ليس إلقاء اللوم على مدير. إنه اعتراف بأن حدود نصف قطر الانفجار ومتطلبات الأدلة هي قرارات منتج وكذلك قرارات برمجية.

عملاء Akamai

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

لم يتحكم العملاء في تحديث Akamai الداخلي. عدم شراء مزود ثانٍ لا ينقل السبب الجذري. يغير تعرض العميل وخيارات الاسترداد.

مشغلو المحلل العودي

سيطر مشغلو المحلل على إعادة المحاولة وتخزين الفشل المؤقت وسياسة الإجابة القديمة والمراقبة. يمكن لتنفيذاتهم تغيير المدة والأعراض المرئية. يجب أن يتبعوا المعايير الحالية ويتجنبوا تضخيم إعادة المحاولة الضار ويكشفوا عن قياسات كافية لتمييز الفشل الموثوق من حالة التخزين المؤقت المحلية. [14][18][19][20]

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

السجلات ومزودو DNS الثانويون

حيث يستخدمهم العملاء، سيطر السجلات والمزودون الثانويون على التفويض ومسارات الخدمة البديلة. تطلبت العملية متعددة المزودين سجلات متسقة وتنسيق DNSSEC وسلطة تغيير وتبديلًا مختبرًا. [12][16]

منظمات المعايير والقياس

حدد IETF سلوك البروتوكول والإرشادات التشغيلية. قدمت ThousandEyes قياسات مستقلة. لم يشغل أي منهما مكون Akamai. كان دورهم جعل آليات الفشل والأدلة العامة أكثر قابلية للقراءة.

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

ادعاء الإصلاح يحتاج إلى اختبار فشل قابل للتكرار

قالت Akamai إنها تراجع عملية تحديث البرمجيات الخاصة بها لمنع الاضطرابات المستقبلية. [1]

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

سيبدأ برنامج إصلاح قوي بنموذج حادث دقيق:

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

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

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

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

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

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

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

يصف توثيق Akamai الحالي قوائم التغييرات والاختلافات والإصدارات وحالة النشر وإعادة التنشيط. هذه لبنات بناء مفيدة للأدلة. لا يمكن للمقال الادعاء بأنها أضيفت بسبب حادثة 2021 أو أنها تنطبق على نفس المكون. يمكنه القول إن القطع الأثرية المكافئة هي المعيار الذي يجب أن يقيم به ادعاء الإصلاح. [7][8]

ما لا يمكن للسجل العام إثباته

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

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

كما لا يمكن للسجل إثبات أن كل عميل يستخدم مزودين متعددين ظل متاحًا، أو أن كل عميل بمزود واحد فشل. تقدم ThousandEyes أمثلة وملاحظات مجمعة من وجهة نظر قياسها، وليس تعدادًا عالميًا. [2][4]

تؤسس RFCs سياق البروتوكول والتشغيل. لا تخلق نتيجة واقعية بأن Akamai انتهكت معيارًا. RFC 9199 وRFC 9520 بعد تاريخ الحادث ويجب ألا يُقدما كالتزامات حكمت تحديث 2021. [15][20]

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

اختبار قابل لإعادة الاستخدام لمساءلة الوصولية

يدعم الحادث اختبارًا عمليًا لأي مزود يدير DNS موثوقًا أو توجيه CDN أو إدارة حركة المرور أو طبقة تحكم شبكة مشتركة أخرى.

1. قم بتسمية سطح التحكم الذي لا غنى عنه.
حدد ما إذا كان المستخدمون يعتمدون على DNS موثوق أو BGP أو أي كاست أو سياسة توجيه أو شهادات أو اختيار أصل أو آلية أخرى. لا تسمِّ الحدث انقطاعًا عامًا.

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

3. تحقق من المعنى بشكل مستقل.
استخدم ضوابط تقارن السلوك المعياري والنطاق المعتمد والبنية التحتية المحمية، وليس نسختين من نفس افتراض المحلل اللغوي.

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

5. حافظ على مسار معروف بأنه جيد ومستقل.
احتفظ بمسار خدمة أو إدارة لا يستهلك الإدخال الجديد فورًا ويمكنه استعادة الحالة السابقة.

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

7. أثبت تقارب التراجع.
أظهر أي المستلمين عادوا، وأي الإجابات عادت، وأي التطبيقات تعافت. رسالة نجاح طبقة التحكم ليست كافية.

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

9. انشر النطاق المصحح.
عندما يضيق التحقيق أو يغير ادعاءًا أوليًا، احفظ التصحيح بشكل بارز وحدد أي استنتاجات تغيرت.

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

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

الاستنتاج

استعادت Akamai الخدمة بسرعة في 22 يوليو 2021. حدد بيانها العام تحديث تكوين وخللًا مسببًا وتراجعًا ومدة تصل إلى ساعة وحدود عدم كون الهجوم إلكترونيًا. ضيق تصحيح اليوم التالي النظام المتأثر إلى مكون DNS من Secure Edge CDN. قدمت ThousandEyes أدلة مستقلة على أن الاضطراب ظهر كفشل في DNS وصولية التطبيقات عبر العديد من المواقع والمستخدمين. [1][2]

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

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

انقطاع Akamai Edge DNS 2021 يحول توزيع التهيئة إلى اختبار لمساءلة الوصولية