الخلاصة

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

إخفاء الاسم ليس إخفاءً للمعلومة بالضرورة

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

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

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

العنوان المشترك يسهّل الوصول ويعقّد الإسناد

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

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

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

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

إجابة صادقة عن الحدث الخطأ

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

كانت هناك وسائل متعارف عليها للاستفسار عن الهوية، منها طلب TXT من الفئة CHAOS للاسم HOSTNAME.BIND. مع قيمة يختارها المسؤول. أزال ID.SERVER. الإشارة إلى تنفيذ بعينه، بينما كان VERSION.BIND. متعلقاً بإصدار البرمجية لا بالسؤال نفسه.

تلك الوسائل سهلة وتستخدم DNS وتترك الإفصاح للمسؤول. لم يجعلها NSID ممنوعة أو عديمة النفع. قصورها هو السؤال الإضافي: المعلومة الصحيحة التي ترجع فيه لا ترتبط بالضرورة بالخادم الذي أنتج الإجابة السابقة.

في يونيو 2007 صاغ RFC 4892 المتطلبات انطلاقاً من هذه الفجوة. قد توزع anycast أو موازنة الحمل الاستعلامات المتتالية على خوادم مختلفة. واستخدام ICMP أو بروتوكول آخر للفحص لا يضمن الوصول إلى النظام نفسه. كان المطلوب إدراج طلب التعريف في استعلام تشغيلي عادي، من دون فئة أو نطاق أسماء خاصين لهذا الغرض.

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

طلب فارغ، لا تحدٍّ يجب تكراره

عرّف R. Austein في RFC 5001 خيار NSID ضمن EDNS. يضع الطالب خياراً فارغاً في سجل OPT الشبهِي للاستعلام. يجب ألا يضيف محتوى إلى الطلب، وعلى الخادم تجاهل أي محتوى يصل خلافاً لذلك.

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

إذا كان الخادم يدعم الخيار واختار تلبية الطلب، يضع معلومات التعريف في OPT للإجابة نفسها. التلبية اختيارية، لكن إرسال NSID من دون أن يطلبه العميل ممنوع. لذلك لا يجوز اعتبار غيابه فشلاً في إجابة DNS العادية أو دليلاً على عدم استخدام anycast.

يسجل سجل معلمات DNS لدى IANA الرقم 3 لخيار NSID في EDNS. ما خُصص هو رقم الخيار، لا معرّفات الخوادم الفردية. لا يشرف السجل على توزيع أسماء العقد، ولا يشترط أن تتضمن القيمة مدينة أو منشأة أو عنواناً خاصاً.

المحلّل لا يسلّم سيرة جميع من سألهم

عندما يطلب عميل NSID من محلّل تكراري، فهو يطلب هوية ذلك المحلّل. يستطيع المحلّل بدوره طلب NSID في الاستعلامات التي يوجهها إلى الخوادم الموثوقة، لكن كل واحد منها تبادل مستقل. لا يمرر المعرّف القادم من المنبع على أنه هويته المطلوبة من العميل.

تؤكد المواصفة أن الآلية غير انتقالية. والمقصود بالعمل بين القفزات هنا هو طرفا تبادل DNS، لا كل موجّه IP على المسار. لا توجد سلسلة تضيف إليها الأجهزة هوياتها، ولا قائمة مكتملة بالمشاركين في عملية الحل.

يوضح RFC 6891، وهو تحديث EDNS الصادر في أبريل 2013، أن OPT معلومات تحكم لمعاملة سؤال وجواب محددة، وليس بيانات DNS. لا يجوز تخزينه مؤقتاً أو تمريره أو وضعه في ملفات المنطقة كسجل عادي.

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

البايت الذي يبدو غير مهم قد يكون جزءاً من الدليل

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

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

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

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

الهوية المحلية تحتاج إلى سياسة محلية

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

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

وينطبق الحذر نفسه على الأمن. يناقش RFC 5001 حمولات موقعة أو مشفرة من دون تقديم وصفة مكتملة؛ فالكتلة الثابتة يمكن إعادة تشغيلها. ويضع NSID ضمن إشارات القناة خارج حماية DNSSEC بحد ذاتها. التحقق من مجموعة سجلات لا يعني تلقائياً توثيق حقل NSID المجاور. ذكر TSIG في النص يوضح الحاجة إلى حماية مناسبة عند طلب التكامل، ولا يثبت أن كل تبادل موجود يحققها.

إمكان التنفيذ لا يساوي انتشار الاستخدام

تفصل وثائق إعداد BIND التي حُفظت لهذا البحث، والمعرّفة بالإصدار 9.20.27، بين server-id وrequest-nsid. الأول يحدد ما يُعاد عبر NSID أو ID.SERVER، وقيمته الافتراضية none، مع إمكان اختيار اسم المضيف. الثاني يطلب معرّفات في الاستعلامات التكرارية ويسجل ما يعود منها ضمن فئة nsid، وهو معطل افتراضياً.

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

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

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