خلل ذاكرة التخزين المؤقت في Azure DNS عام ٢٠٢١ جعل تضخيم إعادة المحاولة اختبارًا للمساءلة

الملخص

• بين الساعة ٢١:٢١ و٢٢:٠٠ بالتوقيت العالمي المنسق في ١ أبريل ٢٠٢١، شهدت Azure DNS مشكلة في توافر الخدمة. قالت Microsoft إن غالبية الخدمات التابعة تعافت بحلول الساعة ٢٢:٣٠ بالتوقيت العالمي المنسق. استخدم إشعارها المجتمعي المعاصر نافذة تأثير تقريبية من ٢١:٣٠ إلى ٢٢:٣٠، بينما أبلغت مراقبة مستقلة عن إنذار قرابة الساعة ٢١:٢٠. هذه ملاحظات مختلفة، وليست بالضرورة ساعات متناقضة. [١][٢]
• وصفت Microsoft زيادة شاذة في استعلامات DNS من أنحاء العالم استهدفت مجموعة من النطاقات المستضافة على Azure. ولم تحدد علنًا جهة مهاجمة أو نية أو شبكة بوتات أو حملة مؤكدة لحجب الخدمة الموزع. يجب أن تظل الزيادة المسبّبة غير مفسرة أبعد من وصف Microsoft. [٢][٤][٥]
• قالت Microsoft إن تسلسلًا محددًا من الأحداث كشف خللًا برمجيًا قلّل كفاءة ذاكرات التخزين المؤقت الطرفية لـ Azure DNS. ولا يكشف السجل العام عن مسار الشيفرة أو مفتاح ذاكرة التخزين المؤقت أو نسبة الإصابة أو تجمع الحواف المتأثرة أو العمل الخلفي الناتج عن كل إخفاق. [٢][٤][٥]
• ومع ازدياد الحمل على خدمة DNS، أعاد العملاء إرسال الطلبات بوتيرة أكبر. قالت Microsoft إن نظام تخفيف الزيادات الحجمية اعتبر عمليات إعادة المحاولة هذه مشروعة، ولذلك لم يُسقطها. وهذا يدعم حلقة تغذية راجعة لتضخيم إعادة المحاولة، لكنه لا يدعم إعادة بناء دقيقة على مستوى الحزم. [٢][٤]
• قالت Microsoft إن المراقبة رصدت انخفاضًا في التوافر، وتدخل المهندسون، وتعافت خدمة DNS تلقائيًا بحلول الساعة ٢٢:٠٠ بالتوقيت العالمي المنسق. وأقرّت بأن زمن التعافي تجاوز الهدف التصميمي. ثم غيّرت منطق التخفيف للحماية من إعادة المحاولة المفرطة، وأدرجت إصلاح خلل ذاكرة التخزين المؤقت بالإضافة إلى كشف أفضل للحركة الشاذة كخطوات تالية. [٢][٤][٥]
• أثّر الحادث على مستوى تحكم في الشبكة وليس على تطبيق واحد. واجه المستخدمون صعوبة متقطعة في تحليل الأسماء المستخدمة من Azure وDynamics وXbox Live وخدمات Microsoft أخرى. لم يكن سجل الخدمة الصحيح كافيًا عندما كان المسار الموثوق قيد التشغيل لا يعيد إجابات يمكن الاعتماد عليها. [١][٣][٦]
• تصف وثائق Azure الحالية شبكة DNS عالمية بتقنية anycast وميزات موثوقية وضوابط للعملاء. وتشرح هذه المواد البنية والمسؤولية، لكن لا يمكن استخدامها دليلًا على التنفيذ الدقيق في عام ٢٠٢١ أو على اكتمال المعالجة. [٧]-[١٣]
• تفصل معايير DNS بين الخدمة الموثوقة والتحليل التكراري وتوثّق كيف تشكّل ذاكرة التخزين المؤقت وعدم الاستجابة وإعادة المحاولة الحمل. وتكتسي وثيقة RFC ٤٦٩٧ أهمية خاصة لأن سلوك إعادة المحاولة لدى المُحلِّل يمكن أن يفرض عملًا مفرطًا على الخوادم الموثوقة. ولا تُظهر المعايير أي العملاء أو المُحلِّلين أسهم بأي حصة خلال هذا الحادث. [١٤]-[٢٢]
• تتبع المسؤولية السيطرة. تحكمت هندسة Azure DNS في شيفرة ذاكرة التخزين المؤقت وسعة الحافة وتشكيل الحركة وتصنيف التخفيف وأتمتة التعافي. وتحكمت فرق خدمات Microsoft في تبعيات DNS المشتركة. وتحكم مشغّلو المُحلِّلات والعملاء في سلوك إعادة المحاولة وذاكرة التخزين المؤقت. وتحكم العملاء في بعض خيارات المراقبة والتفويض لكنهم لم يتمكنوا من فحص أو إصلاح الخلل الداخلي في Azure.
• يتطلب الإصلاح الموثوق أدلة مرتبطة بزمن: نسب إصابة ذاكرة التخزين المؤقت بحسب فئة الاستعلام، ومعدلات إعادة المحاولة، وتشبع الحافة، وتغيرات مناطق جذب anycast، وسلوك قواعد التخفيف، وفحوصات تحليل صالحة معروفة، وتعافي كل خدمة، واختبارات التكرار. ولا ينبغي استنتاج أي من ذلك من تسمية حالة وحدها.

