الخلاصة

  • يعرّف RFC 9910 العلاقة rdap-down للبحث عن الأبناء المباشرين، بينما يبحث rdap-bottom عن أكثر كائنات السجل تحديدًا التي تغطي النطاق المطلوب مجتمعة.
  • أعادت لقطة ARIN لنطاق /21 تخصيصًا مباشرًا نشطًا /22 وكائنًا إداريًا /8؛ ظهر /8 لتغطية الجزء المتبقي، لا بوصفه ابنًا للنطاق /21.

درج يبدو معكوسًا

تبدو بنية الإجابة غير ممكنة للوهلة الأولى. عند طلب كائنات bottom للنطاق 149.112.152.0/21، أعادت خدمة ARIN الكائن NET-149-112-152-0-1، وهو تخصيص مباشر نشط ممثلًا بنطاق /22، ومعه NET-149-0-0-0-0، وهو كائن إداري ممثلًا بنطاق /8.

لا يمكن أن يكون /8 ابنًا أكثر تحديدًا من /21. والخدمة لا تقول ذلك. ينشأ الالتباس من قراءة كلمة bottom بمعنى «كل الأوراق الواقعة تحت هذه العقدة». يطرح RFC 9910 سؤالًا مختلفًا: ما كائنات التسجيل الأكثر تحديدًا المتاحة التي تغطي، عند جمعها، كامل قيمة مورد أرقام الإنترنت التي أرسلها العميل؟

يغطي /22 نصف النطاق /21 فقط. أما العناوين الباقية، فأكثر كائن مسجل تحديدًا متاحًا لها في هذه الإجابة هو /8. لذلك يسمح الناتج بالتداخل. فهو لا يقسم النطاق إلى أبناء منفصلين، بل يوضح أي كائنات تسجيل تكفي لتغطية السؤال كله.

النزول ليس هو التغطية من الأسفل

يكشف الاستعلام الموازي الفرق. أعاد rdap-down للنطاق /21 نفسه التخصيص /22 وحده، لأن هذه العلاقة تبحث عن الكائنات المسجلة التالية مباشرة تحت قيمة الإدخال. أما /8 فليس ابنًا مباشرًا.

يحسب rdap-bottom التغطية. فإذا غطت الكائنات الأكثر تحديدًا جزءًا فقط، قد يبقى كائن أوسع في المجموعة ليمثل العناوين المتبقية. ينص RFC 9910 على أن كائنات bottom ليست بالضرورة منفصلة، وأن النتيجة قد تتضمن كائنًا أقل تحديدًا من الاستعلام. وتشرح ARIN القاعدة نفسها: إذا لم تغط الكائنات المكتشفة كامل القيمة، يُعاد أيضًا كائن الشبكة الأكثر تحديدًا الذي يغطي الباقي.

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

ما تحمله الإجابة فعلًا

تعرف العناصر نفسها بوصفها كائنات ip network. وهي تحمل المعرّفات، وعناوين البداية والنهاية، وتمثيل CIDR، والنوع الخاص بنموذج ARIN، والحالة. في اللقطة كان /22 من نوع DIRECT ALLOCATION وحالته active، بينما كانت حالة /8 هي administrative.

هذه خصائص سجلية. لا تثبت إعلان BGP أو إمكانية الوصول أو مرور الحركة أو تصريح ROA. كانت مصفوفتا ASN الاختياريتان فارغتين في الكائنين، لكن الفراغ لا يثبت عدم وجود مسار؛ إنه حالة حقل واحد في إجابة واحدة ووقت واحد.

يعرّف RFC 9083 كائن شبكة IP باعتباره معلومات تسجيل، ويشرح RFC 9082 أن بحث IP العادي يستهدف أكثر شبكة مسجلة تحديدًا تحتوي قيمة الاستعلام كاملة. لا يحول أي منهما هندسة السجل إلى حالة تشغيلية.

إبقاء العلاقة مع البيانات

يجب أن يحتفظ السجل القابل للمراجعة بنوع العلاقة، والنطاق المدخل، ووقت الاسترجاع، ومعرّف كل نتيجة وحدودها وCIDR ونوعها وحالتها. عندئذ يصبح /8 مفهومًا: هو غطاء التسجيل للجزء الذي لا يغطيه /22.

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

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

المصادر