الخلاصة

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

أربع سلطات تلتقي عند قطع واحد

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

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

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

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

اسم منشور لا يساوي قبولاً

سجّل RFC 1537 في 1993 صورة مباشرة للمشكلة تحت تعبير «مفاجأة الخادم الثانوي». كانت بعض الأجهزة تتلقى سيلاً من استعلامات DNS، ثم يكتشف مشغلوها أن معلومات التسجيل عدّتها خوادم ثانوية لمناطق أخرى. ربما لم يُطلب منهم ذلك، وربما لم يُخبروا به أصلاً.

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

تناول RFC 1713 الفجوة من جهة التشخيص: لا يكفي قراءة قائمة الخوادم؛ يجب سؤال كل واحد منها ومراقبة سلوكه. القائمة تحدد أين يُجرى الاختبار، أما الجواب الحي فيحدد هل توجد سلطة فعلية أم لا.

جمع RFC 1912 هذه الخبرة في فبراير/شباط 1996 وحل محل RFC 1537. وهو مذكرة Informational لا Internet Standard. في مثاله التقليدي تذكر منطقة ابن خادماً محلياً وآخر خارجياً، لكن مسؤول الخارجي لم يكمل ـ أو لم يبدأ ـ إعداده كثانوي صحيح. تقول بيانات DNS إن الخادم الخارجي ينبغي أن يعرف المنطقة، فيما تكشف الآلة أنها لا تخدمها.

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

من الإحالة إلى الجواب خمس حالات

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

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

أوضح RFC 2181 لاحقاً اختلاف الدورين عند القطع: NS في قمة الابن جزء من بيانات الابن السلطوية، أما بيانات الأب فهي تفويض يدفع المحلّل إلى الأسفل. ينبغي أن تتوافق الأسماء، لكن مصدر السلطة ووظيفة البيانات ليسا متطابقين. ويحافظ RFC 8499 في مصطلحاته الحديثة على الفرق بين referral وخادم configured to be authoritative لمنطقة.

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

التكرار الورقي يخفي فشلاً متفاوتاً

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

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

قال RFC 1912 إن النتيجة في أفضل حالاتها حركة DNS إضافية، وفي أسوئها تعذر حل المضيفين وارتداد البريد. لم يقل إن كل استعلام يسلك أسوأ طريق. الطابع المتقطع هو ما يجعل الخلل البنيوي يبدو حادثاً عابراً.

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

حتى الحذف موزع بين السلطات

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

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

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

السجل يصف علاقة قبلها أطرافها

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

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

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

المصادر