يحتوي الخط الزمني على عدة ساعات

غالبًا ما تصبح تقارير الحوادث أنظف مع مرور الوقت. ينبغي لسجل Azure DNS أن يقاوم هذا التنظيف عندما يمحو تمييزات مفيدة.

وضعت رواية الحادث اللاحقة من Microsoft مشكلة توافر خدمة Azure DNS بين الساعة ٢١:٢١ و٢٢:٠٠ بالتوقيت العالمي المنسق في ١ أبريل ٢٠٢١. وقالت إن غالبية الخدمات تعافت بحلول الساعة ٢٢:٣٠ بالتوقيت العالمي المنسق. أعادت Exoprise إنتاج هذا الحساب وأفادت بأن مراقبتها الخاصة لنظامي DNS والخوادم أطلقت إنذارًا قرابة الساعة ٢١:٢٠. [٢] استخدم إشعار مجتمعي معاصر من أحد موظفي Microsoft، نُشر بينما كان الاستجابة لا تزال جارية، وصفًا لتأثير العملاء بين الساعة ٢١:٣٠ تقريبًا و٢٢:٣٠ بالتوقيت العالمي المنسق. وقال تحديث لاحق من موظف Microsoft على الصفحة نفسها إن خوادم DNS التابعة لـ Microsoft شهدت ارتفاعًا في حركة المرور وأن قدرات DNS المرنة قد فُعِّلت. [١]

تقيس هذه الطوابع الزمنية أشياء مختلفة:

• أول ملاحظة فشل من جهة مراقبة خارجية؛
• وقت البدء اللاحق من المزود لحالة خدمة DNS؛
• الوقت الذي اعتبر فيه المزود أن DNS تعافى تلقائيًا؛
• الفترة التي عانى فيها العملاء من وصول متقطع؛
• الوقت الذي تعافت فيه غالبية الخدمات التابعة.

اقتبس تقرير The Register المعاصر وقت البدء التقريبي ٢١:٣٠ بالتوقيت العالمي المنسق وقال إن Microsoft أعادت توجيه حركة المرور إلى قدرات DNS المرنة أثناء التحقيق. ووصف تأثيرات في مناطق جغرافية كبرى، مع استبعاد سحابة Microsoft الحكومية وخدمات الصين من النطاق المُبلَّغ عنه. [٣] وأفادت TechCrunch بشكل منفصل عن إخفاقات شملت منتجات Microsoft متعددة ونقلت عن Microsoft إقرارها بوجود مشكلة في Azure Portal وخدمات Azure. [٦]

