الخلاصة

  • يربط FCFS Naming الاسم غير المستخدم بأول مفتاح SIG(0) يقبله المسجل؛ وهو يثبت الاستمرارية مع ذلك المفتاح، لا هوية الشركة أو المالك أو سلامة التطبيق.
  • يجب أن يمتد إيصال التشغيل من القبول الشبكي واكتشاف المسجل إلى الانتشار لدى خوادم السلطة، ومشاهدة المحلل، ومصادقة الطرف، ومعاملة تطبيقية فعلية.

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

هذه ليست بقايا تنظيف بالضرورة. إنها نتيجة مقصودة في SRP: لسجلات PTR وSRV وA وAAAA وTXT مدة خدمة قصيرة نسبياً، بينما يمكن أن تبقى KEY مدة أطول بكثير. يختفي الإعلان عندما لا يتجدد، ويبقى حق الاسم كي لا يستولي عليه جهاز آخر أثناء انقطاع مؤقت.

المشكلة تبدأ عندما تختصر لوحة التحكم الحالتين في كلمة «مسجل».

ما الذي يملكه المفتاح الأول؟

يتيح Service Registration Protocol للأجهزة نشر معلومات DNS-SD من دون سر مشترك مُعدّ مسبقاً لكل جهاز. ينشئ الطالب زوج مفاتيح فريداً، يضع المفتاح العام في سجل KEY، ويوقّع DNS Update بواسطة SIG(0). إذا كان اسم المضيف أو مثيل الخدمة حراً، يقبل المسجل المطالبة. وطالما لم تنته مهلة KEY، لا يستطيع مفتاح آخر تعديل الاسم.

تثبت الآلية أن التحديث اللاحق صادر عن حامل المفتاح الذي سبق إلى الاسم. ولا تثبت أن الحامل موظف مخوّل، أو أن الجهاز ملك للمؤسسة، أو أن البرنامج أصلي، أو أن الخدمة حميدة ومتاحة.

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

معاملة ذرية لا تعني وصولاً إلى القارئ

تجمع رسالة SRP واحدة وصف مضيف واحداً بالضبط، ويمكن أن تضيف عدة أوصاف وتعليمات اكتشاف لخدماته. لا يرسل الطالب شروط RFC 2136 الصريحة؛ يطبق المسجل قواعد ضمنية لفحص بنية السجلات، وتطابق المفاتيح، وصحة SIG(0)، ووجود Update Lease، وعدم تعارض الملكية. تنجح المجموعة كلها أو تفشل كلها.

لكن نجاح الإدخال لا يثبت النشر. قد يكون المسجل hidden primary لا يجيب المستخدمين. تمر البيانات عبر journal أو توقيع منطقة أو نسخ إلى خوادم ثانوية. لذلك يجب سؤال الخوادم التي تقدم الإجابات فعلاً، لا الاكتفاء بـNoError.

حتى إجابة DNS الصحيحة لا تختبر الخدمة. SRV يحدد هدفاً ومنفذاً، وA أو AAAA يحدد عنواناً؛ أما هوية الطرف ونجاح بروتوكول التطبيق فيحتاجان اتصالاً منفصلاً ومعاملة آمنة قابلة للرصد.

ثلاث ساعات مختلفة

الساعة الأولى هي LEASE لسجلات الخدمة، وغالباً ما تكون نحو ساعتين. الثانية هي KEY-LEASE، وقد تكون نحو أربعة عشر يوماً. الثالثة هي TTL لدى المحللات المتكررة. انتهاء الأولى يجبر السلطة على وقف تقديم السجل، لكنه لا يسحب نسخة سبق أن خزنها محلل حتى ينتهي TTL المتبقي.

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

التوقيع يسير في اتجاه واحد

يستخدم المسجل SIG(0) للتحقق من الطالب. أما المواصفة الأساسية فلا تحدد للطالب آلية للتحقق من رد المسجل. يجب على المسجل توفير DNS-over-TLS، وينبغي للطالب القادر استعماله، لكن من دون تحقق فعلي للمفتاح أو الشهادة يكون ذلك خصوصية انتهازية، لا إثباتاً لهوية المسجل.

يجب أن يذكر السجل التشغيلي كيف عُثر على المسجل: إعداد يدوي، أو اكتشاف نطاق، أو معلومات قدّمتها الشبكة المقيدة؛ وهل استُخدم TLS؛ وهل جرى التحقق من النظير؛ وهل حدث تراجع إلى TCP عادي.

ولا يمنح SIG(0) وحده حق الوصول إلى بوابة التسجيل. لا تملك SRP دلالة تفويض مؤسسي غير FCFS، لذا ينبغي رفض المصادر خارج المجال الإداري. يعتمد TCP على المصافحة لمقاومة انتحال خارج المسار، مع الحذر من بيانات TCP Fast Open. ويعتمد UDP في الشبكات المقيدة على تصفية المصدر وواجهة الدخول.

حدود النطاق هي حدود السلطة

إذا فُتحت SRP على نطاق المؤسسة الرئيسي، يستطيع طالب تلقائي المطالبة بأسماء مثل www أو mail أو smtp. الحل العملي هو نطاق فرعي مخصص للاكتشاف وقائمة أسماء ممنوعة. كما ينبغي عزل تحديثات DNS التقليدية؛ فبيانات اعتماد أخرى قد تستبدل سجلات وعد بها المسجل للمفتاح الأول.

أما service.arpa. فهو نطاق محلي الخدمة وليس ختم ثقة عالمياً. قد يفشل جهاز يستخدم محللاً خارجياً في رؤية الإجابة المحلية الصحيحة. ولا يمكن للاسم المحلي أن يحل محل مصادقة PKI العالمية. كذلك قد يصبح نشر KEY معرّفاً ثابتاً لتتبع المضيف؛ ويمكن إخفاؤه بشرط الحفاظ على اتساق DNSSEC.

سلسلة الدليل

يبدأ الإيصال من انضمام الشبكة وواجهة المصدر ونطاق التسجيل وطريقة اكتشاف المسجل والنقل والتحقق من TLS. ثم يحفظ بايتات التحديث، وعلاقات المضيف والخدمات، وبصمة KEY، والخوارزمية، ونتيجة SIG(0)، والتعارض، والمدد والرد.

بعد ذلك يربط journal الخاص بالـhidden primary بإجابات الخوادم المقدمة للخدمة، والمشاهدة المتكررة وTTL، ثم بمصادقة الطرف ومعاملة تطبيقية. كل طبقة تقول شيئاً مختلفاً، ولذلك يمكنها كشف موضع الفشل بدقة.

المصادر