الخلاصة

  • تبني ARIN تفويضات DNS العكسي على مكوّنات التخصيص المباشر: في المثال الرسمي ينتج عن /23 تفويضان بحجم /24، بينما ينتج عن /16 تفويض واحد على مستوى /16.
  • يرتبط استثناء السلطة المشتركة بكتلة مزوّد الخدمة التي جاءت منها العناوين، لا بحجم ما حصل عليه العميل وحده. ولا يلغي الاستثناء إمكان تفويض منطقة فرعية داخل DNS، لكنه يجعل تنفيذ ذلك مسؤولية جهة أخرى.

من يملك التغيير الذي يحتاجه العميل؟

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

توضح وثائق DNS العكسي لدى ARIN المسألة بمثالين. يحصل تخصيص مباشر /23 على تفويضين /24 يمكن إدارة خوادم الأسماء لكل منهما بصورة منفصلة. أما تخصيص /16 فيحصل على تفويض واحد /16، وتدار خوادمه عند ذلك المستوى. زيادة عدد العناوين لا تعني، إذاً، زيادة عدد وحدات التفويض التي يمكن تعديلها مستقلة داخل السجل.

القاعدة هي إنشاء أكبر تفويض مدعوم لكل كتلة CIDR تتكون منها Direct Allocation، أي التخصيص المباشر. تدعم ARIN في IPv4 حدود /8 و/16 و/24، ويكون /24 أصغر حجم مدعوم. لا يقع /23 على أحد هذه الحدود، فتغطيه وحدتان /24؛ أما /16 فيطابق حداً مدعوماً ويمكن تمثيله بتفويض واحد.

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

ولكل عائلة عناوين حدودها. تصف ARIN تفويضات IPv6 عند حدود من أربعة بتات. أما استثناء /16 الذي تتناوله هذه القراءة فيخص IPv4؛ لا يجوز تحويله إلى قاعدة عامة عن صلاحيات العملاء في IPv6.

الاستثناء يتبع المصدر

تتيح ARIN إدارة مشتركة لـDNS العكسي بين أصحاب الموارد المباشرين وغير المباشرين المؤهلين. ويمكن للمنظمة المخوّلة الظاهرة للمنطقة المعنية أن تشارك في إدارة العناوين المفوّضة إليها. لكن الوثيقة تستثني صراحة إعادة الإسناد أو إعادة التخصيص الصادرة من كتلة /16 أو أكبر لدى مزوّد خدمة الإنترنت.

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

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

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

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

يمكن أن تكون نقطة التسليم داخل DNS

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

لهذا يستطيع مزوّد الاتصال، أو الجهة التي تشغّل DNS لحسابه، ترتيب تفويض فرعي للعميل. ويمكن لـ/24 عادي داخل /16 استخدام تفويض DNS المعتاد لمنطقة فرعية. لا يستلزم هذا تسليم حساب ARIN إلى العميل أو منحه القدرة على تعديل تفويض /16 كله.

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

أما عندما يكون النطاق أقل من 256 عنوان IPv4، فيعرض RFC 2317 ترتيباً يستخدم أسماء مفوّضة إضافية وروابط CNAME، مع الإبقاء على آلية البحث المعتادة في DNS. تبقى المنطقة الأم جزءاً من الاعتماد التشغيلي. لا يعني ذلك أن ARIN تنشئ تفويضات /25 كيفما طُلبت، ولا أن هذه الطريقة مطلوبة لكل تفويض فرعي. استدعاؤها لتفسير /24 عادي تحت /16 يخلط بين آليتين ويجعل القيد أوسع مما تقوله المصادر.

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

نطاق الاختيار هو نطاق العملية

تظهر الفكرة نفسها في توثيق عمليات Reg-RWS. كائنات التفويض تظهر وتختفي مع الشبكات المرتبطة بها، وليست عناصر تُنشأ أو تُحذف بصورة مستقلة. ويجري تعريفها باسم التفويض، لا بمعرّف NET. تتضمن الوثائق جلب التفويضات المرتبطة بشبكة NET وقراءة حالتها الحالية قبل التعديل. هذه قراءة للعمليات المنشورة، لا نتيجة اختبار صلاحيات باستخدام حساب حقيقي.

وتعرض إرشادات إدارة DNS عبر ARIN Online المناطق العكسية وخوادم الأسماء ووسوم مفاتيح DS والمنظمات ذات السلطة المشتركة. عند تغيير خوادم الأسماء، تحل القيم الجديدة محل السابقة في كل التفويضات المحددة. وصف المهمة بأنها تخص عميل /24 لا يقلص أثر اختيار أوسع في الواجهة.

تذكر الإرشادات أيضاً قيمة افتراضية مقدارها 86,400 ثانية لحقل TTL إذا تُرك فارغاً. وتتحدث عن تحديث فوري لقاعدة البيانات، بينما قد يستغرق ظهور التغيير في DNS حتى 24 ساعة. تلك إرشادات تشغيلية وليست قياساً لانقطاع أو ضماناً بأن كل الذاكرات المؤقتة تنتهي في لحظة واحدة. أهميتها هنا التمييز بين حفظ التغيير والتحقق من نتيجته ضمن النطاق المقصود.

تسمح المصادر المتاحة في 3 سبتمبر 2026 بفهم هذا النموذج، ولا تسمح بقياس انتشاره أو كلفته على العملاء. لم تشمل هذه الدراسة استعلامات DNS ميدانية أو انتقالات خدمة أو حوادث أو حالات رفض. كذلك لا يثبت سجل PTR صحيح توجيه الحزم أو ملكية العنوان أو هوية كاملة. ما يحتاج إليه المشغّل هو جواب أكثر تحديداً: من يستطيع تعديل المنطقة التي تعتمد عليها هذه العناوين، ومن يتولى الوصلة إلى المنطقة التالية؟