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

ما بدا وكأنه انهيار شامل في الاتصال كان في الحقيقة شيئًا أكثر دقة وأكثر إثارة للقلق: منطقة واحدة في AWS وهي us-east-1 تعرض لفشل في DNS resolution. هذا التوقف في النظام كشف لنا هشاشة البنية الرقمية التي نعتمد عليها جميعًا، وأظهر مدى اعتمادنا على بروتوكول DNS — البروتوكول الذي لا يفكر فيه معظم الناس إطلاقًا. لم يكن هذا مجرد انقطاع، بل كان درسًا.

العمود الفقري الذي نتجاهله: لماذا DNS هو الخطوة صفر

كل تفاعل عبر الإنترنت من فتح موقع إلى تسجيل الدخول إلى تطبيق أو استدعاء API يبدأ بسؤال صامت: “إلى أين أذهب للوصول إلى هذه الخدمة؟، “هذا السؤال الأساسي يُجاب عليه من خلال نظام أسماء النطاقات (DNS). حيث يُطلق عليه بشكل حرفي العمود الفقري للإنترنت.
DNS هو الآلية التي تحول أسماء النطاقات المفهومة للبشر (مثل example.com) إلى عناوين IP قابلة للتوجيه آليًا (مثل 192.0.2.44 أو 2606:4700:4700::1111).

DNS ببساطة وبشكل تقني

ببساطة، DNS هو دفتر عناوين الإنترنت. لكنه ليس كتابًا ماديًا، بل شبكة هرمية معقدة موزعة عالميًا تتكون من:

• Root name servers.
• TLD servers (مثل ‎.com‎ أو ‎.net‎).
• Authoritative name servers (التي تحتوي على سجلات DNS الفعلية).
• Recursive resolvers (تديرها غالبًا شركات الإنترنت أو خدمات DNS العامة).

من الناحية التقنية، يعمل DNS عبر UDP وTCP على المنفذ 53، ويعتمد نموذج query-response stateless.
تستخدم الـ resolvers آليات التخزين المؤقت (caching) وفقًا لقيمة TTL ) Time To Live) المحددة لكل سجل.

عندما يفشل DNS، يكون التأثير فوريًا وكارثيًا:

• لا يمكن لتطبيقك العثور على قاعدة بياناته.
• شبكة CDN تفشل في تقديم الملفات.
• الـ APIs لا يمكنها الاتصال بالخدمات المطلوبة.

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

مدينة أشباح بدون لافتات للتوجيه

خلال الانقطاع الكبير في AWS، لم يكن العطل في خدمات compute أو storage نفسها مثل DynamoDB، بل في فشل DNS resolution لتلك الخدمات.

سلسلة التفاعل الطبيعية تكون:

• التطبيق يحتاج بيانات
• DNS lookup
• IP resolved
• يتم تكوين اتصال
• ترجع البيانات للمخدم

عندما حدث الانقطاع، فشلت الخطوة الثانية. التطبيقات التي تحاول الوصول إلى ‎dynamodb.us-east-1.amazonaws.com‎ لم تتلق عنوان IP، مما تسبب في timeout. قاعدة البيانات كانت تعمل، لكنها أصبحت “مدينة أشباح بدون أي توجيه”.

هذا الفشل في العنوان أدى إلى انهيارات واسعة:

• جلسات عمليات دخول تعطلت
• أخطاء ‎500/503‎
• APIs وتطبيقات تجمدت
• قوائم مهام متوقفة

الراحة على حساب المرونة ومتانة الأنظمة

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

معظم المؤسسات غالبًا دون قصد قامت بإنشاء نقطة فشل واحدة في نظامها بأكمله، مثل:

• مزود سحابة واحد.
• منطقة واحدة (غالبًا ‎us-east-1‎).
• خادم DNS واحد.

هذا الاعتماد المركزي خلق سلسلة خطيرة من التبعيات. فعندما يفشل DNS، يفشل كل شيء. حتى الأنظمة المصممة للكشف عن الانقطاعات (Monitoring Systems) تعطلت أيضًا. لوحات المراقبة، أنظمة التنبيه، وأدوات الـ auto-remediation لم تستطع الوصول إلى وجهاتها لأنها أيضًا تعتمد على DNS.

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

إعادة ابتكار المرونة: حلول مزودي DNS المتطورين

دفعت دروس مثل هذه الحوادث الصناعة إلى التعامل مع DNS كبنية تحتية حيوية وليست تفصيلًا ثانويًا.
شركات مثل Cloudflare وGoogle وQuad9 أعادت تصور DNS لحل مشاكله الجوهرية: المركزية، التأخير، والهشاشة.

ابتكارات Cloudflare توضح نهج DNS الحديث:  

• Global Anycast DNS: يوجه الاستعلامات إلى أقرب عقدة متاحة، وإن فشل مركز بيانات يتم تحويل الحركة فورًا.
• 1.1.1.1 Resolver: خدمة DNS عامة تركز على السرعة والخصوصية.
• DNSSEC Support: توفر توثيقًا مشفرًا للاستجابات.
• Secondary DNS وLoad Balancing: لضمان التكرار بين المناطق والمزودين المختلفين.
• Health-Based Failover: يعيد توجيه الحركة تلقائيًا بعيدًا عن خوادم المنشأ المعطلة.

لم يعد مزوّدو DNS المتطورون يقتصرون على حلّ الأسماء، بل أصبحوا يحرسون استمرارية الخدمة ويمنعون الانهيارات المتسلسلة.

الدروس التي يجب أخذها بجدية

انقطاع AWS لم يكسر السحابة، بل كسر وهم المرونة.  ولأن “الأمل ليس استراتجية”، يجب على فرق التطوير أن تضع استراتيجيات للبقاء حتى عندما تختفي الخريطة، و أخد الاحتياطات و التدبرات اللآزمة لهذه المشاكل.

إجراءات مرونة و زيادة مستوي الاعتمادية على المدى القصير

• تطبيق client-side caching مع قيم TTL طويلة الأمد.
• استخدام circuit breakers للخدمات الخارجية.
• إعداد تنبيهات خاصة بفشل DNS.

إجراءات مرونة و زيادة مستوي الاعتمادية على المدى الطويل

• اعتماد multi-region architecture كإعداد افتراضي.
• الحفاظ على مزودي DNS احتياطيين.
• تطوير استراتيجيات الانهيار التدريجي (graceful degradation).
• استخدام Chaos Engineering لاختبار سيناريوهات فشل DNS.

مراجع إضافية للتعمق في فهم DNS

لمن يرغب في فهم أعمق وتطبيق هذه الاستراتيجيات:

• Cloudflare Learning Center: What is DNS?
  
• Libyan Spider: Cloudflare Pro
  
• Google Cloud DNS Best Practices: Guide
  
• DNSimple: How DNS Works (Animated)