لا تثبت الأدلة العامة لحظة تعافٍ شاملة واحدة لكل اسم أو مُحلِّل أو منطقة أو خدمة. يمكن لذاكرات التخزين المؤقت في DNS أن تجعل الفشل والتعافي يظهران في أوقات مختلفة. قد يستمر مُحلِّل لديه إجابة دافئة في خدمة اسم بعد تراجع التوافر الموثوق. وقد يفشل مُحلِّل آخر بذاكرة تخزين مؤقت باردة فورًا. وعندما يتحسن التوافر الموثوق، يمكن للحالة السلبية أو الفاشلة لدى العملاء والمُحلِّلات الوسيطة أن تؤخر التعافي المرئي. وميّزت Microsoft نفسها بين التعافي التلقائي لـ DNS عند الساعة ٢٢:٠٠ وتعافي غالبية الخدمات عند الساعة ٢٢:٣٠. [٢]

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

الزيادة الشاذة ليست هجومًا مثبتًا

قالت Microsoft إن Azure DNS تلقى زيادة شاذة في الاستعلامات من أنحاء العالم استهدفت مجموعة من النطاقات المستضافة على Azure. [٢][٤] هذا وصف للحجم وتوزع الأهداف. وهو لا يثبت بذاته من ولّد الحركة، أو ما إذا كانت النية خبيثة، أو ما إذا كانت عناوين المصدر مزيفة، أو ما إذا كان الحدث يستوفي تصنيفًا معينًا لحجب الخدمة.

استخدمت بعض التقارير لغة الهجوم. السجل التقني المذكور هنا لا يقدم عينة حزم أو تقرير إسناد أو بيانًا من Microsoft يسمي حملة DDoS. ولذلك فإن المعيار الاستدلالي المستقبلي ضيق:

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

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

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

غيّر خلل ذاكرة التخزين المؤقت تكلفة كل استعلام

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

قالت Microsoft إن كفاءة ذاكرة التخزين المؤقت الطرفية لنظام DNS تراجعت لأن خللًا برمجيًا انكشف من تسلسل أحداث محدد. [٢][٤][٥] العبارة غنية بالمعلومات لكنها ناقصة. فهي لا تذكر ما إذا كانت الاستعلامات المتأثرة قد أخفقت في ذاكرة تخزين مؤقت للإجابات، أو تجاوزت ذاكرة تخزين مؤقت سلبية، أو سببت عمليات بحث خلفية متكررة، أو تنافست على حالة مشتركة، أو أبطلت مدخلات، أو استهلكت موردًا نادرًا آخر. كما لا تحدد ما إذا كانت كل الحواف معرضة للخلل أم مجموعة فرعية فقط تُوصَل عبر مسارات anycast معينة.

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

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

هذه هي حلقة التغذية الراجعة الأساسية التي تدعمها رواية Microsoft:

1. تصل زيادة استعلامات شاذة إلى Azure DNS.
2. يكشف تسلسل محدد عن خلل في كفاءة ذاكرة التخزين المؤقت.
3. تتطلب طلبات أكثر معالجة مكلفة أو تنتظر وقتًا أطول.
4. يتراجع توافر خدمة DNS.
5. يعيد العملاء إرسال الطلبات غير المُجابة.
6. يعتبر النظام الحجمي عمليات إعادة المحاولة هذه مشروعة.
7. تضيف حركة إعادة المحاولة حملًا إلى الخدمة المعطوبة أصلًا.

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

