الخلاصة

  • أضافت النسخة 01 من DNS and mDNS Discovery for MOQT في 5 سبتمبر قواعد لتطبيع URI ومطابقة شهادات X.509. أما النسخة 02 فلم تغيّر سوى رابط مستودع المصدر.
  • عند توجيه SVCB أو SRV الاتصال إلى مضيف مختلف، تبقى سلطة URI الأصلية ذات مخطط moqt هي هوية TLS. لكن مسار mDNS لا يشرح بعد كيف تحصل الخدمة المكتشفة على هذه الهوية المرجعية أو من يجيز لها إعلان _moqt._udp؛ وما زال قسم الاعتبارات الأمنية كلمة TODO فقط.

قد يجلس مستخدم في صالة مؤتمر ويفتح تطبيق البث، فيظهر مُرحّل محلي من دون إعداد. يسرد PTR نسخة الخدمة، ويقدم SRV المضيف والمنفذ، ويقول TXT إن alpn=moqt. أثبتت السجلات وجود مرشح قابل للمحاولة. لم تثبت أن الجهاز يتبع المؤتمر أو أنه مخول بنقل الجلسة المطلوبة.

يؤرخ سجل Datatracker النسخة الحالية في 5 سبتمبر 2026. الاسم هو لمسودة إنترنت فردية، ولا يسجل لها IETF stream أو intended standard level. تقول الصفحة الأولى إن Standards Track هو المسار المقصود وتحيل النقاش إلى قائمة Media over QUIC، لكن ذلك ليس اعتماداً من مجموعة العمل ولا إجماعاً ولا موافقة.

تكشف مقارنة النسخ حدود الخبر. كانت النسخة 00 في أغسطس قد وصفت SVCB وHTTPS وSRV والاكتشاف المحلي. أضافت النسخة 01 عقد الهوية في 5 سبتمبر. ثم صححت النسخة 02 عنوان GitHub وحده. لذلك يوثق إعلان I-D عملاً جارياً أصبح أدق، ولا يعلن معياراً أو تنفيذاً فعلياً.

يختار DNS موضع الاتصال ولا يعين صاحب السلطة

تستخدم المسودة SVCB لـMOQT فوق QUIC مباشرة، وHTTPS لـWebTransport، وSRV كخيار أبسط. يستطيع SVCB وHTTPS حمل ALPN ومعلمات أخرى، بينما يقدم SRV هدفاً ومنفذاً فقط. وهكذا قد يتصل العميل بآلة لا يظهر اسمها في URI الذي بدأ منه.

ترفض النسخة 01 أن ترث هذه الآلة هوية الخدمة. يجب أن يستخدم العميل مضيف URI الأصلي في SNI والتحقق من الشهادة. الهدف الناتج عن الحل وسيط لتوجيه الحزم، وليس principal جديداً. يقرر RFC 9460 الحد نفسه لـSVCB وHTTPS: البديل لا يغير origin authority.

ويشرح RFC 9525 أن reference identifier يأتي من مدخل مضبوط أو سياق آمن. أسماء الوسط التي يولدها DNS لا تصبح مراجع هوية ما لم يحدد التطبيق طريقة موثقة لذلك.

تفصل الإضافة الجديدة طريقة المقارنة. تطبّع حالة الحروف والترميز المئوي وفق RFC 3986، وتضيف المنفذ 443 إذا غاب، وتحذف النقطة النهائية، وتحول الاسم الدولي إلى IDNA بحسب RFC 5890. تمنع wildcard وCN-ID، وتقبل صيغ subjectAltName المناسبة، ومنها SRVName في RFC 4985.

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

الانتساب إلى الرابط المحلي دليل مكاني ضيق

في mDNS يعلن المُرحّل PTR وSRV وTXT داخل .local. تساعد فحوص عنوان المصدر وIP TTL في RFC 6762 على منع مضيف بعيد من ادعاء أنه محلي. وهي لا تميز جهاز الجهة المنظمة من جهاز خصم موجود أصلاً على الرابط نفسه.

يقول RFC إن حل تعارض الأسماء يفترض مشاركين متعاونين من دون سلطة مركزية، ويوصي بآليات تشفير حين لا يكون الجميع موثوقاً. كما ينبه إلى أن .local لا يحمل سلطة عالمية. ويحدد RFC 6763 بناء DNS-SD ويوصي بـDNSSEC عندما تكون الأصالة مهمة، لكنه لا يمنح الإعلان تفويضاً مؤسسياً.

تطلب مسودة MOQT قيمة ALPN معروفة في TXT، فتستبعد عرضاً غير متوافق. لا تحدد تلك القيمة مالك المُرحّل. ولا تزال Security Considerations في النص الحالي TODO. لم تُعرّف بعد الصلة بين نسخة الخدمة المتصفحة وURI الأصلية التي ستحكم X.509، ولا السياسة التي تسمح للمعلن بالتحدث باسمها.

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

تنتهي مطابقة الشهادة قبل أن تبدأ سلطة المحتوى

يعتمد MOQT Transport 20 على QUIC أو WebTransport لحماية النقل، لكنه يترك صلاحية الاشتراك والنشر والـnamespace للتطبيق أو إطار التفويض. قد تكون الشهادة صحيحة للاسم ويظل المُرحّل بلا حق في المسار الإعلامي. وقد يملك الحق ويفشل الاتصال أو المحتوى.

لذلك يحتاج السجل إلى حقائق منفصلة: الإعلان، واجهة الشبكة، مصدر الرابط، الهدف المختار، URI المرجعية، نتيجة X.509، سياسة الثقة، تفويض namespace، الجلسة، والوسائط المرصودة. عبارة «اكتُشف المُرحّل» تمحو المسؤولية بين هذه المراحل.

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

المصادر

  1. سجل IETF Datatracker
  2. MOQT Discovery، النسخة 02
  3. النسخة 01
  4. النسخة 00
  5. إعلان النسخة 02
  6. MOQT Transport، النسخة 20
  7. RFC 9460: سجلات SVCB وHTTPS
  8. RFC 6762: Multicast DNS
  9. RFC 6763: DNS-Based Service Discovery
  10. RFC 9525: هوية الخدمة في TLS
  11. RFC 4985: SRVName
  12. RFC 3986: بنية URI
  13. RFC 5890: تعريفات IDNA
  14. Heng Lu: الحد الأدنى للمواصفة الأولية
  15. Heng Lu: طبقات الواقع
  16. Heng Lu: أولوية الشيفرة العاملة