الخلاصة

  • أنشأت RFC 6761 في فبراير 2013 سجل IANA لأسماء النطاقات ذات الاستخدام الخاص. وعلى أي مواصفة تطلب إدراج اسم جديد أن تجيب عن سبعة أسئلة تتوزع بين المستخدم والبرنامج والمحلّل وخادم DNS والمشغّل وجهة التسجيل.
  • ضمّت القائمة الأولى أسماء محجوزة من قبل ومناطق بحث عكسي لعناوين خاصة. لا يمنحها السجل جواباً واحداً: localhost يعيد عنوان الحلقة المحلية، وinvalid يستدعي رداً سلبياً سريعاً، وقد تعالج شبكة خاصة منطقة البحث العكسي بنفسها.
  • سجّلت RFC 8244 في 2017 غياب إجراء رسمي للتنسيق بين IETF وICANN بشأن هذه التخصيصات، وغموض حدود «الاستخدام التقني». قيد IANA يثبت التصنيف؛ مسار الاستعلام يثبت ما جرى فعلاً.

الختم لا يرد على الاستعلام

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

حجزت RFC 2606 في 1999 أسماء للاختبار والأمثلة والفشل المقصود والمضيف المحلي. كانت المشكلة أن اسماً مخترعاً في دليل أو برنامج قد يصطدم باسم حقيقي لاحقاً. جاءت RFC 6761 بعد ذلك لتسأل سؤال التنفيذ: أي مكوّن يميّز الاسم المحجوز، وأين تتوقف رحلة الاستعلام، وأي جواب يعود؟ حجز الاسم قرار؛ إعطاء الجواب الصحيح عمل تشغيلي.

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

سبعة مكاتب أمام اسم واحد

اشترطت RFC 6761 مواصفة تصدر بإجراء معياري من IETF أو بموافقة IESG. يجب تحديد الأسماء المعنية والإجابة ضمن اعتبارات الحجز عن سبع فئات: هل يتعامل المستخدم مع الاسم بصورة خاصة؟ هل يفعل التطبيق ذلك؟ مكتبات وواجهات حل الأسماء؟ خوادم التخزين المؤقت؟ الخوادم ذات السلطة؟ مشغلو DNS؟ سجلات النطاقات وجهات التسجيل؟

الأسئلة ليست سبعة أوامر متماثلة. في مناطق البحث العكسي الخاصة مثل 10.in-addr.arpa، ينبغي للتطبيق ومكتبة الحل أن يرسلا الاستعلام العادي إلى الخادم المضبوط لديهما. أما خادم التخزين المؤقت فينبغي افتراضياً أن يجيب محلياً وألا يلاحق خوادم السلطة الخارجية. ويمكنه توفير إعداد لشبكة خاصة لديها خادم سلطة يجيب عن تلك المنطقة. رؤية الحزمة وهي تغادر التطبيق لا تعني أن التصميم أخفق؛ موضع الحكم هنا أبعد من التطبيق.

في localhost يختلف الموضع: يفترض أن تعود استعلامات العنوان إلى عنوان الحلقة المحلية من دون التجول في DNS العام. وفي invalid ينبغي أن يظهر النفي مباشرة. وصف «اسم محجوز» يغطي إذن جوابين مختلفين وموقعين مختلفين لتنفيذ القرار. اختبار محلّل عام واحد لا يكشف إن كانت مكتبة جهاز آخر قد ردّت قبل إرسال أي حزمة.

تضم قائمة IANA الحالية أسماء مثل localhost وinvalid وlocal وonion وhome.arpa ومناطق عكسية خاصة، ولكل منها مرجع. بعضها يبقى داخل DNS مع معالجة خاصة، وبعضها يعتمد على سياق محلي أو برنامج محدد. لم تحصر RFC 6761 الفئة في أسماء المستوى الأعلى، ولم تجعل تجاوز DNS قاعدة واحدة للجميع. المعيار المشترك هو وجوب وصف السلوك المطلوب لكل اسم.

يسافر الاسم وتبقى بيئته في مكانها

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

كانت وثيقة أكتوبر 2017 جرداً للمشكلات لا بديلاً جاهزاً عن RFC 6761. ذكرت وجود علاقة اتصال بين IETF وICANN من دون إجراء رسمي لتنسيق تخصيص الأسماء الخاصة. كما ذكرت غياب تحديد متفق عليه لما يعد «استخداماً تقنياً». للجهتين دور في فضاء الأسماء، لكن أياً منهما لا تستطيع منع طرف خارج العملية من استخدام سلسلة أحرف أولاً.

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

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