أتمتة DNSSEC: على ICANN توضيح أثر أقفال التسجيل

الخلاصة

• تسأل ICANN ما إذا كان تقييم أتمتة سجلات DNSSEC DS يحدد المخاطر ويقترح تدابير كافية ومتناسبة وقابلة للتنفيذ.
• يتوقف الاستنتاج الإيجابي على سبعة متطلبات إلزامية وسبعة إفصاحات يقدمها كل مشغّل؛ ولا يمثل موافقة عامة على أي تنفيذ.

أثر أقفال التسجيل هو المسألة التي ينبغي أن تحسمها ICANN قبل تسريع مسار أتمتة DNSSEC. إشعار المشاورة العامة يحدد الموعد النهائي ونطاق المراجعة.

يتناول التقرير، المؤرخ 23 يونيو، ترتيباً محدداً: ينشر مشغّل DNS للنطاق الابن سجلات CDS أو CDNSKEY، ثم يتحقق الوكيل الأب — وغالباً ما يكون السجل أو المسجّل — منها قبل تغيير DS في المنطقة الأب. ويغطي التقرير استمرار الصيانة والتهيئة الأولى والانتقال إلى تفويض غير موقّع. أما الإشعارات المدفوعة وواجهات API خارج النطاق وآلية CSYNC فخارج نطاقه. لذا لا يشمل الاستنتاج كل وسائل تحديث التفويض، ولا يثبت سلامة تنفيذ مشغّل بعينه. تقييم Interisle يقول إن الآلية لا تثير مشكلة أمن أو استقرار كبيرة إذا استوفت الشروط المحددة.

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

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

تغير وضع مرجع مهم بين تاريخ التقرير والنقاش الحالي. فقد صدر RFC 10026 بوصفه أفضل الممارسات الحالية لدى IETF في يوليو، بعد تاريخ التقييم. وتدرج صفحة ICANN الحالية الإجراءَ RFC 10026 ضمن مواد الدعم، فيما يحافظ متن التقييم المؤرخ في يونيو على التسلسل الزمني السابق للمسودة. يتناول RFC 10026 فحوص القبول والتقارير وأقفال التسجيل والتحديثات المتزامنة. لا يبطل ذلك تقييم يونيو، لكنه يتيح سؤالاً محدداً: هل تتوافق قائمة المتطلبات والإفصاحات مع BCP 246 المنشور، وهل ينبغي أن تثبت الطلبات المقبلة هذه الصلة بنداً بنداً؟

يظهر الاختلاف المحدد في تحليل الأقفال داخل التقرير. فهو يتبنى موقف SAC126: ينبغي لحالة serverUpdateProhibited أن توقف الأتمتة التي ينفذها السجل، بينما لا توقفها حالة clientUpdateProhibited وحدها. أما النسخة النهائية من RFC 10026 فتتخذ موقفاً معاكساً بشأن قفل السجل: لا ينبغي إيقاف أتمتة السجل بسبب هذه الحالة وحدها، إذ يستطيع السجل تجاوز الحالة التي وضعها بنفسه؛ ويظل انسحاب المسجّل من الأتمتة وسيلة التعبير عن تفضيل مخالف. وتذكر قائمة المتطلبات النهائية قفل العميل صراحة، لكنها لا تضع شرطاً موازياً لقفل السجل. وبما أن صفحة ICANN الحالية تستشهد بـRFC 10026، يمكن للمشاركين سؤالها عن القاعدة التي ستطبق على الطلبات اللاحقة والنص التعاقدي.

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

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