الخلاصة

  • يطلب تعليق قُدّم في 16 أكتوبر من ICANN مواءمة تقييم أتمتة سجلات DS في DNSSEC مع RFC 10026، وهو التوجيه التشغيلي الذي نشره IETF.
  • يقول تقرير يونيو في موضع إن الأتمتة ينبغي أن تتوقف عند وجود قفل تحديث على مستوى السجل، لكنه يذكر لاحقاً أن الأتمتة التي ينفذها السجل يمكن أن تستمر. أما المتطلب الإلزامي HR-4 فيتناول صراحةً قفل المسجّل فقط.
  • ستدرس ICANN التعليقات وقد تحدّث التقييم. تنتهي فترة إبداء الآراء في 23 نوفمبر، ويُنتظر تقريرها في 7 ديسمبر؛ ولم يصدر قرار نهائي أو نص تعاقدي بعد.

لا يدور السؤال حول جدوى أتمتة DNSSEC، بل حول الجهة التي يقيدها قفل حالة التسجيل عند تغيير سجل DS في النطاق الأب. وقد أثارت Quynh Nguyen هذه النقطة في تعليقها على تقييم ICANN للأمن والاستقرار في أتمتة سجلات DS، المقدم في 16 أكتوبر.

ترى Nguyen أن التقييم يعالج المخاوف الرئيسية، لكنها تطلب موقفاً واحداً متسقاً بشأن serverUpdateProhibited. وتقول إنها تقدمت بالتعليق بصفتها الشخصية؛ لذلك لا يمثل حكماً صادراً عن ICANN ولا توافقاً مجتمعياً. ومع ذلك، فقد يؤثر تفسير القفل في مسار Fast-Track RSEP الذي تعتزم ICANN إتاحته لمشغلي السجلات الراغبين في أتمتة صيانة DS. وتقول المنظمة إن التقييم سيشكل أساسه التقني.

يحمل تقرير Interisle Consulting Group تاريخ 23 يونيو 2026. وتتخذ الفقرة 4.4 موقفاً مفاده أن صيانة DS آلياً يجب أن تتوقف عند تفعيل serverUpdateProhibited. وتشير الفقرة إلى أن مسودة IETF التي استندت إليها آنذاك اتخذت الموقف المقابل للأتمتة التي يقودها السجل: فالحالة تلزم خادم EPP برفض طلبات التحديث القادمة من المسجّل، لكنها لا تمنع السجل نفسه من إجراء التغيير.

تحولت تلك المسودة إلى RFC 10026، التي نُشرت في يوليو بوصفها أفضل ممارسة حالية BCP 246. وتنص الفقرة 6.1(2) على أن أتمتة صيانة DS التي ينفذها السجل يجب ألا تتوقف لمجرد وجود serverUpdateProhibited. وتوضح الفقرة 6.2.1 الفرق بين الصلاحيات: فالقفل يوقف طلبات التحديث التي يرسلها المسجّل عبر EPP، ولا يوقف أتمتة السجل؛ كما أن إخطار المسجّل يساعده على ملاحظة التغيير.

ويظهر تعارض داخل التقييم نفسه. فالفقرة 4.7 تقول إن النشر يمكن أن يستمر عند وجود clientUpdateProhibited أو serverUpdateProhibited، وتعيد الفقرة 6.1 هذا المعنى عندما يستطيع المسجّل استبعاد النطاقات من أتمتة السجل. لكن HR-4 لا يذكر صراحةً سوى أنه لا يجوز إيقاف الأتمتة استناداً إلى clientUpdateProhibited وحده. لذلك تطلب Nguyen قاعدة واضحة ومتوافقة مع RFC 10026.

وثمة مرجع زمني آخر: ففي 31 أغسطس، نشر فريق الأمن والاستقرار الاستشاري SAC126v2، موضحاً أنه حدّث مشورته لتتوافق مع RFC 10026. وقال إن المعيار حسم السؤال الذي تناولته الفقرة 4.4 من النسخة السابقة، وإن SAC126v1 أُحيلت إلى التقاعد. وعليه، يسبق تقييم يونيو كلاً من RFC النهائية والمشورة المحدثة.

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

وتفيد صفحة الإجراء لدى ICANN بأنها ستنشر ملخصاً للتعليقات، وتنظر فيها، وقد تحدّث التقييم ثم تصدر ملحقاً. ينتهي استقبال الآراء في 23 نوفمبر 2026، ويُستحق التقرير في 7 ديسمبر. وستُطرح مسودة نص التعديل التعاقدي لمسار Fast-Track في إجراء لاحق. لا يجيز التقييم ولا هذا التعليق نشر الخدمة أو يحسم نصوص العقود المقبلة.

المصادر