الخلاصة

  • واقعة ‎.de في مساء 5 مايو 2026 أظهرت أن استمرارية سجل نطاق وطني لا تقاس فقط بتعدد مواقع الخوادم أو وجود anycast أو توزيع وحدات HSM، بل بصحة الحالة الموقعة التي تشترك تلك المكونات في نشرها. إذا كان مفتاح DNSKEY المنشور لا يطابق معظم مفاتيح التوقيع الخاصة التي تنتج RRSIG، فإن البنية الواسعة تصبح وسيلة لتكرار حالة غير قابلة للتحقق.
  • السجل العام يدعم تحليلاً محدداً لا يتوسع خارج حدوده: خطأ في وكيل داخلي لتدوير ZSK أنشأ أزواج مفاتيح متميزة على عدة وحدات HSM مع وسم المفتاح نفسه 33834 وبيانات وصفية مشتركة، بينما نُشر مفتاح DNSKEY واحد فقط. لا يثبت السجل عطلاً في HSM أو Knot DNS، ولا اختراقاً، ولا اصطداماً تقليدياً في وسم المفتاح، ولا يسمح بتحويل عبارة “نحو ثلث التوقيعات كانت تتحقق” إلى نسبة للنطاقات أو المستخدمين أو حركة المرور.

إن نطاق ‎.de ليس خدمة هامشية في طرف الشبكة. هو طبقة تفويض عليا تربط أسماء ألمانية بمسارات تحقق، وسجلات NS، وحالات DS، وبنية ثقة يعتمد عليها مشغلو الشبكات، والبريد، والويب، والتطبيقات المؤسسية. في النظام العادي، لا يرى المستخدم هذه الطبقة إلا عندما تتوقف. أما في مساء 5 مايو 2026، فقد أصبح سجل ‎.de نفسه موضوع اختبار عام: هل يستطيع سجل يستخدم بنية موزعة، ومراكز بيانات منفصلة، وخدمة أسماء عبر anycast، ونظام توقيع حديث، أن يمنع نشر حالة DNSSEC غير صالحة؟ وهل تكفي المراقبة إذا كانت تعرف بوجود الخلل ولا تحوّله إلى إيقاف نشر أو رجوع موثوق؟

التسلسل الزمني يجب أن يبدأ من التمييز بين طبقات الرصد. DENIC وضعت في إشعارها المحسوم بداية الأثر الملحوظ عند الساعة 21:57 في 5 مايو 2026، وذكرت أن توزيع منطقة صحيحة بدأ عند الساعة 00:08 في 6 مايو، وأن استعادة حالة التشغيل السابقة اكتملت عند الساعة 01:15. هذا هو خط DENIC التشغيلي الرسمي للواقعة. في المقابل، نشرت Cloudflare ملاحظة من طبقة محلل تكراري ترى فشل التحقق من موقعها هي وفي توقيت رصدها هي. لا يصح دمج الساعتين في وقت عالمي واحد لبداية عطل عام. ولا يصح تحويل رصد محلل تكراري كبير إلى بيان بأن كل مستخدم في كل شبكة بدأ يعاني في اللحظة نفسها.

طبقة السجل تصف توليد المنطقة وتوزيعها واستعادتها؛ طبقة المحللات التكرارية تصف ما رأته شبكات بعينها عند محاولة التحقق من تلك المنطقة.

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

جوهر الخلل كان في حالة التوقيع، لا في اختفاء الخوادم. وفق تقرير DENIC النهائي، وقع الحادث أثناء تدوير روتيني لمفتاح توقيع المنطقة ZSK. كان نظام التوقيع من الجيل الثالث قد دخل الخدمة في أبريل 2026، وجمع بين Knot DNS، ومكوّنات داخلية، وعدة وحدات HSM موزعة عبر مركزين منفصلين جغرافياً وشبكياً. الدور المتوقع لوكيل التدوير الداخلي كان إنشاء زوج مفتاح واحد وتحميله إلى كل وحدة HSM مع الحفاظ على علاقة واحدة بين المفتاح العام المنشور والمفاتيح الخاصة المستخدمة في إنتاج التوقيعات. ما حدث، حسب DENIC، أن الوكيل أنشأ زوج مفتاح مختلفاً لكل HSM متصلة، مع منح هذه المفاتيح وسم المفتاح نفسه 33834 والبيانات الوصفية نفسها.

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

