الخلاصة

  • وصف Richard Laager في اقتراح 2026.4 إعادة تخصيص تفصيلية من شبكة يملكها إلى منظمة أخرى. مفتاح الشبكة الأم رُفض عند GET بمعرّف NET الابن، مع أنه استطاع حذف السجل وجلبه عبر mostSpecificNet بنطاق العناوين؛ مفتاح المنظمة المستقبلة نجح في القراءة بالمعرّف.
  • ردّت ARIN في 30 مارس 2026 بأن وسائل الاسترجاع الموجودة وخطط التطوير المقبلة تجعل تغيير صلاحيات API غير ضروري حينها. أُغلق الاقتراح بموافقة صاحبه.

كان يستطيع إرسال أمر حذف السجل، لكنه لم يستطع قراءته باسمه. يبدأ اقتراح ARIN رقم 2026.4 بخطوتين قدّمهما Richard Laager: أنشئ إعادة تخصيص تفصيلية من إحدى شبكاتك إلى منظمة ثانية، ثم استخدم مفتاح API المرتبط بالشبكة الأم لطلب سجل NET الابن بمعرّفه. النتيجة التي أبلغ عنها هي رفض بسبب نقص الصلاحية. وأضاف أن مفتاحه يستطيع حذف الابن، وأن إدخال أول عنوان وآخر عنوان في mostSpecificNet يعيد السجل، وأن بياناته العامة تظهر لأي شخص في Whois.

تُنشئ إعادة التخصيص التفصيلية صلتين إداريتين بسجل واحد. يوضح دليل ARIN لإدارة الموارد أن المنظمة المستقبلة تملك Org ID ويمكنها إدارة العناوين المعاد تخصيصها، بينما يحتفظ المسجّل المباشر بحق استرجاع التخصيص. وتصف ARIN إدارة كائنات IRR وDNS العكسي بأنها مشتركة بين الطرفين. لا تختفي مصلحة الشبكة الأم عند ظهور منظمة مستقبلة. لكن الواجهة تختار أي علاقة تعترف بها عند كل عملية.

في وصف Laager، يستطيع مفتاح المنظمة المستقبلة تنفيذ GET بالمعرّف. يُرفض مفتاح الأم في الطلب نفسه. ينجح مفتاح الأم حين يستخدم mostSpecificNet بنطاق العنوان. وتعرض Whois العامة المعلومات نفسها بالمعرّف أو العنوان. إذن لم تكن البيانات محجوبة عن الجمهور. الفارق في اجتماع هوية المفتاح مع الطريق المحدد للوصول إلى السجل.

تفصل وثيقة Reg-RWS بين الطرق بوضوح. يعيد GET /rest/net/NETHANDLE بيانات NET. يبحث GET /rest/net/mostSpecificNet/STARTIP/ENDIP عن أكثر NET تحديداً ضمن النطاق. يفتح DELETE /rest/net/NETHANDLE طلباً ذا تذكرة لإزالة إعادة تخصيص أو إعادة توزيع؛ ولا يمحو تخصيصاً مباشراً فوراً. ويعدل PUT /rest/net/NETHANDLE السجل بحزمة بيانات تُرسل معه. نجاح البحث بالنطاق لا يغيّر جواب الطلب بالمعرّف؛ على برنامج إدارة الموارد أن يعرف الطريقين ويقارن النتيجتين.

تظهر الكلفة في دورة المراجعة العادية. يحتفظ نظام التزويد بمعرّف NET الابن الذي عاد بعد إنشاء إعادة التخصيص. في اليوم التالي يقرأه لمقارنة حالة ARIN بخطته. إذا رُفض GET المباشر، يحتاج النظام إلى تخزين حدَّي العنوان أيضاً، وإرسال طلب آخر، والتحقق من أن النتيجة تحمل معرّف الابن والأم والمنظمة المستقبلة المقصودة. تستطيع Whois مساعدة مهندس يفحص الحالة، لكنها قناة أخرى وسجل أدلة آخر. أخطر استجابة لخطأ القراءة هي استخدام صلاحية الحذف لإعادة بناء السجل؛ تسجيل العميل ليس ورقة اختبار يمكن تمزيقها للحصول على نسخة جديدة.

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

في ردها المؤرخ 30 مارس، قالت ARIN إنها درست وسائل أخرى متاحة لاسترجاع المعلومات وخطط تطوير مستقبلية، وخلصت إلى أن تعديل فحوص الصلاحية الحالية غير لازم في ذلك الوقت. أُغلق الاقتراح بموافقة Laager. لا يعلن الرد إصلاح GET بالمعرّف؛ إنه يترك على العميل مهمة استخدام طريق آخر مع التأكد من هوية الكائن العائد.

تنقص وثائق القضية حقيقة حالية واحدة: سجلّ اتصالات إنتاج جديد بمفتاحَي المنظمتين وعلى نقاط النهاية الموثقة سيُظهر هل يستمر رفض GET بعد جواب مارس. الموجود علناً هو إعادة الإنتاج التي أبلغ عنها المستخدم وقرار ARIN الإبقاء على الفحص. ومن يدير عمليات إعادة التخصيص آلياً يحتاج منذ الآن إلى فصل «ممنوع قراءة هذا الطريق» عن «سجل NET غير موجود».

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

الاقتراح وردّ ARIN · طرق Reg-RWS · دليل إدارة الموارد · تعديلات NET