الخلاصة

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

يريد العميل X حذف domain1.example. ويدير أيضاً ns1.domain1.example. لكن domain2.example، الذي يرعاه العميل Y، يستخدم هذا المضيف خادم أسماء. يستطيع X تعديل كائناته، ولا يستطيع تغيير نطاق Y، وربما لا يُسمح له حتى برؤية العلاقة. الخادم في السجل هو الطرف الذي يرى الرسم كاملاً.

هذه الرؤية تمنح الخادم مسؤولية إضافية. فالاستجابة الناجحة تثبت أن الطلب قُبل وفق السياسة النافذة. ولا تثبت أن Y احتفظ بتفويض سليم، أو تسلّم إشعاراً، أو يستطيع الاستعادة، أو أن آخر مهمة خلفية انتهت.

لماذا وُضعت قيود الحذف

يوصي RFC 5731 بألا يُحذف نطاق ما دامت له مضيفات تابعة مرتبطة. ويوصي RFC 5732 بألا يُحذف مضيف ما دام مرتبطاً بكائنات أخرى. تحمي هذه القيود ثلاث صور من الاتساق.

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

وعند تعدد العملاء تظهر سلطة موزعة. يملك Y وحده تعديل نطاقه، بينما يريد X إنهاء الكائن الذي يعتمد عليه Y. لا يكفي منع X إلى الأبد، ولا يصح تحميل Y النتيجة بلا تحذير. المطلوب انتقال يمكن إثباته.

المضيف التضحيتي ليس فراغاً بلا مالك

يمكن تغيير اسم المضيف ليصبح خارجياً بالنسبة إلى النطاق المراد حذفه. ويسمى الاسم الجديد مضيفاً تضحيتياً. لكن العلاقة لا تختفي؛ بل تنتقل إلى حارس جديد.

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

كما أن وضع عناوين خدمة DNS تكرارية عامة في glue لا يجعلها موثوقة لذلك النطاق. قد تظهر SERVFAIL وتزداد إعادة الاستعلامات. وهذه ممارسة محظورة أيضاً.

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

فترة الاسترداد تفصل الأثر عن اللارجعة

يسمح التصميم الآخر بحذف صريح مع معالجة الارتباطات بنطاقات العملاء الآخرين. يستطيع الخادم عرض تفاصيل الأثر قبل التنفيذ، وطلب موافقة واعية، وإبلاغ المتأثرين عبر EPP Change Poll أو وسيلة مماثلة.

وبالاستناد إلى RFC 3915 يمكن إبقاء النطاق والمضيفات التابعة والعلاقات في حالة pendingDelete خلال فترة الاسترداد. يظهر أثر الإزالة في DNS، بينما يبقى الرسم قابلاً للإعادة. فإذا كان الأمر خاطئاً أو خبيثاً أو أوسع ضرراً من المتوقع، يمكن استخدام restore قبل انتهاء المهلة. يأتي التطهير النهائي بعدها.

ولا يوجد حد معلن لعدد العلاقات. لذلك يمكن تقسيم التعطيل وإعادة التفعيل والتطهير إلى معاملات غير متزامنة. وقت قبول الأمر ووقت انتهاء كل علاقة حقيقتان مختلفتان.

الإيصال يتبع رسم الاعتماد

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

ويسجل قسم DNS الأسماء والعناوين الموثوقة قبل التغيير وبعده، وحالة المنطقة المتوقعة والملاحظة، وظروف DNSSEC وDS، والممارسة المختارة من RFC 9874. وتحفظ كتلة القرار التحذيرات والتفاصيل والموافقة البشرية وسبب الاختيار.

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

هذا الإيصال اقتراح تشغيلي من Daniel Kade، وليس حقلاً جديداً في EPP ولا متطلباً أضافه RFC. يمكن للخصوصية أن تستبدل الأسماء بأعداد أو مراجع غير مكشوفة، لكنها لا تبرر غياب دليل الحصر والإخطار.

يعتمد DNSSEC على اتساق الأدلة

يقلل DNSSEC وتعدد الخوادم بعض المخاطر، ولا يصلحان حراسة سيئة تلقائياً. يصف RFC 9874 حالة يسيطر فيها مهاجم على خادم واحد، بينما تقبل أتمتة DS سجلات CDS/CDNSKEY من دون مقارنة كل الخوادم الموثوقة. عندها قد تدخل مادة المهاجم في DS، وقد يزيد CSYNC أثر التغيير.

لذلك يجب تسجيل ما إذا كانت الأتمتة فعالة، والخوادم التي استُعلمت، واتساق الإجابات، والسلطة التي قبلت التغيير. عبارة «DNSSEC مفعّل» تصف قدرة، ولا تثبت سلامة الانتقال.

خمس طبقات للنجاح

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

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

المصادر