الخلاصة

  • يتيح next-hop-aliases للوكيل أن يذكر الأسماء البديلة والقياسية التي تلقاها أثناء حل اسم القفزة التالية.
  • قد تكون السلسلة ناقصة أو فارغة أو غير موجودة، ولا تحتوي معلومات DNSSEC؛ لذلك لا تتجاوز الثقة فيها الثقة بالوكيل وبمحللاته.
  • القرار القابل للتدقيق يربط هوية الشاهد، واستجابة DNS، والتحقق، ومصادقة الطرف، والسياسة المحلية، والنتيجة الفعلية من دون دمجها.

ظهرت للعميل سلسلة أسماء مقنعة: اسم مألوف، ثم اسم خدمة، ثم عنوان. كان من السهل قراءة هذه السلسلة كأنها شهادة بأن الوجهة هي حقاً من تدّعيه.

لكن RFC 9532 لا يمنحها هذه السلطة. فهو يعرّف المعامل next-hop-aliases ضمن Proxy-Status كي يبلغ الوسيط عن الأسماء البديلة والقياسية التي تلقاها في سجلات CNAME أثناء حل القفزة التالية. هذه الرؤية مفيدة لعميل وكيل أمامي فوّض عملية الحل، وللكشف عن إخفاء متتبع أو مضيف ضار خلف اسم يبدو بريئاً.

ما يصل إلى العميل هو قول الوكيل عما رآه، لا محضر DNS مستقل.

قد يكون الغياب هو المعلومة الأهم

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

يقر المعيار بأن الأدوات نفسها قد تحجب التاريخ. فواجهات شائعة مثل getaddrinfo قد تعيد الاسم القياسي الأخير عبر AI_CANONNAME من دون الأسماء الوسيطة. لذلك يسمح RFC بمعلومة ناقصة.

قد تكون البنية صحيحة تماماً، بينما القصة مبتورة.

كما يمكن لمحلل تعاودي أو خادم موثوق أن يحذف سجلات CNAME لإخفاء cloaking، ويمكن لوكيل خبيث ألا يبلغ عنها. لذا فإن عدم ظهور دليل ليس دليلاً على عدم وجود الاسم البديل.

طبقتان من الصياغة

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

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

السجل المهني يحتفظ بالبايتات الأصلية، ونتيجة Structured Fields، وخطوات فك الترميز، والـ labels النهائية، وإصدار المحلل. العرض النهائي وحده لا يثبت ما أرسله الوكيل.

لا توجد DNSSEC داخل القائمة

ينص RFC 9532 بوضوح على أن المعامل لا يتضمن معلومات DNSSEC ولا يعني استخدام DNSSEC. إنه hint، ولا ينبغي أن يقرر هوية المورد الذي جرى الوصول إليه. صدقيته تساوي فقط صدقية الوكيل والمحللات التي اعتمد عليها.

يعرّف RFC 4033 وRFC 4035 سلسلة أخرى: مصادقة مصدر بيانات DNS وسلامتها، وسلسلة الثقة، والإثبات الموثق لعدم الوجود. لا تحمل قائمة الوكيل التواقيع ولا نتيجة التحقق.

وحتى DNS الموثق لا يحسم ملكية مفتاح TLS، أو authority في HTTP، أو هوية الحساب، أو حق إرسال cookie، أو الإذن بكشف البيانات. النجاح في طبقة لا يصدر تفويضاً للطبقة التالية.

ابدأ بتسمية الشاهد

أنشأ RFC 9209 Proxy-Status كي يصف الوسطاء كيفية تعاملهم مع الطلب. لذا يبدأ الإثبات من هوية الوكيل، وعلاقة الثقة به، وإصداره، ومكانه في سلسلة الوسطاء.

بعد ذلك يسجل المحلل، وذاكرته المؤقتة، ووضع التحقق، ونسخة الإعداد؛ ثم سؤال DNS وجوابه وCNAME والاسم الأخير والعناوين وTTL؛ ثم مادة DNSSEC المنفصلة. ويسجل كيف جُمعت السلسلة ورُتبت وهُربت ورُمزت. وفي النهاية تحفظ نتيجة الاتصال، ومصادقة الطرف، والسياسة المحلية، وصاحب القرار، وما حدث فعلاً.

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

صيغة مشتركة وقرار محلي

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

لا تثبت المصادر أن منتجاً بعينه يطبق RFC 9532، ولا تقدم أرقام انتشار أو معدل cloaking أو نتائج حوادث. أمثلة RFC شرح للآلية وليست تقارير تشغيل.

قيمة المعامل في حدوده: يجعل أسماء رآها الوكيل قابلة للفحص، من دون ادعاء أنه أثبت من يملك الوجهة.

المصادر