لذلك لا تكفي مراجعة ملف المنطقة النهائي وحده لفهم فئة الخلل. الدليل الحاسم يجب أن يربط كل مسار توقيع بحالة مفتاحه: أي DNSKEY منشور، أي مفتاح خاص مستخدم داخل HSM، أي RRSIG ناتج، وأي نتيجة تحقق مستقلة لذلك الناتج. إذا بقيت هذه العلاقات ضمن وصف منطقي عام، يمكن للنظام أن يبدو موحداً لأن الوسم والبيانات الوصفية واحدة، بينما تكون المادة المشفرة مختلفة. أما إذا حُفظت كأدلة حالة لكل HSM، فإن التناقض يظهر قبل أن يصبح جواباً عاماً للمحللات.

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

تقول DENIC إن نحو ثلث التوقيعات كان يتحقق عملياً. هذه عبارة عن علاقة في مخرجات التوقيع، وليست قياساً لحصة النطاقات العاملة، أو المستخدمين المتأثرين، أو الاستعلامات الفاشلة، أو التوافر النهائي. إذا كانت واحدة من ثلاث وحدات HSM تنتج توقيعات مطابقة للمفتاح المنشور، فهذا يصف مصدر التوقيع. لكنه لا يخبرنا وحده كيف توزعت الاستعلامات على المحللات، وما الذي كان مخزناً في الذاكرة المؤقتة، وأين استخدمت خدمة serve-stale، وأي سجلات تغيّرت أو أُعيد توقيعها في لحظة معينة. بل إن DENIC أشارت إلى أن سجل SOA تغيّر وأعيد توقيعه مع استمرار تحديثات المنطقة، ما يعني أن صلاحية التحقق يمكن أن تتغير مع الوقت.

لذلك يكون الاستنتاج الدقيق هو أن حالة التوقيع كانت غير متسقة، لا أن ثلث الإنترنت بقي يعمل وثلثيه توقفا.

تأثير NSEC3 يوضح لماذا امتد الخلل إلى نطاقات فرعية لا تستخدم DNSSEC بذاتها. في طبقة TLD، لا يقتصر التحقق على سجلات DNSKEY أو DS المباشرة. عندما يحتاج المحلل إلى إثبات أن نطاقاً فرعياً غير موقّع لا يملك سجل DS، يستخدم السجل الأعلى أدلة إنكار موثقة، ومن بينها NSEC3 في بنية ‎.de. إذا كانت التوقيعات فوق سجلات NSEC3 غير صالحة، فإن إثبات عدم وجود DS يصبح هو نفسه غير موثوق. وعندها قد يصنف المحلل المتحقق معلومات التفويض بأنها bogus حتى لو كان النطاق الفرعي غير موقّع. هذه النقطة حاسمة لأنها تنفي التفسير البسيط القائل إن المتأثرين هم فقط أصحاب النطاقات الذين اختاروا DNSSEC.

في سلسلة الثقة، قد يفشل التفويض غير الموقع عندما لا يستطيع السجل الأعلى إثبات حالته بطريقة صالحة.

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

استخدمت Cloudflare في طبقتها الخاصة آليتين تستحقان الفصل. الأولى هي serve-stale، أي الاستمرار المؤقت في تقديم بيانات قديمة عندما لا يمكن الحصول على جواب جديد موثوق، وفق قيود تشغيلية وزمنية. هذه الآلية يمكن أن تخفف الأثر لبعض المستخدمين إذا كانت لدى المحلل ذاكرة مؤقتة صالحة من قبل. لكنها لا تصلح كل المسارات، ولا تعني أن الحالة الجديدة سليمة. الثانية هي Negative Trust Anchor مؤقت لـ ‎.de بعد تأكيد أن المشكلة في التوقيع الموثوق عند المصدر. NTA، كما تصفه الممارسة القياسية، استثناء محلي ومؤقت يجعل المحلل يعامل منطقة مكسورة كما لو أنها غير موقعة إلى حين انتهاء الاستثناء أو عودة التحقق.

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

حدود هذه التخفيفات recursive مهمة للمساءلة. مشغل المحلل لا يستطيع إصلاح DNSKEY المنشور في السجل، ولا يستطيع جعل توقيع صادر من مفتاح خاص غير مطابق توقيعاً صحيحاً. يستطيع فقط أن يختار، ضمن حد مؤقت ومحلي، كيف يوازن بين الإغلاق الآمن واستمرار الخدمة لمستخدميه عندما يصبح مصدر الثقة نفسه مكسوراً. لذلك يجب ألا تتحول NTA أو serve-stale إلى دليل على أن السجل أدى واجبه لأن بعض المسارات واصلت العمل. كما يجب ألا تتحول إلى لوم للمحللات المتحققة لأنها طبقت قواعد التحقق. السجل يملك الحالة الأصلية؛ المحلل يملك سياسة تخفيف على الحافة التكرارية. الخلط بينهما يخفي موقع الخلل ويجعل التخفيف يبدو علاجاً بنيوياً.