تثبت وثيقتا RFC ١٠٣٤ وRFC ١٠٣٥ أن ذاكرة التخزين المؤقت جزء أساسي من تشغيل DNS. [١٧][١٨] وتعرف RFC ٢٣٠٨ التخزين المؤقت السلبي حتى لا يكرر المُحلِّلون سؤال عدم الوجود نفسه بلا حدود. [١٩] وتصف معايير لاحقة مثل RFC ٨٠٢٠ وRFC ٨١٩٨ طرقًا لتقليل حركة الاستعلامات السلبية غير الضرورية في ظروف معينة. [٢١][٢٢] ولا تثبت أي من هذه الوثائق أن خلل Azure كان يتعلق بالإجابات السلبية. وهي تُظهر فقط أن إعادة استخدام الاستعلامات وحالة ذاكرة التخزين المؤقت والإخفاقات المتكررة متغيرات تشغيلية معترف بها.

قد تظل إعادة المحاولة المشروعة غير آمنة في مجموعها

كان أكثر اعترافات Microsoft أهمية أن إعادة محاولة العملاء اعتُبرت حركة DNS مشروعة، ولذلك لم تُسقِطها أنظمة تخفيف الزيادات الحجمية. [٢][٤]

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

توثق RFC ٤٦٩٧ سلوك المُحلِّل الذي يمكن أن يفرض حمل استعلام مفرط على الخوادم الموثوقة. وتصف أنماطًا يعيد فيها المُحلِّلون المحاولة بعدوانية مفرطة، أو يستعلمون عدة خوادم، أو يواصلون العمل عندما تكون الاستجابة الأكثر انضباطًا ستقلل الحمل. [٢٠] تسبق الوثيقة حادث Azure بسنوات عديدة. وأهميتها ليست أن Azure خالف بالضرورة خوارزمية موصوفة. بل إنها تثبت أن تضخيم إعادة المحاولة عند الحد الفاصل بين المُحلِّل والخادم الموثوق فئة فشل تشغيلية معروفة.

يترك سجل Azure أسئلة عدة دون إجابة:

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

دون هذه القياسات، تظل «إعادة المحاولة المفرطة» فئة مفيدة لكنها ليست تشخيصًا كاملًا.

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

قالت Microsoft إنها حدّثت منطق التخفيف الحجمي فور الحادث لحماية خدمة DNS من إعادة المحاولة المفرطة. [٢][٤] وسيُظهر حساب قابل للتحقق ما الإشارة التي تغيرت، وكيف تميز القاعدة الجديدة بين إعادة محاولة غير ضارة وسلوك إجمالي ضار، وما اختبارات الإيجابيات الكاذبة التي أُجريت، وكيف يمكن للمشغّلين تعطيل الضابط أو ضبطه إذا حجب أسماء مشروعة.

الخدمة الموثوقة والتحليل التكراري مجالان مختلفان للسيطرة

يمر استعلام DNS الخاص بالمستخدم عبر أنظمة تشغلها أطراف مختلفة.

عادةً ما يسأل المُحلِّل العميل الموجود على الجهاز مُحلِّلًا تكراريًا. وقد يجيب المُحلِّل التكراري من ذاكرة التخزين المؤقت. وإذا افتقر إلى إجابة قابلة للاستخدام، يتبع التفويضات ويسأل الخوادم الموثوقة للمنطقة المعنية. وتعرّف وثيقتا RFC ١٠٣٤ وRFC ١٠٣٥ هذه الأدوار وتبادل الرسائل بينها. [١٧][١٨]

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

ولذلك يمكن أن تكون للأعراض نفسها أسباب مختلفة:

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

تشرح RFC ٨٩٠٦ أن الخادم الموثوق غير المستجيب قد لا يمكن تمييزه عن فقدان الحزم من وجهة نظر المُحلِّل. [١٦] ويؤثر هذا الغموض في السلوك الآلي والتواصل بشأن الحادث على حد سواء. وقد يحاول المُحلِّل بشكل معقول عنوانًا موثوقًا آخر، لكن العديد من المُحلِّلين الذين يتخذون القرار نفسه يمكن أن ينقلوا الحمل أو يضاعفوه.

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

