الخلاصة

  • فتح IESG في 3 سبتمبر 2026 مراجعة مجتمعية لمشروع إعادة ميثاق مجموعة DNSSD، وحدد 13 سبتمبر موعداً للتعليقات. وينص الإعلان على أن IESG لم يتخذ قراراً بعد.
  • يشمل المشروع نشر الأسماء المسجلة عبر SRP في mDNS وحل التحديثات المتنافسة للاسم نفسه. ويستهدف draft-ietf-dnssd-tsr-03 نداءً أخيراً داخل المجموعة في نوفمبر، كي يفرّق بين نسخة وكيل قديمة وتحديث أحدث. لكنه لا يصادق على صاحب الاسم ولا يجعل الخدمة آمنة أو متاحة.

تبدأ الواقعة من تبديل مسار لا يبدو مثيراً. يسجل جهاز خدمته لدى مسجل SRP أول. يعمل المسجل أيضاً وكيلاً إعلانياً وينشر السجلات على وصلة mDNS. بعد انقسام الشبكة أو تغيّر مسار anycast، يرسل الجهاز تحديثه التالي إلى مسجل ثان. يظهر العنوان الجديد عبر الوكيل الثاني، فيما يواصل الأول إعلان العنوان السابق.

ترى mDNS مجموعتي سجلات متعارضتين تحت owner name واحد. وتحمي آلية النزاع المعتادة الإعلان الأقدم. هذا تصرف سليم عندما يتحدث جهازان عن نفسيهما: لا ينبغي لوافد جديد أن يستبدل طابعة أو تطبيقاً كان موجوداً. لكن الوكيلين هنا لا يملكان خدمتين مختلفتين؛ إنهما يحملان جيلين من بيانات طالب واحد.

لهذا تصبح الأقدمية قرينة على التقادم، لا على السلطة.

نشر إعلان IESG في 3 سبتمبر مشروع إعادة ميثاق DNSSD للتعليق حتى 13 سبتمبر. يوسع الميثاق المقترح نطاق المجموعة إلى اكتشاف خدمات قابل للتوسع على وصلة واحدة أو عدة وصلات، ونشر أسماء SRP في mDNS، ومعالجة تحديثات متنافسة للاسم نفسه.

لا يعني ذلك أن الميثاق أُقر. يقول الإعلان صراحة إن IESG لم يقرر. كما أن موعد نوفمبر ليس إجماعاً تحقق بالفعل. تعرض صفحة TSR النسخة 03 بوصفها Internet-Draft نشطة على مسار Standards Track، وليست RFC أو دليلاً على نشر فعلي. وطلب رقم EDNS لا يثبت أن IANA خصصته.

توضح RFC 6762 أصل القاعدة. تعمل Multicast DNS على الوصلة من دون خادم سلطة وحيد، بخلاف بنية التفويض في DNS التقليدي كما تصفها RFC 1034. لذلك تستخدم mDNS الاستكشاف والنزاع لحماية الأسماء الموجودة. وتبني RFC 6763 اكتشاف الخدمات على سجلات DNS.

ثم أضيفت الجسور. تجعل RFC 8766 خدمات تعلّمها Discovery Proxy عبر mDNS متاحة في DNS الأحادي. وتعرّف RFC 9665 SRP، حيث يقدم الطالب تحديثاً مرتبطاً بمفتاحه إلى المسجل. أما مشروع Advertising Proxy فيتيح للمسجل إعادة نشر تلك البيانات في mDNS.

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

تقترح النسخة 03 من TSR خيار EDNS باسم Time Since Received لكل owner name. يشير الخيار إلى مجموعة السجلات المعنية، ويحمل key checksum مرتبطاً بالمفتاح العام للطالب، ويعبّر عن الزمن المنقضي منذ استلام البيانات. يحول المستقبل ذلك إلى وقت محلي يقارن به الأجيال.

يفصل checksum بين المصادر، ويفصل الزمن بين نسخ المصدر نفسه. فإذا كان الوكيلان ينشران بيانات مرتبطة بالمفتاح ذاته، لا يُعامل التحديث الجديد كاستيلاء على الاسم لمجرد أن الوكيل القديم تكلم أولاً. ويساعد التصميم أيضاً على خفض probes والإجابات المكررة، وتجنب إعادة تسمية زائفة، ومنع goodbye من حذف سجل ما زال صالحاً عبر وكيل آخر.

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

توفر RFC 6891 حاوية EDNS القابلة للتوسعة. ينسق الشكل المشترك البايتات بين التطبيقات، لكنه لا يصادق على صحة ساعة منتج بعينه أو ذاكرته الدائمة أو cache الخاص به.

أما الحد الأمني فحاسم. يعترف المشروع بأن مضيفاً خبيثاً على الوصلة يمكن أن يتلاعب بالنزاعات. وحتى من دون TSR يستطيع نشر بيانات متعارضة والرد على probe لإحداث حجب خدمة. لا يجوز لبروتوكول يعتمد mDNS أن يفترض أن الخدمة آمنة أو خاصة. يجب توفير المصادقة والتفويض والسرية في طبقة التطبيق أو باستخدام اكتشاف مبني على DNSSEC حين يناسب ذلك.

وتشرح RFC 8882 أن اكتشاف الخدمات قد يكشف الأجهزة والخدمات ونشاط المستخدم. توسيع الاكتشاف عبر الوصلات يوسع جمهور المراقبة. قد يكون السجل الأحدث صحيحاً من ناحية الزمن ومكشوفاً في نطاق غير مسموح من ناحية السياسة.

يجب أن يحتفظ التشغيل بسلسلة إثبات: هوية الطالب ومفتاحه، SRP Update الأصلي، المسجل الذي قبله، الوكيل الذي نشره، owner name، RRset كاملاً، وقت الاستلام وأساس الساعة، checksum، offset، probes، بيانات النزاع، قرار الاختيار وإعادة التسمية وكل goodbye. ثم تُضاف إجابة العميل الفعلية، والوجهة التي اتصل بها، ونتيجة النقل، ومصادقة التطبيق، والأثر الذي رآه المستخدم.

لا تتجاوز أي وثيقة سؤالها. قبول المسجل للتحديث لا يعني أن الوكلاء القدماء سحبوا نسخهم. فوز سجل في مقارنة TSR لا يثبت الوصول إلى endpoint. نجاح الاتصال لا يثبت الهوية. ونجاح مصادقة التطبيق لا يثبت أن caches على وصلات أخرى نسيت العنوان السابق.

السحب يحتاج المسار المعاكس: إيقاف تسجيل المصدر، إزالة حالة المسجل، رؤية انسحاب كل proxy، الحفاظ على النسخ الاحتياطية التي ما زالت صالحة، انتظار TTL وانتهاء cache، ثم إثبات أن endpoint القديم لم يعد يستقبل الحركة. اختفاء الصف من لوحة مركزية لا يكفي.

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

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

المصادر