الخلاصة

  • بقاء منطقة موقعة مسبقاً وتوقيعات RRSIG صالحة يثبت أن حالة قديمة ما زالت قابلة للتحقق مؤقتاً؛ ولا يثبت وجود المفتاح الخاص أو قدرة النظام على توقيع التغيير التالي.
  • مسار الاستعادة يتغير بحسب الدور المفقود: النشر المسبق لزوال قدرة ZSK، وDouble-DS لفشل KSK، وDouble-DS معدّل بفترة تقاعد أطول لفشل CSK.
  • إعلان استعادة الوظيفة يحتاج سلسلة أدلة مستقلة تشمل DS عند الأب، وDNSKEY والتوقيعات عند الابن، وكل نسخة سلطوية وثانوية، وحالة SOA وNSEC/NSEC3 وZONEMD، ومحللات ذات مخازن باردة ودافئة، ثم الخدمة الفعلية.

الحادث الذي لا يبدأ بانقطاع

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

هذه هي المسألة الدقيقة التي يتناولها draft-ietf-dnsop-dnssec-keyrestore-02. وحتى التحقق في 13 سبتمبر/أيلول 2026، كان سجل IETF Datatracker يصفه بأنه Internet-Draft نشط لدى مجموعة عمل DNSOP، بالمراجعة 02، ومحدّث في 10 أغسطس/آب 2026. ليس هذا المستند RFC. مؤلفاه Florian Obser وMartin Pels، وحالته المقصودة Informational، وهو عمل قيد التطوير تنتهي صلاحيته المدرجة في 11 فبراير/شباط 2027 ما لم يُحدّث.

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

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

النافذة ليست زمناً واحداً

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

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

يساعد RFC 7583 على فهم الفرق بين حالات المفتاح: منشور، جاهز، نشط، متقاعد، ثم ميت. رؤية DNSKEY لا تجعله جاهزاً، والجاهزية لا تعني أن كل توقيع أصبح جديداً، والنشاط لا يمنح تلقائياً إذن حذف القديم. أما RFC 6781 فيشرح النشر المسبق وDouble-Signature وDouble-DS ومخاطر التخزين المؤقت. في ظرف فقدان المفتاح لا تكون هذه الخيارات متساوية؛ قدرة المفتاح الباقي تحدد المسار الممكن.

ZSK غير قابل للتشغيل: انشر أولاً ولا تغيّر المنطقة

في تصميم يفصل KSK عن ZSK، يستطيع KSK العامل توقيع DNSKEY RRset جديد، بينما يعجز ZSK القديم عن توقيع بيانات المنطقة. لذلك لا يجوز في البداية تغيير السجلات العادية. المسار القابل للاستخدام هو Pre-Publication.

عند Tpub يضاف ZSK الجديد إلى DNSKEY RRset، مع إبقاء ZSK القديم غير القابل للتشغيل وكل RRSIG التي أنشأها. لا ينبغي عادةً تغيير SOA لمجرد إدخال المفتاح. يجب مع ذلك إجبار كل خادم ثانوي وكل نسخة سلطوية على تحميل الحالة الجديدة. تبدأ بعد ذلك فترة النشر Ipub = Dprp + TTLkey، حيث يمثل Dprp وصول التغيير إلى جميع النسخ السلطوية وتمثل TTLkey قيمة TTL لمجموعة DNSKEY. لا يصبح المفتاح الجديد جاهزاً قبل Trdy = Tpub + Ipub، لأن محللاً ما قد يحتفظ حتى ذلك الحين بمجموعة DNSKEY قديمة لا تتضمنه.

بعد الجاهزية يمكن تغيير المنطقة وتوقيعها بواسطة ZSK الجديد. يمكن إزالة التوقيعات القديمة عندئذ، لكن DNSKEY الخاص بـZSK القديم يبقى خلال التقاعد. الحد الأدنى هو Iret = Dsgn + Dprp + TTLsig: زمن إنشاء التوقيع، ثم زمن انتشاره سلطوياً، ثم أكبر TTL لتوقيعات RRSIG ذات الصلة. يوجد مسار Double-Signature نظري، لكنه أبطأ للاستعادة لأن البيانات يجب أن تبقى بلا تغيير حتى انقضاء Dsgn + Dprp + max(TTLkey, TTLsig).

