يعتبر DNS أحد أكثر خدمات الإنترنت موثوقية.
وهذا هو بالضبط السبب وراء نسيان العديد من الشركات أنها تعتمد عليه.
عندما يصبح DNS غير متوفر، تختفي مواقع الويب، وتتوقف واجهات برمجة التطبيقات (APIs) عن الاستجابة، وتفشل اتصالات الشبكة الافتراضية الخاصة (VPN)، وقد ينقطع تسليم البريد الإلكتروني، وتظهر التطبيقات السحابية فجأة وكأنها "غير متصلة بالإنترنت" على الرغم من أن الخوادم نفسها لا تزال تعمل.
غالبًا ما لا يكون الانقطاع في التطبيق نفسه.
إنه في الدليل الذي يخبر الجميع بمكان التطبيق.
قبل تحديث بنيتك التحتية، اسأل سؤالاً بسيطًا.
كم عدد خدماتك الحيوية التي ستظل قابلة للوصول إذا توقف DNS عن العمل لمدة ساعة؟
بالنسبة لبعض الأنظمة الداخلية، قد تكون الإجابة بسيطة بشكل مدهش. قد يظل بإمكان الموظفين الوصول إلى خدمة باستخدام عنوان IP مباشر، أو ملف hosts محلي، أو طريقة وصول طارئة موثقة أخرى أثناء استعادة DNS — تمامًا مثل كيفية حماية البدائل الاحتياطية للشبكة المحلية أولاً (local-first network fallbacks) للعمليات عندما تتعطل مسارات مزود خدمة الإنترنت (ISP). حتى نشر عنوان IP لوصول الطوارئ لخدمات مختارة تواجه العملاء يمكن أن يكون ذا قيمة إذا كانت استمرارية العمل أمرًا بالغ الأهمية وتم تصميم التطبيق لدعم الوصول المباشر إلى عنوان IP، متجنبًا الاعتماد على نقاط النهاية الهشة حيث تنتهي صلاحية النطاقات خلف الروابط المادية أو تفشل.
الجزء المهم ليس الحل المحدد.
بل امتلاك حل قبل حدوث الانقطاع — والتوسع في بناء الاستقلال التكنولوجي عبر جميع البنى التحتية الحيوية.
تقوم معظم المؤسسات ببناء التكرار (redundancy) للخوادم.
بينما يقوم عدد أقل بكثير ببناء التكرار للطريقة التي يجد بها الأشخاص تلك الخوادم.
الخدمة المرنة (resilient service) ليست فقط تلك التي تبقى متصلة بالإنترنت.
إنها الخدمة التي لا يزال بإمكان الأشخاص الوصول إليها.
غالبًا ما يُخطئ بين تأخير DNS وازدحام قناة شبكة Wi-Fi على أنها حدود لعرض النطاق الترددي (bandwidth).
إعداد فريق Anatolia Solutions