يجب أيضاً تثبيت حدود المسؤولية التقنية للمكونات. DENIC قالت إنها استبعدت الاختراق، وعطل Knot DNS، وعطل HSM. السجل العام لا يدعم افتراض أن أحداً اخترق النظام أو أن وحدة HSM أساءت توليد المفاتيح أو أن برنامج Knot DNS هو سبب الخلل. السبب المنشور هو خطأ في وكيل تدوير داخلي ضمن منظومة التوقيع. هذا لا يخفف خطورة الواقعة، لكنه يوجه المساءلة إلى تصميم النظام حول الوكيل: كيف اختبر؟ كيف تحقق من اتساق المفاتيح عبر عدة HSM؟ كيف سمح بنشر DNSKEY واحد بينما كانت مخرجات التوقيع تأتي من حالات خاصة مختلفة؟ وكيف مرّت البيانات رغم أن أدوات تحقق رأت أن توقيعات مفقودة أو غير قابلة للتحقق؟

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

من زاوية المساءلة، يجب أن يتغير تعريف “الاختبار المكافئ”. لا يكفي أن تمر أوامر التدوير في المختبر. يجب أن تمر الحالة الناتجة: مفتاح عام واحد، مفاتيح خاصة مطابقة عبر كل HSM المصرح لها، توقيعات RRSIG قابلة للتحقق من كل مسار توقيع، سجلات NSEC3 قابلة للتحقق في حالات وجود DS وعدم وجوده، وسجل SOA وتسلسلات المنطقة تحت تحديثات متتابعة. ويجب أن ينطبق ذلك على عدد وحدات HSM، وتوزيعها، وتوازيها، ومسارات الاختيار بينها، وأسلوب نشر المنطقة إلى خوادم الأسماء. إذا كان النظام الفعلي يوقع عبر عدة وحدات في موقعين، فاختبار HSM واحدة هو اختبار وظيفي محدود، لا اختبار تطابق لحالة السجل.

وهذا يجعل “المنطقة المرشحة” كائناً رقابياً مستقلاً لا مجرد نتيجة بناء. قبل النشر، يجب أن تُقرأ كما سيقرأها محلل متحقق: هل يطابق DNSKEY كل توقيع حاسم؟ هل يثبت NSEC3 حالات عدم وجود DS؟ هل تبقى النتائج صالحة عند تغيّر SOA وتتابع تحديثات المنطقة؟ هل تختلف الإجابة إذا جاء التوقيع من مسار HSM مختلف؟ إذا كان الاختبار يكتفي بأن الوكيل نفذ أمر التدوير، فإنه يفحص النية التشغيلية. أما اختبار المنطقة المرشحة فيفحص الحقيقة التي ستخرج إلى الشبكة. في حادثة كهذه، الحقيقة الأخيرة هي التي حددت الأثر، لأنها كانت المادة التي تلقاها المحللون، لا الوصف الداخلي لما كان النظام يقصد فعله.

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

هذه الواقعة تجعل “حق إيقاف النشر” سؤالاً مركزياً. من يستطيع أن يقول إن منطقة ‎.de الموقعة لا تخرج إلى الخدمة عندما تفشل مجموعة تحقق مستقلة؟ هل يمكن لأداة تحقق كاملة السلسلة أن تمنع توزيع منطقة جديدة تلقائياً، أم أنها ترسل تنبيهاً فقط؟ من يقر باستلام تنبيه DNSSEC حرج خلال دقائق؟ وما هو المسار إذا لم يقر أحد؟ هل يوجد تحول سريع إلى منطقة موقعة معروفة الصلاحية؟ وما الذي يثبت أن المنطقة المعروفة الصلاحية لم تعد تحتوي على المفتاح المعيب نفسه أو توقيعات من HSM غير مطابقة؟ في السجلات العليا، لا ينبغي أن يكون الرجوع مجرد نسخ ملف سابق؛ يجب أن يكون استعادة حالة مشفرة يمكن التحقق منها خارج مسار الخطأ.

التعافي المنشور يبين أن DENIC بدأت توزيع منطقة صحيحة عند 00:08، ثم استعادت حالة التشغيل السابقة عند 01:15. هذا يعطي إطاراً عاماً للرجوع، لكنه لا ينشر تفاصيل كافية عن قرار الرجوع، ولا عن مخرجات التحقق في اللحظة، ولا عن كل مسار توزيع. لذلك من المنصف القول إن الخدمة استعادت حالتها السابقة وفق DENIC، لا أن كل مستخدم في كل شبكة استعاد الوصول في اللحظة نفسها. المحللات التكرارية والذاكرات المؤقتة وسلوك NTA وserve-stale كلها طبقات قد تمدد الأثر أو تقلله حسب الشبكة. التقرير العام لا يكفي لبناء خريطة دقيقة لكل نطاق أو مزود أو تطبيق.

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