إذا ظهر ZSK الجديد في إجابة خادم واحد، فقد ثبتت نقطة نشر واحدة فقط. لا نعرف من ذلك أن كل backend خلف Anycast يقدمه، ولا أن الثانويات حملته، ولا أن المخازن التي تحفظ DNSKEY القديم تجاوزت TTL. هذا الفرق بين «موجود» و«جاهز» هو أول حاجز أمام استعجال التفعيل.

KSK غير قابل للتشغيل: ساعة الأب تسبق ساعة الابن

عند فقدان KSK في تصميم مفصول، لا يستطيع المفتاح القديم توقيع DNSKEY RRset متغير. لذلك لا يكفي النشر المسبق؛ المسار هو Double-DS. وإذا كان ZSK أيضاً غير قابل للتشغيل، تُستعاد وظيفة KSK أولاً من دون محاولة استعادة ZSK في اللحظة نفسها.

يُرسل DS الجديد إلى الأب عند Tsbm. قبول المسجل أو السجل لهذا الطلب يثبت الإرسال أو القبول الإداري فحسب. بعد تأخر التسجيل Dreg يظهر السجل في منطقة الأب عند Tpub. ثم لا بد من انتظار IpubP = DprpP + TTLds: زمن الانتشار على كل خوادم الأب السلطوية، متبوعاً بمرور TTL الخاص بـDS. يصبح KSK الجديد جاهزاً عند Trdy = Tpub + IpubP، وليس عندما يتلقى المشغّل رسالة نجاح من بوابة المسجل.

عند التفعيل يضاف KSK الجديد إلى DNSKEY في الابن ويوقّع المجموعة. يمكن أن يغادر KSK القديم غير القابل للتشغيل مجموعة DNSKEY في الابن، بينما يبقى ZSK. إلا أن DS القديم عند الأب يجب أن يستمر فترة Iret = DprpC + TTLkey بعد التفعيل، كي يتمكن محلل يحتفظ بمجموعة DNSKEY القديمة للابن من إكمال سلسلته. الموعد المبكر للحذف هو Trem = Tact + Iret.

وهكذا يجب أن يسجل دفتر الحادث أربعة أحداث منفصلة: إرسال DS، قبوله، رؤيته على كل خادم أب، ثم انقضاء TTL منذ آخر نشر مثبت. دمجها في خانة «تم تحديث DS» يلغي أهم معلومة زمنية في الاستعادة.

CSK غير قابل للتشغيل: تداخل أطول لأن المفتاح يؤدي دورين

يوقع CSK مجموعة DNSKEY وبيانات المنطقة معاً. إذا فشل جزؤه الخاص فلا يبقى سوى Double-DS معدّل. يُنشر DS الجديد عند الأب، ويُنتظر Dreg ثم IpubP = DprpP + TTLds. عند التفعيل يضاف CSK الجديد إلى DNSKEY ويوقعها، لكن CSK القديم وكل RRSIG اللازمة يظلان موجودين. ينبغي تفادي تغيير SOA غير الآمن وإجبار الثانويات على التحميل.

فترة التقاعد هنا Iret = Dsgn + DprpC + max(TTLkey, TTLsig). لا تُحذف معاً مادة DS القديمة عند الأب وCSK القديم والتوقيعات القديمة إلا عند Trem = Tact + Iret. ولا تستأنف تغييرات المنطقة العادية قبل ذلك. السبب هو أن مفتاحاً واحداً كان يسند مسارين: مصادقة DNSKEY وتوقيع بيانات المنطقة. لذلك يجب أن يغطي التداخل كلاً من مخازن DNSKEY ومخازن التوقيعات، إلى جانب مسار DS عند الأب.

الاتساق الجانبي هو المكان الذي تختبئ فيه الأعطال

