الخلاصة

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

لنتصور سجل HTTPS موقّعاً يعرض وجهتين. الأولى ذات أولوية أعلى وتوفر HTTP/3 مع مفتاح جديد معلن على أنه إلزامي. الثانية توفر HTTP/2 على منفذ آخر. يختار هاتف حديث الأولى. يتجاهل حاسوب مؤسسي السجل الأول لأنه لا يفهم المفتاح الإلزامي. أما جهاز خلف وكيل يعتمد الأسماء فيعطل SVCB حتى لا يكشف الوجهة لمحلل إضافي.

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

يعرّف RFC 9460 سجل SVCB العام بالنوع 64، وسجل HTTPS المتوافق معه بالنوع 65. الغاية هي إعطاء العميل معلومات الاتصال قبل الجولة الأولى مع التطبيق: وجهات بديلة ومعاملات مرتبطة بها، بدلاً من اكتشاف المسار الأفضل بعد بدء اتصال غير مثالي.

تعني قيمة SvcPriority الصفرية AliasMode، أي تفويض الخدمة إلى TargetName. أما القيمة الموجبة فتعني ServiceMode، حيث يرتبط TargetName بمعاملات SvcParams في السجل نفسه. قيمة التصميم هنا هي الربط: يبقى ALPN والمنفذ وتلميح العنوان تابعاً للوجهة التي وصفها الناشر، فلا تتكون حزمة عشوائية من سجلات تدور بصورة مستقلة.

ولا يعمل AliasMode كـ CNAME شامل. فهو يؤثر في نوع السجل المتوافق المطلوب فقط، ولا يغير الأنواع الأخرى، ولا ينقل أصل HTTPS إلى TargetName. يمكنه حل التفويض عند قمة النطاق، لكن العملاء القدامى يظلون محتاجين إلى A وAAAA صالحين. النشر يتيح تبنياً تدريجياً ولا يفرض قدرة جديدة على كل برنامج.

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

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

يكشف سجل IANA لمعاملات SVCB، المحدث في 25 يونيو 2026، اتساع المساحة. فإلى جانب mandatory وALPN والمنفذ وتلميحات IPv4 وIPv6، توجد ECH ومسار DoH وOHTTP ومجموعات TLS ومسار DNS over CoAP وPvD ومؤشر ثقة المشغل بكل ناقل لخادم الأسماء. يمنح التسجيل رقماً ومعنى مستقراً، ولا يثبت أن كل عميل نفذ المفتاح أو أنه آمن في كل mapping.

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

لكن RFC 9460 يسمح بمحاولات متوازية، وجلب عدة TargetName مسبقاً، واختيار سجل لا يتطلب استعلام DNS إضافياً، والاستمرار في اتصال قائم يتوافق مع السجل ولو كان رقم أولوية سجل آخر أصغر. لذلك لا يتنبأ ملف المنطقة وحده بالمقبس الذي سينجح أولاً.

يبين ALPN الفرق بين العرض والتفاوض. يسرد المعامل مجموعات البروتوكول التي توفرها الوجهة، فيرشح العميل ما يدعمه، ثم يحكم RFC 7301 التفاوض داخل مصافحة TLS. وجود h3 في DNS لا يفعل QUIC في الجهاز، ولا يفتح UDP في الشبكة، ولا يضمن قبول الخادم في تلك اللحظة.

وتبقى عناوين ipv4hint وipv6hint تلميحات لتقليل التأخير. إذا توافرت A أو AAAA محلياً ينبغي تجاهلها. وإلا يستعلم العميل عن TargetName ويمكنه الانتقال من عنوان التلميح عند وصول الجواب الفعلي. اعتبار التلميح سلطة دائمة قد يعطل التوزيع الجغرافي أو موازنة الحمل.

عند وجود عدة عناوين يمكن للعميل استخدام Happy Eyeballs v2 لمنافسة IPv6 وIPv4. النتيجة تتبع توقيت العميل والمسار الحاضر، لا ترتيباً مخزناً في المنطقة.

