الخلاصة

  • نُشر RFC 2182 بوصفه BCP 16 في يوليو 1997، وتعامل مع مواضع الخوادم باعتبارها مسألة موثوقية تشغيلية.
  • أوصى بثلاثة خوادم لمعظم نطاقات المؤسسات، على أن يكون أحدها على الأقل بعيدًا بوضوح عن البقية.
  • كانت الوثيقة إرشادًا؛ فقائمة NS لا تثبت استقلال الطاقة أو المسارات أو المزودين أو إمكانية الوصول الفعلية.

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

كانت هذه المشكلة التشغيلية محور RFC 2182، «اختيار الخوادم الثانوية لنظام DNS وتشغيلها»، الذي أعده روبرت إلز وراندي بوش وسكوت برادنر ومايكل باتون. نشره IETF في يوليو 1997 بوصفه أفضل ممارسة حالية رقم 16. لم يكن بروتوكول DNS جديدًا، بل محاولة لجعل التكرار الذي يسمح به النظام قادرًا على العمل خارج ملف النطاق، داخل الشبكة الحقيقية.

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

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

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

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

لم يقسّ BCP مدى اتباع المشغلين للتوصيات، ولا أثبت أن بنية بعينها صمدت أمام انقطاع محدد. فقائمة NS المنشورة لا تثبت أن مزودين يستخدمان شبكتي عبور مختلفتين، أو أن موقعيهما يملكان مصدرَي طاقة مستقلين، أو أن المسارات ستبقى منفصلة تحت الضغط. «ثلاثة خوادم» دليل على العدد، لا تدقيق لمسارات الفشل.

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

الفكرة الأهم في RFC 2182 أدق من رقم سحري: يعتمد التكرار على التبعيات. ولا يكون للخادم الثالث أثر حقيقي إلا إذا غيّر ما يمكن أن يتعطل معًا.

المصادر