يوزّع anycast الاستعلامات لكنه لا يجعل كل حافة متكافئة

تقول وثائق Microsoft الحالية إن Azure DNS يستخدم شبكة عالمية من خوادم الأسماء وتقنية anycast لتوجيه كل استعلام إلى خادم DNS قريب متاح. [٧] ويشرح إرشاد Microsoft لخادم Windows حول anycast النمط العام: تعلن مواقع متعددة عن عنوان الخدمة نفسه ويختار التوجيه مسارًا. [٩]

تصف هذه الوثائق البنية الحالية والممارسة العامة. وهي لا تثبت البنية الدقيقة لعام ٢٠٢١ أو سياسة التوجيه أو سلوك السحب. ينبغي أن يظل هذا الحد الزمني صريحًا.

تشرح RFC ٩١٩٩ لماذا تستخدم الخدمات الموثوقة الكبيرة عادةً خوادم متعددة وتقنية anycast وموازنة الأحمال. كما تحذر من افتراض نموذج نشر شامل واحد. ويؤثر تموضع المُحلِّلات والتوجيه والتناظر وشكل مناطق الجذب في أي مثيل يستقبل الحركة. [١٤]

أثناء زيادة الاستعلامات، يمكن لأي anycast توزيع الحمل. ويمكنه أيضًا إنتاج تجربة غير متساوية:

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

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

ظهرت عبارة «إعادة توجيه حركة المرور إلى قدرات DNS المرنة لدينا» في تقارير الحالة المعاصرة. [٣] وهي أعم من أن تثبت ما تغير. وسيربط الحساب التقني الموثوق العبارة بأدلة:

• أي المسارات أو نقاط نهاية الخدمة تغيرت؛
• أي مناطق الجذب تحركت؛
• هل تحركت حالة ذاكرة التخزين المؤقت أو سُخِّنت؛
• كيف تغيرت معدلات الإجابة والمهلة في كل خطوة؛
• هل قلل التغيير حجم إعادة المحاولة؛
• أي الفحوصات الخارجية أكدت التعافي.

anycast بنية تحتية وليس إعفاءً. وتقاس قيمته بالاستمرارية الملحوظة تحت حمل العمل الفعلي.

تقديم البيانات القديمة خيار وليس علاجًا مفترضًا

عندما تعجز الخوادم الموثوقة عن الإجابة، قد يمتلك المُحلِّل التكراري نسخة منتهية الصلاحية من استجابة كانت صالحة سابقًا. وتعرف RFC ٨٧٦٧ طريقة محدودة لتقديم بيانات قديمة لتحسين المرونة في ظروف محددة. [١٥]

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

ينطوي تقديم البيانات القديمة على مقايضات:

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

للتخزين المؤقت السلبي حدود مماثلة. تقلل RFC ٢٣٠٨ الاستعلامات المتكررة عن الإجابات السلبية المعروفة. وتسمح RFC ٨٠٢٠ للمُحلِّل بالتوقف تحت فرع NXDOMAIN مُتحقق. وتسمح RFC ٨١٩٨ بالاستخدام القوي لسجلات الإنكار الموثقة بـ DNSSEC لتوليف إجابات سلبية إضافية. [١٩][٢١][٢٢]

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

السؤال المدفوع بالأدلة ليس «لماذا فشل كل مُحلِّل في تقديم بيانات قديمة؟» بل:

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

ستحول هذه القياسات نقاش المعايير العام إلى قرار ضبط خاص بالحادث.

تركيز التبعية جعل خللًا واحدًا في DNS يبدو كإخفاقات عديدة في الخدمات

