الخلاصة

  • يرتب الخيار 23 في RFC 3646 عناوين المحللات التكرارية حسب التفضيل، ويقدم الخيار 24 قائمة بحث خاصة بـ DNS؛ ولا يثبت أي منهما ما ثبته المضيف أو استخدمه.
  • ينبغي فصل توثيق مصدر DHCP عن أولوية السياسة المحلية، وتحويل الاسم، واختيار الخادم، وصحة الإجابة، وقرار DNSSEC، وأثر التطبيق.

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

يحدد RFC 3646 الخيار OPTION_DNS_SERVERS برقم 23، ويحمل عنواناً واحداً أو أكثر من عناوين IPv6 لخوادم DNS التكرارية بترتيب تفضيل محلل العميل. أما OPTION_DOMAIN_LIST برقم 24 فيحمل قائمة نطاقات البحث لتحليل أسماء المضيفين عبر DNS وحده. وتبين النسخة النصية أن الخيارين لا يظهران إلا في Solicit وAdvertise وRequest وRenew وRebind وInformation-Request وReply.

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

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

يوصي RFC 3646 بطلب مصادقة DHCP قبل تثبيت قائمة خوادم أو قبول قائمة بحث، لأن خادم DHCP دخيل يستطيع تحويل الاستعلامات. غير أن المصادقة لا تختبر صحة الخدمة ولا تضمن أن السياسة المحلية اختارت القيمة. كما يشرح RFC 4033 خدمات DNSSEC؛ ويمكن لسجل داخل نطاق بحث خاطئ أن يكون موقعاً توقيعاً مشروعاً. نجاح التحقق لا يعيد بناء الاسم الذي كان ينبغي طلبه.

يحفظ المعيار سلطة المضيف أيضاً: إعدادات DNS اليدوية لا ينبغي أن يستبدلها DHCP. لذلك لا تكفي حزمة Reply لإثبات الحالة النهائية. يجب معرفة هل وُجد إعداد يدوي، وما قاعدة الأولوية، وهل قُبل الخيار، وما الذي ظهر في حالة المحلل بعد ذلك.

ويضيف RFC 8106 مصدراً آلياً آخر من خلال خيارات Router Advertisement للخوادم التكرارية ونطاقات البحث. قد يصل العنوان نفسه عبر DHCPv6 وRA بصلاحيات زمنية ومصادر مختلفة. إزالة التكرار بحسب القيمة وحدها تمحو سبب بقاء الإعداد.

يوفر RFC 3315 السياق الأصلي لـ DHCPv6، بينما حل محله RFC 8415 كأساس حالي. ويسجل RFC 8504 متطلبات عقد IPv6. هذه التزامات معيارية، وليست شهادة عن حالة جهاز بعينه.

تشرح بنية RFC 1034 ورسائل RFC 1035 طبقة DNS نفسها. ويقدم RFC 3397 نظيراً لقائمة البحث في DHCPv4. تساعد هذه المراجع على تفسير السلوك، لكنها لا تحل محل أثر الاستعلام المرصود.

يسند سجل IANA لمعاملات DHCPv6 الرقمين 23 و24. وهذا يثبت تنسيق المفردات، لا الإعلان أو القبول أو التثبيت أو النتيجة. وتوثق صفحة Datatracker وصفحة معلومات RFC Editor وسجل التصويبات وتاريخ الوثيقة أصل المعيار وحدوده، لا انتشار تطبيقه.

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

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