تم تبديل المفتاح الجذري في موعده؛ فكيف يثبت المشغلون أن محللاتهم تثق بالمفتاح الجديد؟

الخلاصة

• بدأ KSK-2024 توقيع منطقة جذر DNS في الموعد المحدد، 11 أكتوبر 2026. وقالت ICANN إنها لم ترصد مؤشرات على اضطراب تشغيلي واسع النطاق.
• يؤكد هذا السجل العلني تبديل التوقيع في منطقة الجذر، ولا يثبت أن كل المحللات اعتمدت المفتاح الجديد أو أن الأعطال المحلية لم تقع. وسيظل KSK-2017 نقطة ثقة صالحة إلى أن تُنفذ خطوات إلغائه وإزالته اللاحقة.

لنجاح التبديل أكثر من معنى

تسجل صفحة ICANN الخاصة بتبديل KSK واقعة محددة: في 11 أكتوبر عند 14:00 بالتوقيت العالمي، بدأ KSK-2024 توقيع منطقة الجذر. وتقول الصفحة إن مؤشرات الاضطراب التشغيلي الواسع لم تظهر حتى ذلك الوقت، وإن الرصد مستمر. كما تسجل IANA المفتاح الجديد على أنه نشط، وتقول إن KSK-2017 لم يعد يوقّع. هذه وقائع تشغيلية مهمة، لكن نطاقها يظل محدوداً بما تقوله.

لا يعني تغيير مفتاح توقيع الجذر أن كل محللة تكرارية تتحقق من DNSSEC قد قبلت المفتاح الخلف. تنشر منطقة الجذر بيانات DNS موقعة، وتتحقق المحللات التكرارية منها نيابة عن العملاء. تحتاج كل محللة إلى نقطة ثقة محلية تبدأ منها سلسلة التحقق. وإذا لم يكن لديها KSK-2024 صالح حين تحتاج إلى التحقق من حالة التوقيع الجديدة، فقد يفشل تحقق DNSSEC على تلك المحللة. ويمكن أن يتأثر عملاؤها من دون أن يعني ذلك تعطل الجذر العالمي أو DNS كله.

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

مهلة الإعداد الطويلة تراعي استقلال المحللات

نشرت IANA بيانات KSK-2024 قبل تفعيله بوقت طويل. ظهر المفتاح في منطقة الجذر في 11 يناير 2025، وكان متوقعاً أن تبدأ المحللات المتوافقة مع RFC 5011 الثقة به في 10 فبراير. منحت فترة النشر المسبق، التي قاربت عامين، تلك الأنظمة وقتاً لاكتشاف المفتاح وقبوله بينما ظل المفتاح السابق يوقّع المنطقة. وقال دليل ICANN الصادر في يوليو إن أكثر من 95% من المحللات التي أرسلت تقارير تعرّفت إلى KSK-2024 أو اعتمدته قبل التبديل. وهذا مؤشر إلى جاهزية واسعة بين الجهات المبلغة، وليس تعداداً لجميع المحللات أو نسبة نجاح بعد التبديل.

يوضح RFC 5011 لماذا يختلف «النشر» عن «الثقة». ترى المحللة التي تحدث مفاتيحها آلياً المفتاح الجديد ضمن مجموعة DNSKEY تم التحقق منها، ثم تنتظر فترة احتجاز الإضافة، وبعدها تتحقق من مجموعة لاحقة ما زالت تتضمن المفتاح قبل قبوله كنقطة ثقة. لا تقل فترة الاحتجاز عن 30 يوماً، مع مراعاة قاعدة TTL الأصلي. تنشئ كل محللة هذه الحالة محلياً بناءً على ما تراه وتحفظه. يستطيع جدول مركزي أن يتيح وقتاً كافياً للتبني، لكنه لا يثبت حالة الملفات المحلية أو إعدادات البرامج أو نجاح التحقق في أسطول موزع.

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

أكتوبر موعد تبديل التوقيع لا نهاية دورة المفتاح

لم تنته السلسلة بعد. يقول الجدول الحالي لدى IANA إن KSK-2017 توقف عن التوقيع في 11 أكتوبر 2026، لكنه ما زال نقطة ثقة صالحة. ومن المقرر نشر بت REVOKE في 11 يناير 2027، ثم إزالة المفتاح من منطقة الجذر في 22 مارس. هذان انتقالان لاحقان منفصلان ولهما سلوك محلي خاص بالمحللات. لذلك لا يصح وصف تبديل أكتوبر بأنه حذف فوري للمفتاح السابق أو نهاية كل ثقة به.

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

تطلب ICANN من مشغلي المحللات المتحققة التأكد من وجود KSK-2024، ورقم وسمه 38696، في إعداد نقطة الثقة، وتحذر من افتراض نجاح التحديث الآلي. وتحدد IANA ملف XML الموقع لنقاط الثقة مصدراً مرجعياً لمعلمات المفاتيح، وتحيل المشغلين إلى تعليمات موردي البرامج. وهكذا يوجد هدف واضح للفحص المحلي، مع بقاء أدلة الأسطول الأوسع موزعة.

ما الذي يثبته السجل العلني؟

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

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

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