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

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

إيجابيات الاستضافة الذاتية للشركات الكبيرة

هناك عدة أسباب وراء رغبة مؤسسة كبيرة في إنشاء واستضافة خدمة DNS موثوقة بنفسها:

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

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

مراقبة: بعض الشركات ببساطة لا تريد أن تعتمد على أحد البائعين، لا سيما فيما يتعلق بشيء بالغ الأهمية للأعمال مثل نظام أسماء النطاقات (DNS) الرسمي. وتتمتع شركات أخرى بثقافة "قم بالبناء" التي ترى قيمة في تطوير الأساليب الداخلية التي تنمي المهارات التقنية.

النظرية مقابل الواقع

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

فيما يلي بعض المجالات التي لا يتطابق فيها واقع نظام DNS الموثوق المستضاف ذاتيًا مع النظرية:

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

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

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

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

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

أتمتة: لا يحتوي BIND على واجهة برمجة التطبيقات (API) ولم يتم تصميمه لدعم أي شكل من أشكال الأتمتة. عادةً لا يتم تصميم بنيات DIY لدعم منصات التشغيل الآلي القياسية مثل Ansible أو Terraform. يكاد يكون من المستحيل تنسيق بنيات DIY باستخدام أدوات الطرف الثالث. إذا كان لديك نظام DNS موثوق يمكنك تنفيذه بنفسك، فمن المحتمل أنك عالق في التغييرات اليدوية التي تؤدي إلى إبطاء جهود تطوير التطبيق إلى حد الزحف.

DNS المُدار أمر منطقي

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

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

التعامل مع مخاطر ترحيل DNS

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

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

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

هل أنت مستعد للانتقال من نظام DNS الرسمي المستضاف ذاتيًا؟

احصل على DNS الذي يقوم بالمزيد: IBM NS1 Connect