الخلاصة

  • خصص RFC 3397 خيار DHCP رقم 119 لقائمة مرتبة من نطاقات البحث. كان على العميل أن يضم الشظايا وفق RFC 3396 أولاً، ثم يفك مؤشرات ضغط RFC 1035 داخل الكتلة المجمعة الكاملة.
  • عملت القائمة قبل DNSSEC. فقد تصنع لاحقة معادية لكنها مقبولة اسماً كاملاً آخر، ينشر مالك نطاقه سجلات موقعة بصورة مشروعة: إجابة أصيلة عن سؤال لم يقصده المستخدم.

لم تكن الكلمة القصيرة myhost سؤال DNS كاملاً. كان لا بد بين إدخالها وإرسال الحزمة من اختيار لاحقة، وبناء اسم نطاق كامل، وترتيب المحاولات. وحّد RFC 3397 الطريقة التي يستطيع بها خادم DHCP تقديم قائمة الاختيارات تلك إلى العميل.

صدر النص في نوفمبر 2002 ضمن مسار المعايير، وعرّف خيار Domain Search بالرمز 119. كان نطاقه محدداً في DNS. لم يرتب خدمات تسمية مختلفة ولم يختر بينها؛ فتلك وظيفة أخرى تناولها RFC 2937. حمل الخيار 119 فقط قائمة النطاقات التي تكمل الأسماء الناقصة داخل DNS.

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

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

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

شفّر مثال الوثيقة الاسمين eng.apple.com. وmarketing.apple.com. عبر ثلاث نسخ. انتهى الاسم الثاني بـ C004، وهو مؤشر إلى الإزاحة أربعة حيث تبدأ apple.com. في الكتلة المجمعة. لو فُسرت كل شظية منفردة لظهر المرجع باطلاً. كان التجميع في DHCP سابقاً بالضرورة لفك ضغط DNS.

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

بعد الفك تبدأ سياسة المحلل. أحال RFC 3397 إلى إرشادات RFC 1535 وRFC 1536: ينبغي أن تكون قوائم البحث صريحة، لا مستنتجة من اسم المضيف. ويُجرّب الاسم الذي يحتوي نقطة بوصفه اسماً كاملاً أولاً، ثم تضاف إليه النطاقات المحلية بعد الفشل. أما الاسم من دون نقطة فيمكن إلحاق القائمة به فوراً.

هناك وقع التحويل. ربما توقع المستخدم أن تصبح myhost هي myhost.bigco.com. يستطيع خادم DHCP خبيث تقديم roguedomain.com، فيسأل الجهاز عن myhost.roguedomain.com. لم تكن هناك حاجة إلى تزوير إجابة DNS؛ فقد تغير موضوع السؤال قبل وصوله إلى DNS.

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

ليس هذا فشلاً في التشفير، بل حداً لما يثبته. تحدد الإعدادات المحلية الأولوية، ويقترح DHCP اللواحق، ويقبل العميل الخيار ويفكه، ويبني المحلل المرشحين، ويجيب DNS، ويتحقق DNSSEC، ثم يقرر التطبيق الاتصال. لا تستطيع شهادة متأخرة أن تمنح قراراً مبكراً شرعية بأثر رجعي.

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

استهدفت وسائل التخفيف الطبقة المناسبة: تطبيق سلوك البحث في RFC 1536، وعدم السماح لـ DHCP باستبدال معلمات DNS المضبوطة يدوياً، واشتراط توثيق DHCP عند الحاجة قبل قبول الخيار 119. ومع ذلك يثبت توثيق الرسالة هوية مرسل مقبول، لا نية الشخص الذي كتب الاسم القصير.

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

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

يسجل سجل IANA لمعاملات BOOTP/DHCP الرمز 119؛ فيثبت تنسيق التخصيص لا الانتشار أو الصحة. ولا يعرض بحث RFC Editor الحالي خطأً مطابقاً لـ RFC 3397، لكنه لا يمنح محللات البرامج أو أولوية الإعدادات أو المحللات العاملة شهادة صحة.

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

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

المصادر