الخلاصة

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

الإجابة المرتبة ليست أمراً بفتح الاتصال

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

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

من تدوير العناوين إلى قياس الحمل

يرجع المؤلف بدايات المسألة إلى نحو عام 1986، حين ظهرت تعديلات على BIND تغيّر ترتيب سجلات العناوين. ويذكر تعديلات Shuffle Address التي ارتبطت بـ Bryan Beecher وشيفرة Round Robin التي ارتبطت بـ Marshall Rose باعتبارهما مثالين ربما انتشرا على نطاق واسع. هذا تقدير استعادي، لا إحصاء مستقل.

كان التدوير يغيّر العنوان الذي يظهر أولاً من دون قياس الحمل الحقيقي على كل آلة. ويقارن RFC 1794 ذلك بتعديلات ينسبها إلى Matt Madison في TGV، استخدمت وظائف خاصة بنظام VMS لقراءة أحمال الأنظمة وترتيب سجلات A من الأقل حملاً إلى الأعلى. أخذ ذلك حالة الخادم في الحسبان بصورة أوضح، لكنه اعتمد على نظام تشغيل بعينه وتطلب تغييرات في معالجة السجلات. أحد النهجين أبسط وأوسع قابلية للنقل لكنه لا يقيس الحمل؛ والآخر أدق صلة بالحالة لكنه أقل عمومية.

نقلت متطلبات التوافق الجزء المتغير

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

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

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

بقي القرار الأخير محلياً لدى العميل

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

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

المصادر