انتقال ULD يحتاج إلى سجل يثبت استمرارية الخدمات

الخلاصة

يجعل مشروع ULD الأول لدى مجموعة DNSSD العملاء يتقاربون على خادم مفضّل واحد لكل وصلة، ويلزم العميل عند الانتقال بإعادة تسجيل جميع خدماته لدى الخادم الجديد.
نجاح المفاضلة لا يثبت بقاء الجرد. المطلوب إيصال انتقال يربط الخادم السابق باللاحق، وسبب التغيير، والخدمات المتوقعة، ونتائج التسجيل والإيجارات والتعارضات، والرؤية عبر unicast وmDNS وعبر IPv4 وIPv6.

الفشل الجزئي لا يطلق إنذاراً واضحاً

الانقطاع الشامل سهل الوصف. تنتهي مهلة استعلامات DNS، يفشل تجديد إيجار SRP، أو تسقط جلسة DNS Push. أما الحالة الأصعب فهي عودة معظم الأشياء لا كلها. يسجل جهاز أربعة موارد محلية، يقبل الخادم الجديد ثلاثة منها، ويصطدم الرابع باسم موجود. تستمر الشبكة وتعمل غالبية التطبيقات، لكن خدمة بعينها تصبح غير مرئية.

يحمل draft-ietf-dnssd-uld-00 تاريخ 18 أغسطس 2026، وهو مشروع إنترنت نشط لدى مجموعة DNSSD في IETF. يقترح Unicast Local Discovery، أو ULD، لاستخدام SRP وDNS أحادي البث في الإعلان والاكتشاف داخل الوصلة، مع إبقاء التوافق مع الأجهزة التي تستخدم mDNS. يستهدف المشروع مسار Standards Track وسيحدّث RFC 6762 إذا اعتُمد، لكنه ليس RFC حالياً، ولا تزال أقسام الأمن واعتبارات موجّهات SNAC وطلب IANA غير مكتملة.

تجمع خدمة ULD خمس وظائف منطقية: مسجّل SRP، وخادم DNS موثوق للمنطقة، ومنطقة .local، وDiscovery Proxy يجلب ما أُعلن عبر mDNS، وAdvertising Proxy يعيد عرض تسجيلات SRP على جانب mDNS. وعند السجلات المشتركة، يُفترض أن تجمع الإجابة بين محتوى المنطقة ورؤية وكيل الاكتشاف.

لهذا السبب لا تكفي إجابة DNS ناجحة. قد تكون المنطقة الجديدة سليمة جزئياً بينما لم ينشر وكيل الإعلان كل ما يلزم إلى أجهزة mDNS. وقد يرى عميل IPv6 نتيجة لا يراها جهاز IPv4. صحة الخادم وصف منفصل عن اكتمال الكتالوج.

قاعدة الاختيار لا تنقل الحالة القديمة

يعلن كل خادم ULD قيمة رقمية في مفتاح pri، وتفوز القيمة الأدنى. يضع المشروع خادم البنية التحتية عند 0، ويعطي الخوادم المؤقتة قيماً أعلى بحسب قدرتها ونوع الوصلة. وعند التعادل تُفضّل قيمة عنوان IPv6 المحلي للوصلة الأصغر رقمياً.

ويعلن خادم البنية التحتية خيار ULD داخل رسائل Router Advertisement في IPv6. يجب على عميل IPv6 استخدام هذا الخيار للاكتشاف أو للتحقق من صفة البنية التحتية التي تعرّف إليها أولاً عبر DNS-SD. يشير النص إلى RA Guard لحماية هذا التعيين.

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

يبحث العميل أولاً عن خادم بنية تحتية، ثم يفاضل بين البدائل المؤقتة، ويعود إلى mDNS إن لم يجد خادماً صالحاً. وبعد اعتماد ULD ينبغي أن يتوقف عن المشاركة المباشرة في mDNS على تلك الوصلة وأن يعتمد على الخادم المختار في عمليات .local.

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

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

يوضح مشروع SRP Replication المنتهي الصلاحية المسار البديل. كان يهدف إلى حفظ الحالة بين شركاء النسخ، وتقليل التعارضات، وإخفاء بعض حالات تبديل الخادم عن العملاء. ذلك المشروع ليس جزءاً من ULD 00. المقارنة مهمة فقط لتحديد موضع الدليل: في ULD الحالي يقع العبء على ملاحظة كل عميل للتغيير وإعادته بناء ما يملكه.

عبارة «أعد تسجيل الجميع» تحتاج إلى خط أساس