يوثق DNSSEC طبقة النشر فقط. سجلات HTTPS ليست موثقة تلقائياً؛ إذ يفترض RFC 9460 أن قناة DNS قد تكون تحت سيطرة مهاجم، ويجعل التوقيع والتحقق اختياريين. وإذا كان العميل يفرض DNSSEC على A وAAAA فعليه تطبيق السياسة نفسها على SVCB كي لا يتجاوز سجل مزور حماية العنوان. يحدد RFC 4035 حالات التحقق.

تعني نتيجة Secure أن المنطقة الموقعة نشرت RRset المعني بلا تعديل مكتشف. ولا تعني أن الوجهة تعمل، أو أن الوكيل يسمح بها، أو أن العميل يفهم مفتاحها، أو أن شهادتها صحيحة. صحة التوصية ونجاح الاتصال دليلان مختلفان.

ولا تصبح هوية TargetName هي هوية الخدمة. يظل TLS SNI وHost أو :authority في HTTP يشير إلى الأصل المطلوب. ويؤكد RFC 9525 أن استخدام SVCB أو HTTPS لا يغير متطلبات PKIX الحالية في HTTP أو DNS over TLS. قد يستقبل CDN الاتصال، لكنه ملزم بإثبات الأصل نفسه.

وتوضح المقارنة مع Alt-Svc المبدأ. يستطيع Alt-Svc تغيير المضيف والمنفذ والبروتوكول من دون استبدال الأصل، ويختار العميل البديل وفق معاييره الأمنية. يقدم HTTPS RR معلومات مشابهة قبل أول تبادل HTTP ويستخدم TTL، بينما يصل Alt-Svc عبر HTTP ويستخدم ma. تظل دلالة الأصل والسلطة في RFC 9110 فوق مساري الاتصال.

يحمي التراجع الاستمرارية في النشر التدريجي. ففي بروتوكول قائم مثل HTTP يكون SVCB عادة اختيارياً، ويمكن الرجوع إلى الاتصال التقليدي بعد فشل البدائل. لكن إذا كانت الوجهة المفضلة تقدم ECH أو HTTP/3 أو حماية إضافية، فقد يؤدي إسقاطها إلى downgrade. ويحذر Alt-Svc من الخطر نفسه. ينبغي فصل ميزة الأداء عن الحد الأمني الذي لا يجوز فقده.

ويغير الوكيل موقع القرار. قد يحلل وكيل قائم على الأسماء A وAAAA بنفسه، بينما يكشف استعلام SVCB منفصل من العميل الوجهة لطرف آخر. لذلك يوجب RFC 9460 على العميل الاختياري تعطيل SVCB عندما لا توجد آلية تحليل خاصة مناسبة، وعلى العميل المعتمد عليه رفض الإعداد. وعند الاستخدام يشمل التوافق قدرات الوكيل وموقعه الشبكي.

يقدم RFC 9461 mapping لخدمات DoT وDoH وDoQ. وهو يثبت أن الصيغة المشتركة لا تلغي قواعد البروتوكول الخاصة: يجب تحديد المفاتيح المناسبة، وهوية الخدمة، وسياسة التراجع لكل استخدام.

تساعد تفرقة Heng Lu بين أولوية الكود العامل والمواصفة الأولية الدنيا والقرار المستقبلي المحلي وطبقات الواقع في ترتيب الإثبات. تصف المواصفة، وتنشر المنطقة، وينقل المحلل، ويرشح العميل، ويتفاوض TLS، ثم يثبت التطبيق النتيجة.

لا تنتهي المراجعة عند جواب النوع 65. بل تربط RRset وDNSSEC بإصدار العميل والمفاتيح المفهومة ووضع الوكيل والسجل المختار والعناوين المجربة وALPN والشهادة وسبب التراجع والجواب النهائي. يستطيع الناشر إثبات ما عرضه؛ ويثبت المسار العامل ما استُخدم.