الخلاصة

  • وصف RFC 8552، المنشور في مارس 2019، فرعاً يبدأ اسمه بشرطة سفلية لحفظ سجلات تتعلق بالنطاق الأب. والاسم المسطر الأقرب إلى جذر DNS هو الاسم ذو النطاق العالمي.
  • يقيد سجل IANA الاقتران بين نوع سجل المورد والاسم العالمي. تراجع الخبرة وضوح هذا الاقتران وتفرّده؛ أما الأسماء الأعمق فيحددها البروتوكول الذي يملك الفرع.
  • حدّث RFC 8553 مواصفات أقدم، ومنها قوالب SRV وURI، لكي تشير إلى السجل الموحد مع الحفاظ على البرمجيات والتشغيل القائمين. قيد السجل يثبت تخصيص الاسم، لا أن نطاقاً بعينه نشر بيانات صالحة تحته.

النوع واحد والمعاني كثيرة

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

تشرح وثيقة RFC 8552 حلاً مكانياً. توضع بيانات البروتوكول تحت اسم فرعي مثل _name.example.org، ويبقى example.org هو النطاق الذي تصفه البيانات. يسأل العميل عن الفرع المقصود فيحصل على السجلات الموجودة فيه. لا يتغير نوع TXT، ولا تتغير صيغة حزمة DNS؛ يصبح موضع السجل جزءاً من طريقة قراءته.

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

سبقت الفكرة سجل 2019 بزمن طويل. نص RFC 2782 في فبراير 2000 على صيغة _Service._Proto.Name لسجلات SRV، واضعاً الشرطة قبل اسم الخدمة والبروتوكول لتجنب التعارض مع أسماء المضيفين العادية. واستعمل DNS-Based Service Discovery الاتفاقية المعروفة لاحقاً. تشرح هذه المواصفات كيف يجري استعلام خدمتها. أما سؤال 2019 فكان: من ينسق الاسم الخارجي حين تحتاج بروتوكولات كثيرة إلى فروع ذات معنى داخل DNS؟

الباب المشترك أقرب إلى الجذر

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

أنشأت IANA سجل أسماء عقد DNS المسطرة ذات النطاق العالمي. تسرد أعمدته نوع السجل، واسم العقدة، والمرجع. مفتاحه زوج محدد: (RR Type, _NODE NAME). يمكن لنوع واحد أن يظهر تحت اسمين عالميين مختلفين، ويمكن لاسم واحد أن يقترن بنوعين مختلفين. موضع التصادم هو مطالبة ثانية بالزوج نفسه لمعنى آخر. هذا أضيق من منع كل الأسماء المسطرة، وأدق من محاولة تسجيل كل اسم داخلي ينشئه كل تطبيق.

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

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

لحق التنظيم بالممارسة

نشأت أسماء كثيرة ذات شرطة سفلية قبل وجود هذا السجل الموحد. لذلك عالج RFC 8553، المنشور مع RFC 8552 في مارس 2019، الورق القديم: حدّث مواصفات سابقة وراجع القوالب المستخدمة لإنشاء أسماء SRV وURI العالمية كي تحيل إلى الإجراء الواحد. لم تكن تلك حملة لإعادة تسمية السجلات في المناطق القائمة.

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

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

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