عند استعادة ZSK أو CSK ينبغي ألا يتغير SOA فقط لإدخال DNSKEY جديد. المفتاح القديم لا يستطيع توقيع SOA المعدّل. قد تبقى إجابات الأسماء الموجودة قابلة للتحقق، بينما تصبح إجابة «غير موجود» أو «هذا النوع غير موجود» Bogus. سجلات NSEC وNSEC3 تحمل خرائط أنواع، وليس مجرد إثبات مرتب للأسماء. إضافة CDS أو CDNSKEY عند القمة تغير خريطة الأنواع وتحتاج إلى إعادة توقيع لا يقدر عليها المفتاح المفقود.

لهذا قد يفشل مسار تحديث DS الآلي نفسه في لحظة الحاجة إليه. يوضح RFC 8078 استخدام CDS/CDNSKEY لإدارة DS عند الأب، لكن إدخال سجل جديد لا يمكن التحقق منه بواسطة ZSK أو CSK المعطل لا يمنح الأب إشارة موثوقة. قد يلزم تحديث يدوي موثّق خارج هذا المسار. ويشرح RFC 10026 أهمية قرار الأب وسجل المعالجة، من دون أن يجعل القبول الإداري بديلاً عن النشر الفعلي.

كذلك يؤدي تغيير DNSKEY RRset إلى إبطال ZONEMD منشور. يجب إنشاء digest جديد لمحتوى المنطقة الجديد وتوقيعه بواسطة DNSSEC. يبين RFC 8976 أن ZONEMD وRRSIG الذي يغطيه وبناء NSEC/NSEC3 أجزاء مرتبة من حالة واحدة. تطابق ZONEMD دليل قوي على سلامة محتوى المنطقة ضمن آليته، لكنه ليس بديلاً من تحقق سلسلة DNSSEC ولا من اختبار وصول التطبيق.

أما الخوادم الثانوية فقد لا تلتقط التغيير تلقائياً لأن SOA لم يرتفع. توفر آليات NOTIFY والنقل الكامل أو المتزايد في RFC 1996 وRFC 9103 وسائل تحريك البيانات، لكنها لا تثبت أن كل خادم حمّل النسخة المقصودة. حتى تطابق SOA serial إشارة إصدار فقط، لا بصمة تشفير لكل محتوى المنطقة. المطلوب إيصال موجّه، وإيصال تحميل، ثم استعلام مباشر عن الحالة التي يخدمها كل هدف.

ما الذي تثبته كل إشارة فعلاً؟

إن الحد من الاستنتاج أهم من جمع المزيد من اللقطات. لكل مشاهدة مجال صلاحية:

  1. DNSKEY قديم مع RRSIG قديم غير منتهٍ على خادم سلطوي واحد يثبت أن ذلك الخادم يقدم حالة قديمة قابلة للفحص في تلك اللحظة. لا يثبت بقاء المفتاح الخاص أو عمل التوقيع الجديد أو تطابق بقية الخوادم.
  2. DNSKEY جديد مرئي من نقطة واحدة يثبت النشر هناك. لا يثبت اكتمال النشر السلطوي ولا خروج DNSKEY القديم من كل cache.
  3. قبول DS من جهة المسجل يثبت خطوة إدارية. لا يثبت إدراجه عند الأب، أو انتشاره إلى كل خوادمه، أو انقضاء TTLds، أو رؤيته من المحللات.
  4. RRSIG جديد يتحقق بالمفتاح الجديد يثبت علاقة RRset واحدة بتوقيع ومفتاح في زمن معين. لا يثبت إعادة توقيع كل RRset أو اتساق NSEC/NSEC3 أو ZONEMD أو صلاحية حذف المسار القديم.
  5. تطابق SOA serial يساعد في تتبع النسخة، لكنه لا يثبت تطابق المنطقة تشفيرياً.
  6. استجابة NSEC أو NSEC3 صحيحة تثبت نفي اسم أو نوع محدد من خادم محدد، لا صحة كل خرائط الأنواع في الأسطول.
  7. نتيجة Secure لدى محلل تحققي واحد تثبت مسار ذلك المحلل وحالة cache لديه في لحظة القياس. لا تثبت تقارب مخازن العالم.
  8. نجاح HTTP أو TLS أو التطبيق بعد الحل يثبت مسار خدمة واحداً. لا يثبت أن كل العملاء يتحققون من DNSSEC أو أن التقاعد أصبح آمناً.

