الخلاصة

  • يقترح draft-ranjbar-regext-rdap-subordinate-referrals-01 رابطين اتجاهيين لاكتشاف خدمة RDAP يحددها صاحب مورد من أجل أسماء أو شبكات أو عناوين تقع تحته.
  • بيانات الخدمة التابعة يؤكدها صاحب المورد لا مشغل السجل. يحدها نطاق التبعية الصارم ورابط العودة وسقف القفزة الواحدة، ويستطيع صاحب المورد رؤية الاستعلامات التي تصل إليه.
  • يحتاج العميل إلى سجل لفاصل السلطة يبقي كائن التغطية لدى السجل، وفعل التعيين، وجواب صاحب المورد حقائق مستقلة.

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

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

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

المشكلة تظهر عندما تختفي لحظة عبور الحد.

الاتجاه إلى الأسفل لا يورث صفة السجل

تسمي المراجعة 01 العلاقة rdap-base-down عندما تشير إلى عنوان الخدمة التابعة، وrdap-base-up عندما تعود إلى عنوان خدمة السجل المغطي. الاسمان يصفان الاتجاه بين خدمتين، ولا يحولان المشغل التابع إلى سجل.

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

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

التوافق قد يخفي تبدل المتكلم

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

هذا مفيد للتوافق، لكن إعادة توجيه HTTP هادئة. تتبعها المكتبات تلقائياً، فتبدو الصفحة الأخيرة صادرة عن مصدر البداية مع أن المشغل ومسؤولية التوافر والخصوصية وقيمة الدليل تغيرت.

يعرف draft-ietf-regext-rdap-referrals-04 طلباً صريحاً لإعادة التوجيه إلى مورد RDAP مرتبط. إذا وجد رابط واحد مناسب وكان العميل مخولاً، يرسل الخادم حالة إعادة توجيه وLocation. ويتناول اختيار العلاقة والتفاوض والتخزين المؤقت وتعدد القفزات. يوفر نقل سجل كامل لاستخراج رابط، لكنه لا يحدد كيف ينسب القارئ الجواب النهائي.

صاحب المورد ناشر ومراقب معاً

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

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

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

فعل التعيين هو مفصل السلطة خارج النطاق

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

من ينشئ المؤشر أو يغيره أو يلغيه؟ هل يحق للوكيل الذي يشغل الخادم تغيير التعيين؟ متى ينشط الهدف الجديد؟ هل يلغي نقل النطاق أو مورد الأرقام الهدف القديم تلقائياً؟ ما السجل الذي يبقى بعد اختراق الحساب أو خطأ التكوين؟

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

حفظ فاصل السلطة عند الاسترجاع

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

تحفظ الطبقة الأولى مسار التمهيد، والكائن المغطي، وخدمة السجل، والعلاقة، والهدف المحدد، والفاعل وقناة التعيين، ووقت التفعيل والنطاق وآخر فحص للمطابقة. يبقى غير المتاح مجهولاً.

وتحفظ الثانية عملية العبور: مسار الطلب، إعادة توجيه عادية أو علاقة صريحة، حالة HTTP، خيار المنع، العنوان، نتيجة TLS، الوقت وعدد القفزات، وهل نُبه المستخدم إلى أن الصاحب سيرى الاستعلام.

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

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

صيغت العلاقات لتصلح أيضاً لاكتشاف RPKI المفوض أو الهجين وتحديث RWhois وSWIP. يقلل ذلك المفردات، لكن «تابع» وصف للطوبولوجيا لا للسلطة القانونية أو الجودة أو مستوى الخدمة.

المراجعة 01 مشروع فردي مؤرخ 21 يوليو 2026. يقول Datatracker إنه بلا مكانة IETF رسمية أو مسار أو حالة RFC مقصودة، بينما يذكر العنوان Standards Track. يفضل المؤلف دمجه في مشروع إحالات REGEXT. ويبلغ قسم التنفيذ عن خدمة من جهة الصاحب ويقول إن إحالة جهة السجل هي الحلقة المفقودة؛ ليس ذلك دليلاً على انتشار عام.

تستحق البيانات الفرعية طريقاً إلى القارئ. لكنها لا تستحق استعارة سلطة السجل. يمكن للمسار أن يستمر ما دام تغير المتكلم ظاهراً.

المصادر