كان الحادث مرئيًا عبر Azure وDynamics وXbox Live وخدمات Microsoft أخرى لأن تحليل الأسماء يقع تحت مسارات خدمة متعددة. وسمّى إشعار الأسئلة والأجوبة من Microsoft كلاً من Azure وDynamics وXbox Live. [١] وأعادت Exoprise إنتاج اتصال من Microsoft 365 أدرج Teams ومجموعة أوسع من المنتجات التابعة. [٢] ووصف The Register وTechCrunch بشكل مستقل شكاوى وصول واسعة عبر خصائص Microsoft. [٣][٦]

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

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

تثير التبعية المشتركة أسئلة مساءلة عدة:

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

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

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

رصدت المراقبة التدهور، لكن الرصد ليس احتواءً

قالت Microsoft إن انخفاض توافر الخدمة فعّل أنظمة المراقبة وأشرك المهندسين. [٢] وقالت Exoprise إن مراقبتها الخارجية أنذرت قرابة الساعة ٢١:٢٠، قرب بداية نافذة DNS لدى المزود عند الساعة ٢١:٢١ لاحقًا. [٢]

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

ينبغي لنظام رصد مفيد أن يفصل بين هذه الإشارات على الأقل:

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

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

يقول الحساب العام إن المهندسين حضّروا سعة خدمة إضافية وقدرة على الإجابة عن استعلامات DNS من نظام التخفيف الحجمي إذا لزم إجراء آخر. [٢] ولا يذكر ما إذا كانت أي من الخطوتين طُبقت فعلًا قبل التعافي التلقائي، أو ما العتبة التي كانت ستطلقها، أو هل كانت السعة ستكسر حلقة التغذية الراجعة.

هذا تمييز ضبط:

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

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

تجاوز التعافي الهدف التصميمي

بيان Microsoft بأن التعافي تجاوز هدفه التصميمي مفيد على نحو غير معتاد لأنه يكشف معيارًا داخليًا دون الإفصاح عن الهدف الرقمي. [٢][٥]

يثير البيان أربعة أسئلة.

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

ثانيًا، أي آلية كان متوقعًا أن تحققه؟ قد تتعافى ذاكرة التخزين المؤقت مع انخفاض الحمل. وقد ينسحب موقع anycast. وقد تُضاف سعة. وقد تتغير قاعدة تخفيف. ودون مالك ضابط ومحفّز، يظل «الهدف التصميمي» طموحًا.

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

رابعًا، كيف تم التحقق من الإصلاح؟ أدرجت Microsoft إصلاح خلل الشيفرة بحيث يمكن التعامل مع الطلبات بكفاءة في ذاكرة التخزين المؤقت وتحسين الكشف التلقائي والتخفيف من الحركة الشاذة. [٢][٤] وقائمة عناصر العمل ليست دليلًا على الاكتمال.

سيربط الإغلاق المناسب كل إجراء باختبار:

دون هذه الأدلة، يستطيع القراء معرفة ما كانت Microsoft تنوي تحسينه لكن ليس مقدار المخاطر التي أزيلت.

اتفاقية مستوى الخدمة ليست بديلًا عن أدلة الحادث

تنشر Azure اتفاقية مستوى خدمة لمناطق DNS. وتعرّف الوثيقة الحالية توافر الخدمة وائتمانات الخدمة المحتملة في ظل شروط تعاقدية محددة. [١٣] وهي مفيدة لتحديد الحد القانوني والتجاري اليوم.

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

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

ولذلك ينبغي لسجل المساءلة أن يفصل بين ثلاثة دفاتر:

1. التوافر التقني: ما الذي أعادته الأنظمة الموثوقة والتكرارية.
2. تأثير العميل: أي الوظائف فشلت، ولمن، وكم استمرت.
3. العلاج التعاقدي: أي الشروط والقياسات وإجراءات المطالبة كانت سارية.

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

تحكم العملاء في البنية، لا في خلل Azure

