الخلاصة

  • وافق فريق DNSSD في 18 أغسطس على draft-ietf-dnssd-uld-00 بوصفها وثيقة فريق عمل، وربطها بالمسودة الفردية التي تحل محلها. لم يتغير المتن التقني بعد التطبيع.
  • تجمع ULD مسجل SRP وDNS موثوقاً ووظيفتي وسيط في خادم مفضل على الوصلة. قد تخفف كلفة mDNS على Wi-Fi، لكن قسم اعتبارات الأمان ما زال TODO فقط.

لا تحمل النسخة الجديدة بروتوكولاً جديداً بقدر ما تحمل مسؤولية جديدة عن بروتوكول قائم على الورق.

يسجل تاريخ وثيقة فريق العمل في اللحظة نفسها، 16:22:50 بالتوقيت العالمي يوم 18 أغسطس، موافقة الرئيس على النسخة -00 وإتاحتها وربطها بوثيقة draft-tlmk-infra-dnssd التي تستبدلها. وبعد حذف اسم الوثيقة والتاريخ والانتهاء ورابط المستودع وترويسات الصفحات، يتطابق النصان. لذلك فالحدث هو انتقال العمل إلى DNSSD رسمياً، وليس إضافة سلوك تقني في ذلك اليوم.

سبق هذا الانتقال تصحيح علني للإجراء. يذكر تاريخ المسودة السابقة أن الرئيس سجل التبني أولاً بعد إظهار للأيدي في جلسة IETF 126، ثم أعاد الوثيقة لأنه أدرك أن دعوة التبني على القائمة البريدية كان ينبغي أن تسبق القرار. صدرت الدعوة في 21 يوليو، وسجلت حالة «Adopted by a WG» في 6 أغسطس. يثبت السجل أن القرار قابل للمراجعة، ولا يثبت أن كل مسألة تقنية حُسمت.

تعالج مسودة ULD كلفة صغيرة تتكرر في الشبكات المحلية. في mDNS يستمع كل جهاز يعلن خدمة إلى استعلامات البث المتعدد ويرد عليها. إطارات البث المتعدد في Wi-Fi لا تحصل على إقرار أو إعادة إرسال في طبقة MAC، ولا يحتفظ بها مركز الوصول لمحطة نائمة، كما ترسل بسرعة إلزامية منخفضة. إما أن يستيقظ الجهاز العامل بالبطارية مراراً، وإما أن يفقد بعض الاستعلامات؛ وقد تستهلك حركة محدودة زمناً لاسلكياً غير متناسب.

تقترح ULD وسيطاً يعمل باستمرار. يجمع الخادم مسجل SRP وخادم DNS موثوقاً وDiscovery Proxy وAdvertising Proxy. يسجل العميل المتوافق خدماته في الخادم ويرسل استعلامات .local إليه بأحادي الإرسال. وعندما يكون الخادم متاحاً، يتوقف العميل عادة عن المشاركة المباشرة في mDNS على الوصلة، بينما يحافظ الخادم على التوافق مع الأجهزة التي لا تعرف إلا البث المتعدد.

بعض هذا البناء معياري بالفعل. يحدد RFC 9665 بروتوكول Service Registration Protocol وفترات تسجيل الخدمات. ويحدد RFC 8766 وسيط الاكتشاف الذي يجيب عن DNS أحادي الإرسال بمعلومات تعلمها من وصلات mDNS. تضيف ULD طريقة جمع هذه العناصر في خدمة محلية واحدة، مع قواعد للإعلان والاختيار والمراقبة والانتقال.

ولا تلغي المقترحات RFC 6762، وهو أساس Multicast DNS. تقول المسودة إنها ستحدثه إن اعتمدت لاحقاً، لكنها تبقي mDNS لإعلان الخادم، والتعامل مع الأجهزة القديمة، والرجوع إليه عند غياب خادم ULD صالح. ما ينتقل هو العمل الروتيني للعميل المتوافق، لا كل البث المتعدد في الشبكة.

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

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

في IPv6 يعلن خادم البنية التحتية خياراً في RA أيضاً. يجب أن يستخدمه العميل للاكتشاف أو للتحقق من ادعاء تعلمه عبر DNS-SD حتى تتمكن RA Guard من حماية الدور. أما العميل الذي يعمل بـIPv4 فقط فيجد الخوادم عبر mDNS. وعلى الخادم التأكد من أن مصدر طلب .local عبر IPv4 ينتمي إلى شبكة فرعية متصلة مباشرة.

تتوقف المسودة قبل الإجابة عن أسئلة الثقة الأساسية. قسم Security Considerations لا يحتوي إلا على TODO، وقسم موجهات SNAC غير مكتمل، واسم الخدمة المطلوب من IANA ما زال عنصراً مؤقتاً. لا توجد في المصادر نتائج لتنفيذين مستقلين أو تشغيل بيني أو قياس زمن البث أو استهلاك البطارية أو فقد الاستعلامات أو سرعة الانتقال. وهي Internet-Draft قابلة للتغيير أو الاستبدال أو الانتهاء، وليست RFC.

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

اعتماد فريق العمل بداية لمسار عام، لا حكماً على النتيجة. لم يثبت تحسين Wi-Fi ولا نشر المنتجات ولا أمان السلطة الجديدة. ما ثبت هو أن IETF ستطور اقتراحاً لنقل جزء من الاكتشاف المحلي إلى أحادي الإرسال، وأن الاعتماد على الخادم أصبح سؤالاً يمكن اختباره بدلاً من افتراضه.

المصادر