تحدد RFC 4034 وRFC 4035 وRFC 9364 معنى المواد المشفرة وسلوك التحقق. هذه المعاني ضرورية، لكن الصفة Secure ليست مرادفاً لاستمرارية العمل؛ فهي لا ترى توجيه المرور أو صحة التطبيق أو أثر المستخدم.

بناء حجة استعادة يمكن مراجعتها

تبدأ الحجة بحفظ غير قابل للتغيير لآخر منطقة جيدة موقعة بالكامل، مع جرد DNSKEY وDS، وبدايات ونهايات RRSIG، وSOA، وNSEC أو NSEC3، وZONEMD. لا يعيد هذا الحفظ المفتاح؛ لكنه يمنع فقدان الحالة القديمة ويحدد مقدار الزمن المتبقي لكل دليل.

بعد ذلك تُقاس كل نسخة سلطوية على حدة، بما فيها backends المتاحة خلف Anycast والواجهات Unicast. يسجل القياس بقاء القديم وظهور البديل، ومحتوى DNSKEY وRRSIG، وإجابات إيجابية وسلبية. عند الأب تُفصل موافقة الطلب عن نشر DS في كل خادم وعن عبور TTL. وعند الابن تُفصل لحظات نشر المفتاح وجاهزيته وتفعيله وإعادة توقيع المجموعات وانتشارها وتقاعد القديم.

تأتي الملاحظة الخارجية من محللات مستقلة في شبكات متعددة، باستخدام cache بارد وآخر دافئ، وفي أزمنة متكررة طوال فترات التداخل والتقاعد. تشمل الأسئلة أسماء موجودة وأخرى غير موجودة، أنواعاً موجودة وأخرى غائبة، وDNSKEY وDS وأعمار RRSIG. تفريغ cache في محلل اختباري واحد يصنع تجربة نظيفة ولا يصف الإنترنت. لا يمكن تعداد كل caches عالمياً؛ لذلك يعتمد الحد المحافظ على نشر مُشاهد وقيم TTL قصوى معروفة، لا على ادعاء أن كل محلل فُحص.

وبالتوازي تُراجع إيصالات تحميل كل Secondary، واتساق SOA وسجلات النفي، وZONEMD الجديد الموقع. تستمر اختبارات التطبيق من شبكات متعددة طوال فترة التداخل لا بعد لحظة التفعيل فقط. ويوضع قرار توقف صريح عند كل حذف: لا يُزال DS أو DNSKEY أو RRSIG قديم ما دام اختبار مطلوب يعتمد عليه، أو ما دامت المدة القصوى ذات الصلة لم تنقضِ.

يذكر Internet-Draft أن الإجراءات جُرّبت باستخدام Knot DNS. غير أن المسار يتضمن خطوات يدوية، وأن توليد ZONEMD جديد يدوياً غير مدعوم في مسار التنفيذ الموصوف. هذه خبرة تنفيذية نافعة وليست إثباتاً للدعم في كل منتج. وكل تأخر انتشار غير معلوم أو أسطول سلطوي غير متجانس يزيد مساحة عدم اليقين.

لذلك تكون العبارة النهائية المنضبطة: «استُعيدت وظيفة التوقيع ضمن حدود القياس»، لا «استُعيد المفتاح». معناها أن مادة بديلة نُشرت، وعبرت فترات cache اللازمة، وفُعّلت، ووقعت الحالة المطلوبة، وظهرت على الأب والابن وكل نسخة يمكن قياسها، وظلت صالحة عبر محللات مستقلة وخدمات فعلية حتى خروج المسار القديم. المنطقة التي واصلت الإجابة بعد الفشل لم تكن برهان التعافي؛ كانت المهلة التي أتاحت جمعه.

المصادر