كان اسم DNS المستعار ينقل الخدمة ولا يثبت وجودها: RFC 2219

الخلاصة

• جمعت RFC 2219 تسميات DNS التي اعتاد الناس والبرامج تجربتها للعثور على الخدمات، بحيث يمكن للاسم الثابت أن يبقى بعد انتقال الخادم.
• وحدد النص ما لا يثبته الاسم: عنواناً، أو عملية تستمع، أو منفذاً متوقعاً، أو قبول العميل، أو دليلاً كاملاً للخدمات.

الاسم بدا كأنه وعد، لكن جواب DNS لم يكن كذلك

قد يبدو إدخال www.example.org في المتصفح كأنه يحدد الوجهة. لكنه لا يفعل ذلك وحده. فقد لا يعيد DNS أي عنوان؛ وقد يقود العنوان إلى جهاز لا يشغّل خادم HTTP؛ وقد تستمع العملية على منفذ آخر؛ وحتى الخادم العامل يستطيع رفض طلب بعينه. في أكتوبر 1997، جعلت RFC 2219 هذه الفجوة صريحة وهي تحاول تنظيم التسميات التي تعلّم المستخدمون تخمينها.

كان للعُرف نفع مباشر. يستطيع المرء تجربة www أو ftp أو mail من دون معرفة اسم الجهاز. ويمكن للبرنامج أن يخمّن بالطريقة نفسها. والأهم للمسؤول أن يحتفظ باسم موجّه للخدمة حتى لو تغيّر المضيف أو عنوانه. فلا يضطر الزائر إلى تعلّم اسم جديد مع كل نقل. وصفت RFC 2219 هذا الإسناد غير المباشر بأنه وسيلة لنقل الخدمات بين الأجهزة، وقرينة على احتمال أن تقدم مؤسسة ما خدمة معينة.

لم تكن الوثيقة، بوصفها أفضل ممارسة حالية، نوعاً جديداً من سجلات DNS ولا دليلاً عاماً للخدمات. قال المؤلفان إن هذه التسميات كانت قد انتشرت تقريباً في كل مكان؛ وهذا تقدير معاصر في RFC نفسه، لا نسبة انتشار قِسناها على نحو مستقل. جمعت القائمة أسماء مألوفة مثل www وftp وgopher وldap وmail وnews وntp وpop وwhois. أما البروتوكول غير المدرج فعلى مواصفته اقتراح اسم. ما جرى توحيده هو المفردات، لا معاملة تتحقق مما يعمل خلف كل كلمة.

لم يكن هذا القيد هامشياً. فوجود سجل DNS باسم www لا يعني تسجيل خدمة ويب. ولا يلزم أن يُحل الاسم إلى عنوان IP؛ ولا يتعين على أي جهاز الاستماع إلى HTTP؛ كما لا يلزم أن تستخدم العملية المنفذ 80. وحتى إذا تحققت الشروط كلها، لا ضمان بأن يقبل الخادم عملاء عشوائيين. سمت RFC 2219 هذه الأسماء «قرائن» نافعة وطلبت من المنفذين التعامل معها على هذا الأساس. السجل داخل منطقة DNS التابعة للمؤسسة شيء، وسلوك الخدمة شيء آخر.

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

نقل الاسم ينقل معه عبء الصيانة

تعرض RFC 2219 طريقتين لنشر اسم الخدمة. يمكن أن يجعل سجل CNAME الاسم ph.example.org اسماً مستعاراً للاسم القانوني لجهاز. وهذا يقلل تكرار صيانة العناوين عند نقله، لكن قواعد DNS تمنع الاسم الذي يحمل CNAME من حمل بيانات أخرى مثل MX. والبديل نشر سجل A واحد أو أكثر مباشرة تحت اسم الخدمة. عندئذ تظهر العناوين في المكان نفسه، لكن ينبغي مزامنتها مع الأجهزة الفعلية. لم تفرض RFC طريقة واحدة على كل موقع؛ فالاختيار يتبع متطلباته.

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

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

أقرت RFC 2219 أيضاً بأن التسميات الشائعة ليست حلاً كاملاً طويل الأجل للعثور على خدمة بعينها. وأشارت إلى عمل سجلات مواقع الخوادم، المعروف آنذاك بـ RFC 2052. ويجب الحفاظ على التسلسل الزمني: اقتراح SRV سبق RFC 2219، والأخيرة ذكرته عملاً مختلفاً لمعالجة مشكلة اكتشاف أوسع. ثم حلت RFC 2782 محل RFC 2052 ووصفت سجلاً يضم الخدمة والبروتوكول والأولوية والوزن والمنفذ والهدف. لكن لا يستخدمه العميل إلا إذا طلبت مواصفة البروتوكول التطبيقي ذلك. ولم تحوّل المواصفة اللاحقة اسم www بأثر رجعي إلى شهادة تسجيل خدمة.

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

المصادر: RFC 2219؛ سجل RFC 2219 لدى RFC Editor؛ IETF Datatracker: BCP 17؛ RFC 1912؛ RFC 1034؛ RFC 1035؛ RFC 2052؛ RFC 2782؛ RFC 1123.