قد يؤدي أمر حذف واحد إلى تعطيل نطاق يخص طرفاً آخر: RFC 9874 والتحكم في تبعيات EPP

الخلاصة

• قد تتجاوز العلاقات بين نطاقات EPP ومضيفيها التابعين حدود العميل الواحد.
• قد يؤدي حذف كائن من دون فحص تبعياته إلى ترك نطاق بعدد غير كافٍ من خوادم الأسماء السلطوية، أو إلى فرض عدد كبير من التحديثات.
• يناقش RFC 9874 سجلات خوادم أسماء يحتفظ بها العميل عمداً لاستخدامها عند الحاجة، والفصل الصريح الذي يتبعه إرجاع وإخطار، وكذلك الاسم ذي الاستخدام الخاص sacrificial.invalid.

تبدأ المشكلة حين يُحذف كائن بينما تظل الروابط التي تعتمد عليه قائمة. يصف RFC 5731 خرائط النطاقات، ويصف RFC 5732 خرائط المضيفين، أما RFC 9874 فيتناول آثار دورة حياة هذه الكائنات حين تتشابك علاقاتها. وإذا سمح الخادم بالحذف رغم استمرار الروابط، فقد يفصل كائنات مضيف عن نطاقات يرعاها عملاء آخرون. وهذا تغيير في دورة حياة كائن EPP، لا علاقة له بانقضاء ذاكرة DNS المؤقتة، أو بانتهاء تسجيل النطاق، أو بسحب مسار BGP.

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

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

يوصي RFC 9874 بالنظر في الاحتفاظ بسجلات خوادم أسماء بديلة يديرها العميل، أو في حذف يتضمن فصل الارتباطات صراحة ثم إرجاع الحالة وإخطار الأطراف المتأثرة، أو في استخدام الاسم الخاص sacrificial.invalid. أما الأساليب الأخرى التي يستعرضها النص فلا يوصى بها بسبب آثار جانبية غير مرغوبة. وهذه توصيات واردة في الوثيقة، وليست دليلاً على تطبيق موحد لها في جميع السجلات.

يمثل امتداد EPP Change Poll إحدى الوسائل المتاحة لإبلاغ العملاء الراعيين المتأثرين عندما يجري السجل تغييرات في الارتباطات من جانبه. غير أن إرسال الإخطار لا يضمن استجابة فورية أو مناسبة للوقت. وقد يتيح إبقاء النطاق وارتباطات مضيفيه التابعين في حالة pendingDelete نافذة قابلة للإرجاع خلال فترة الاسترداد، قبل التطهير النهائي. لكن ذلك لا يجعل كل عملية بين عملاء مختلفة قابلة للإرجاع الكامل بأي حجم؛ فقد تتطلب مجموعات الارتباطات الكبيرة معالجة غير متزامنة.

يمكن لـ DNSSEC ووجود عدة كائنات مضيفة سلطوية أن يخففا بعض المخاطر، لكن RFC 9874 لا يقدمهما بديلاً عن أسلوب حذف يراعي التبعيات. كما أن DNSSEC لا يمنع كل انقطاع أو كل استيلاء مرتبط بعمليات الحذف.

المصادر

• RFC 3915 — الاسترداد ودورة الحذف المعلّق.
• RFC 5730 — إطار EPP.
• RFC 5731 — خريطة النطاق.
• RFC 5732 — خريطة المضيف.
• RFC 8590 — EPP Change Poll.
• RFC 9874 — أفضل ممارسات الحذف.