يصف إرشاد موثوقية Azure الحالي مسؤوليات المزود والعملاء. تشغّل Azure منصة DNS، بينما يهيئ العملاء المناطق والسجلات والتفويض وبعض خيارات المرونة. [٨][١٢]

يمكن للعملاء اتخاذ خطوات مفيدة:

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

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

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

القرار المهم للعميل هو قبول مخاطر موثق:

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

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

تتبع المسؤولية السيطرة والوصول إلى الأدلة

يدعم السجل العام توزيعًا قائمًا على السيطرة.

هندسة Azure DNS

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

إدارة الحوادث في Microsoft

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

مالكو الخدمات في Microsoft

تحكمت الفرق التي تشغّل Azure وDynamics وXbox Live وMicrosoft 365 وأسطح التحكم ذات الصلة في تصميم تبعياتها ومراقبتها الخارجية. ولم تتحكم في خلل DNS، لكن كان يمكنها تحديد ما إذا كانت الأسماء الحرجة وصفحات الحالة وأدوات التعافي تشترك في المسار الموثوق نفسه.

مشغّلو المُحلِّلات التكرارية والعملاء

تحكم مطورو المُحلِّلات والعملاء في فترات إعادة المحاولة وسلوك ذاكرة التخزين المؤقت ومعالجة الفشل. وتُظهر RFC ٤٦٩٧ لماذا يشكل انضباط إعادة المحاولة مسؤولية مشتركة معروفة منذ زمن طويل. [٢٠] ولا يحدد السجل أي التطبيقات ولّدت معظم الحركة، ولذلك لا ينبغي اتهام مشغّل بعينه. وسيقدم تحليل ما بعد الحادث الكامل توزعات إجمالية تسمح للمنظومة بإصلاح الأنماط الضارة.

العملاء

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

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

تُظهر السيناريوهات المضادة أي الضوابط مهمة

يساعد التحليل بالسيناريوهات المضادة على فصل المحفّز والظروف المساهمة والإصلاح.

لو حدثت الزيادة الشاذة دون خلل ذاكرة التخزين المؤقت

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

لو ظهر خلل ذاكرة التخزين المؤقت دون زيادة

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

لو كانت إعادة المحاولة مقيدة فورًا

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

لو قدم كل مُحلِّل إجابات قديمة

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

لو استخدم العملاء مزودين موثوقين اثنين

كانت بعض الأسماء ستحتفظ بمسار مستقل، شريطة تنسيق التفويض وبيانات المنطقة وDNSSEC وسياسة الصحة. وكان يمكن لتبعيات مشتركة أخرى أو سلوك المُحلِّل أن تفشل. التنوع بنية قابلة للاختبار، وليس شعارًا.

لو كانت سعة حافة أكبر متاحة

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

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

ما الذي لا تزال الأدلة العامة عاجزة عن إثباته

تؤسس المصادر مخططًا مفيدًا لكنها تترك السجل الداخلي الحاسم غير متاح.

وهي لا تثبت:

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

لا تستطيع وثائق Microsoft الحالية ملء هذه الفجوات التاريخية. فهي تصف خدمة اليوم والممارسات الموصى بها. [٧]-[١٣] وتعرّف وثائق RFC سلوك البروتوكول والخيارات التشغيلية. [١٤]-[٢٢] وتحفظ التقارير المستقلة البيانات والأعراض لكنها لا تملك قياسات Azure الداخلية. [٢]-[٦]

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

ينبغي أن يكون الإصلاح قابلًا للتدقيق كتسلسل

سيحافظ برنامج معالجة قابل للتحقق على اختبار حادث مشترك بدلًا من قائمة تحسينات منفصلة.

أعِد الإنتاج

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

قِس

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

احتواء

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

تعافَ

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

تحقق من الخدمات التابعة

افحص أسماء تمثيلية لـ Azure ومستوى تحكم Microsoft والعملاء من عدة مُحلِّلات تكراريين وشبكات وصول. وميّز تعافي DNS عن تعافي التطبيق.