قبول تحديث SRP واحد يثبت نجاح تلك الرسالة وحدها. لا يثبت أن العميل أرسل كل ما كان ينوي إرساله. وعدّ السجلات على الخادم الجديد لا يفيد إذا لم تُثبت قائمة متوقعة قبل الانتقال. كما أن استعلام تصفح واحد لا يختبر بالضرورة ما يراه عملاء mDNS عبر Advertising Proxy.

يبدأ الإيصال بتحديد النطاق: الوصلة، والواجهة، وعائلة العناوين، وفترة الرصد. يحتفظ ULD بمثيل ومنطقة .local مستقلين لكل وصلة، وقد يستخدم جهاز متعدد الواجهات ULD على واجهة وmDNS على أخرى. عبارة عامة مثل «انتقل الجهاز» تمحو هذه الفروق.

ثم تُسجّل هويات الطرفين: عنوانا الخادم القديم والجديد المحليان للوصلة، وقيمتا pri، وتصنيف كل منهما بنية تحتية أو مؤقتاً، وكيف حُسم التعادل. ويُصنّف السبب: فشل مستمر، فشل تجديد إيجار، سقوط Push، ظهور مرشح أفضل، أو إجراء من المشغّل.

مصدر صفة الخادم الجديد جزء من الدليل. في البيئة المُدارة يمكن ربطها بطلب تغيير وموافقة. وفي المنزل يمكن تسجيل كونه البوابة الفعلية. ملاحظة خيار RA وسياسة RA Guard ذات صلة، لكنها ليست مصادقة شاملة على الخادم. يسمح المشروع بشهادات موقعة ذاتياً، ويوصي بعدم رفضها، ويقول إن مصادقة الخادم ليست هدف TLS الانتهازي هنا.

أما القلب فهو مطابقة الجرد. قبل المغادرة، ينشئ العميل التزاماً مشفراً لوصف الخدمات المعيارية التي يتوقع إعادة إرسالها. وبعد الانتقال يسجل لكل خدمة القبول أو الرفض أو التعارض أو انتهاء المهلة، والإيجار الممنوح، ونتيجة المحاولة التالية. يستطيع الخادم الجديد توفير بصمة مقابلة للمنطقة. ثم تُختبر إجابة unicast، وما أضافه Discovery Proxy، وما نشره Advertising Proxy إلى mDNS.

يجب فصل IPv4 عن IPv6. اكتشاف البنية التحتية عبر RA خاص بـIPv6، بينما يكتشف عميل IPv4-only الخوادم بواسطة mDNS، وقد يعود إليه إن تعذر الوصول إلى الخادم المفضّل عبر IPv4. نجاح حاسوب مزدوج المكدس لا يمثل كل الأجهزة.

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

دليل صغير بدلاً من سجل مراقبة

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

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

تغطي مدة الاحتفاظ دورة انتهاء الإيجارات وتغيّر الذاكرات المؤقتة ووصول البلاغات المتأخرة، ثم تُحذف الأسماء غير الضرورية. الغاية إثبات انتقال محدد، لا بناء أرشيف للحياة داخل الوصلة.

ما تثبته المصادر وما لا تثبته

يثبت المشروع أن اختيار الخادم وإعادة تسجيل الخدمات عمليتان منفصلتان. لكنه لا يعرّف الإيصال المقترح هنا؛ فهذا تحليل Daniel Kade، لا نصاً من IETF. ولا تتضمن الحزمة الحالية قياسات علنية لمعدل الفقد أو زمن الاستعادة أو التشغيل البيني بين موردين.

يوثق RFC 7113 قيوداً في تطبيق RA Guard. وتحمي مفاتيح SRP وSIG(0) ملكية التسجيل، لكنها لا تثبت اكتمال جرد منقول بين خادمين. كما تبقى سلطة خادم ULD داخل .local في الوصلة، ولا تصبح تفويضاً في DNS العام.

يكتمل الانتقال حين تعود كل خدمة متوقعة، أو تُسحب قصداً، أو تظهر بوصفها استثناءً قابلاً للتحقق. أما فوز الخادم الجديد بالمفاضلة فهو بداية الدليل، لا نهايته.

يحتاج انتقال خادم ULD إلى إثبات بقاء الخدمات المحلية

لماذا هذا مهم

الخلاصة

الفشل الجزئي لا يطلق إنذاراً واضحاً

قاعدة الاختيار لا تنقل الحالة القديمة

عبارة «أعد تسجيل الجميع» تحتاج إلى خط أساس

دليل صغير بدلاً من سجل مراقبة

ما تثبته المصادر وما لا تثبته

المصادر

سياق أعمق للملف الشخصي

الدائرة الاستراتيجية

تحالف القيادات

إحاطة الدائرة الاستراتيجية

إحاطة تحالف القيادات