الخلاصة

  • لا تعني SvcPriority الأصغر الأفضلية إلا بين السجلات الصالحة لذلك العميل. يسبق الترتيب رفض السجل المشوه أو المتناقض أو غير المتوافق، وقد يجعل مفتاح إلزامي مجهول الخيار الأول الظاهر غير مؤهل.
  • يفوض AliasMode اكتشاف الخدمة من دون تغيير أصلها، ويربط ServiceMode الهدف بمعاملاته. لكن عناوين hint وALPN المنشور وحتى جواب DNS الموثق ليست إلا مدخلات؛ أما A/AAAA وشهادة الاسم الأصلي وALPN المتفاوض عليه واستجابة التطبيق فهي أدلة لاحقة مستقلة.

الأول في اللوحة، والغائب عن قائمة الاختيار

لنفترض أن أصلا نشر سجلين من نوع HTTPS في ServiceMode. يشير صاحب الأولوية 1 إلى حافة جديدة ويحمل معاملا تجريبيا معلما بأنه mandatory. ويشير صاحب الأولوية 2 إلى الحافة القائمة بمعاملات يفهمها العملاء المثبتون. تعرض لوحة التشغيل الأول بوصفه الوجهة المفضلة.

بالنسبة إلى عميل لا يعرف الامتداد، لا تكون تلك الوجهة مرشحة أصلا. يوجب RFC 9460 تجاهل سجل ServiceMode إذا لم يتعرف العميل إلى جميع المفاتيح الإلزامية. ينتقل إلى الأولوية 2 وقد ينجح. لم يقلب ترتيب الأولويات؛ بل حسم الأهلية قبل تطبيق التفضيل.

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

نمطان لا سلطة واحدة

يعرف RFC 9460 النوع 64 لـSVCB والنوع 65 لـHTTPS. يضم كل سجل SvcPriority وTargetName ومعاملات اختيارية. تعني القيمة صفر AliasMode، وتعني القيمة غير الصفرية ServiceMode.

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

ولا يغير alias هوية الأصل. عندما يصل عميل HTTPS إلى TargetName تديره شركة استضافة، يبقى SNI باسم الخدمة الأصلية، وتفحص الشهادة لذلك الاسم، ويحمل HTTP قيمة Host أو :authority الأصلية. التفويض يخص طريق الاكتشاف، لا الهوية التي وثق بها القارئ.

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

الاستبعاد يسبق المفاضلة

قد يؤدي سجل wire مشوه إلى رفض RRset كله والعودة إلى الاتصال بلا SVCB. وإذا تعارضت معاملات يعرفها العميل أصبح السجل غير متسق. ويمكن تجاهل مفتاح مجهول عادي، لكن إدراجه في mandatory يجعل السجل غير متوافق.

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

ولا يفرض mandatory شيئا على الخادم. إنه يخبر العميل أن تجاهل المفتاح يفسد معنى السجل. يجب أن تظهر المفاتيح المذكورة في السجل نفسه، ولا يجوز أن يسرد mandatory ذاته. في HTTPS يصبح port وno-default-alpn إلزاميين تلقائيا عند وجودهما، لأن تجاهل المنفذ يرسل إلى مستمع آخر وتجاهل نفي البروتوكول الافتراضي يعيد خيارا استبعده الناشر.

الإعلان ليس نتيجة التفاوض

يصف alpn حزم البروتوكولات التي يقول الهدف إنه يقدمها، فيستطيع العميل الاستعداد مباشرة لـHTTP/3 عبر QUIC أو HTTP/2 عبر TLS. لكن النتيجة الحقيقية تتقرر في handshake. قد يسبق DNS نشر الحافة، أو يحجب المسار UDP، أو يعمل موقع بإصدار قديم.

لذلك تحفظ التحقيقات مجموعتين: ALPN الوارد من DNS وALPN الذي اتفق عليه الطرفان. وكذلك يقترح port مكان المحاولة ولا يضمن أن سياسة العميل أو الجدار الناري سيسمحان به.

أما ipv4hint وipv6hint فهما لتقليل الانتظار لا لاستبدال A/AAAA الخاصة بـTargetName. إذا كانت إجابات العنوان متاحة محليا ينبغي تجاهل hints. وإن لم تكن متاحة، يستمر الاستعلام ويستخدم العميل الإجابات الرسمية في الاتصالات التالية. قد يبدأ بعنوان مساعد ثم ينتقل إلى عنوان آخر بسبب التوجيه الجغرافي.

يجب أن يسجل الدليل مصدر IP: hint أو Answer أو Additional أو cache أو proxy، مع TTL والشبكة. كتابة «اتصل بهذا العنوان» فقط تمحو الفرق بين سباق مقصود وبيان قديم وانقسام مزود وتحويل عدائي.

الاسم الأصلي يعبر كل التحويلات

يفترض RFC 9460 إمكان نقل SVCB/HTTPS عبر DNS غير موثوق. يقوي DNSSEC مصدر RRset وسلامته لكنه اختياري. وحتى جواب موقع لا يثبت حياة الهدف أو البروتوكول الذي يشغله أو صحة محتواه.

على نقطة النهاية البديلة أن توثق نفسها للخدمة الأصلية. شهادة صحيحة لـTargetName الخاص بالمورد وحده لا تكفي. يحكم DNS الاكتشاف، وتحكم قواعد TLS هوية الطرف، ويسجل ALPN اتفاق هذه الوصلة، ويحمل HTTP سلطة الأصل واستجابته. لا يمكن لمرحلة ناجحة أن تشهد بالنيابة عن البقية.

ولأن HTTP أقدم من SVCB، يكون الاستخدام غالبا اختياريا ويمكن الرجوع إلى المسار التقليدي عند الغياب. لكن فشل استعلام SVCB محمي بسبب خطأ توثيق أو SERVFAIL أو نقل محمي أو timeout ينبغي أن يوقف المحاولة كي لا يستطيع مهاجم حذف المعاملات انتقائيا. أما فشل DNS غير الموثق فيخضع لسياسة محلية أخرى.

وفي بيئة multi-CDN قد ترى استعلامات CNAME وHTTPS وA/AAAA أجيالا مختلفة من النشر. لذلك يجب جلب عناوين TargetName المختار فعلا. هنا تصبح أولوية الكود العامل عملية: قيمة الإعلان تأتي من تنفيذ متوافق، لا من منحه سلطة تلغي أدلة TLS وHTTP.

المصادر