تراجع

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

احتفظ بالأدلة

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

يجيب هذا التسلسل عن السؤال المركزي: ليس ما إذا كانت Microsoft أضافت «مزيدًا من المرونة»، بل ما إذا كان تفاعل ذاكرة التخزين المؤقت وإعادة المحاولة نفسه لا يزال قادرًا على تجاوز عتبة الفشل.

الخلاصة

انقطاع Azure DNS في أبريل ٢٠٢١ لم يُفسَّر بحجم الحركة وحده.

قالت Microsoft إن زيادة استعلامات شاذة كشفت خللًا برمجيًا قلل كفاءة ذاكرة التخزين المؤقت الطرفية لنظام DNS. وتسببت الخدمة المتدهورة في إعادة محاولة العملاء. وكانت إعادة المحاولة هذه حركة مشروعة، ولذلك لم يُسقطها التخفيف الحجمي في البداية. تعافت الخدمة تلقائيًا، لكن ليس ضمن هدفها التصميمي. ثم غيّرت Microsoft حماية إعادة المحاولة وقالت إنها ستصلح خلل ذاكرة التخزين المؤقت وتحسن كشف الشذوذ. [٢][٤][٥]

يحدد هذا التسلسل مشكلة مساءلة في البنية التحتية للشبكة بطبقات عدة:

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

الاستنتاج المسؤول ليس أن إعادة محاولة DNS سيئة، أو أن anycast فشل، أو أن العملاء يجب أن يستخدموا دائمًا مزودًا ثانيًا. فكل ادعاء من هذه سيتجاوز الأدلة.

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

السجلات وأوصاف الخدمة وإشعارات الحالة جزء من الأدلة. لكنها ليست الخدمة قيد التشغيل. في ١ أبريل ٢٠٢١، كان يمكن أن تظل الأسماء مُهيأة بشكل صحيح بينما يعجز المستخدمون عن تحليلها بشكل موثوق. تبدأ المساءلة حيث تتباعد هاتان الحالتان.

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

المصادر

1. https://learn.microsoft.com/en-us/answers/questions/341519/outage-notification-dns-issue-impacting-multiple-m
2. https://www.exoprise.com/2021/04/01/azure-dns-outage-april-1st-2021/
3. https://www.theregister.com/2021/04/01/microsoft_azure_dns_outage/
4. https://www.theregister.com/security/2021/04/06/anomalous-surge-in-dns-queries-knocked-microsofts-cloud-off-the-web-last-week/
5. https://virtualizationreview.com/articles/2021/04/08/azure-outage.aspx
6. https://techcrunch.com/2021/04/01/microsoft-outage-knocks-sites-and-services-offline/
7. https://learn.microsoft.com/en-us/azure/dns/dns-faq
8. https://learn.microsoft.com/en-us/azure/reliability/reliability-dns
9. https://learn.microsoft.com/en-us/windows-server/networking/dns/deploy/anycast
10. https://learn.microsoft.com/en-us/azure/networking/design-guide/dns-security
11. https://learn.microsoft.com/en-us/azure/dns/dnssec
12. https://learn.microsoft.com/en-us/azure/dns/dns-zones-records
13. https://azure.microsoft.com/en-us/support/legal/sla/dns/v1_1/
14. https://www.rfc-editor.org/rfc/rfc9199.html
15. https://www.rfc-editor.org/rfc/rfc8767.html
16. https://www.rfc-editor.org/rfc/rfc8906.html
17. https://www.rfc-editor.org/rfc/rfc1034.html
18. https://www.rfc-editor.org/rfc/rfc1035.html
19. https://www.rfc-editor.org/rfc/rfc2308.html
20. https://www.rfc-editor.org/rfc/rfc4697.html
21. https://www.rfc-editor.org/rfc/rfc8020.html
22. https://www.rfc-editor.org/rfc/rfc8198.html