Summary

  • وصف تقرير بيركلي لعام 1984 برنامج BIND بوصفه خدمة أسماء لبيئات Unix الموزعة؛ ولم يدّع أن بيركلي اخترع DNS أو كتب أول خادم له.
  • بحلول 1987، وثّقت أدلة التشغيل توزيع BIND مع 4.3BSD. وبعد عامين، وصفه دليل للإنترنت بأنه مدمج في النظام وقادر على استبدال الاستعلام المعتمد على /etc/hosts.
  • كان التغيير عملياً: حددت المواصفات السلوك اللازم للتوافق، فيما أتاح توزيع البرنامج وإدارة المناطق محلياً للمشغلين نشر أسماء شبكاتهم.

المواصفة وحدها لا تجيب عن استعلام

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

في 1984، نشر Douglas Terry وMark Painter وDavid Riggle وSongnian Zhou تقريراً تقنياً عن خادم Berkeley Internet Name Domain. يصف الملخص طريقة مشتركة لتسمية الموارد في بيئات Unix موزعة، وحفظ المعلومات واسترجاعها، وتقسيم فضاء الأسماء الهرمي إلى نطاقات تعكس جهات إدارية. هذا تصميم للبرمجيات والتشغيل، لا مطالبة باختراع DNS. فقد كتب Paul Mockapetris خادماً أسبق اسمه Jeeves، وعمل في USC-ISI وSRI-NIC؛ ويميّز تاريخ ISC اللاحق بينه وبين مشروع بيركلي.

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

الشبكة العاملة غيّرت المواصفات أيضاً

التسلسل الزمني مهم. ظهرت أوصاف DNS الأولى في RFC 882 وRFC 883 عام 1983. وبحلول يناير 1986، كان RFC 973 الذي كتبه Paul Mockapetris يسجل تغييرات وإرشادات تشغيل ومشكلات لوحظت ونواقص في النظام القائم. كما يقول إن التغييرات الشائعة الاستخدام ينبغي اعتبارها جزءاً من المواصفة. أي إن خبرة التنفيذ والتشغيل عادت إلى نص البروتوكول بينما كان النظام يعمل.

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

يقدّم تقرير بيركلي لعام 1984 BIND بوصفه خدمة لموارد Unix الموزعة. ويسمي تاريخ BIND لدى ISC الفريق الأول، ويذكر أن Computer Systems Research Group حافظ على البرنامج حتى الإصدار 4.8.3. يوضح هذا السرد اللاحق مسار التطوير، لكنه لا يحصي الأنظمة التي شغّلت كل إصدار.

توزيع BSD وضع الخدمة في متناول المشغلين

يظهر دليل معاصر في RFC 1033، وهو دليل تشغيل النطاقات الصادر في نوفمبر 1987. يحمل ملحقه عنواناً يذكر صراحة أن BIND «موزع مع 4.3 BSD UNIX». ويشرح ملفات الإقلاع والتخزين المؤقت الخاصة به، ومنها named.boot، ويعرض أمثلة لبيانات المناطق. لا يثبت ذلك أن كل نظام BSD شغّل خادم أسماء، لكنه يبين أن المشغلين استطاعوا الحصول على BIND ضمن توزيعة Unix مألوفة وقراءة تعليمات تهيئته.

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

ويقدم RFC 1118 بعد عامين وصفاً أكثر تحديداً. كتب Ed Krol أن BIND مدمج في 4.3BSD ويُستخدم للبحث عن أسماء المضيفين والعناوين ووكلاء البريد ومعلومات أخرى وتخزينها، وأنه حل محل البحث القائم على /etc/hosts. ويوضح مثال جامعة إلينوي في أوربانا-شامبين فرق الحجم: لم يرد في جدول المضيفين الذي توزعه SRI سوى عدد قليل من الآلات، بينما حُفظت غالبية أسماء نطاق الجامعة في جداول BIND محلية. وظلت تلك الأسماء متاحة لمضيف آخر يشغّل BIND أو أي محلّل DNS.

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

ما أصبح محلياً وما بقي مشتركاً

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

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

للأدلة حدودها. يثبت RFC 1033 توزيع BIND مع 4.3BSD، ويوثق RFC 1118 تكامله ومثال جامعة واحدة. ولا يثبتان انتشاره في كل الأنظمة، أو أنه السبب الوحيد لاعتماد DNS، أو اختفاء جميع ملفات المضيفين. الخلاصة التاريخية الأضيق هي أن BIND ساعد في تحويل DNS إلى خدمة Unix يستطيع المسؤول تشغيلها. أتاح ذلك لكل نطاق أن يدير جزأه مع الحفاظ على التوافق مع بقية شجرة الأسماء.

المصادر