الخلاصة

  • تتناول draft-ietf-dnsop-dnssec-keyrestore-02 حالة محددة: مفتاح خاص غير قابل للتشغيل بلا نسخة احتياطية صالحة، مع بقاء نسخة كاملة موقّعة مسبقاً من المنطقة وتوقيعات لم تنته صلاحيتها.
  • يعتمد الاسترداد الآمن على ساعات منفصلة لانتهاء RRSIG، وانتشار DNSKEY، ونشر DS في الأب، وتحميل الخوادم الثانوية، وانقضاء الذاكرات المؤقتة. لا يملك الموقّع هذه الساعات كلها.
  • ينبغي حفظ إيصال لساعات الاسترداد يربط كل انتقال بصاحبه وحسابه ودليله. هذا اقتراح حوكمة من Daniel Kade، وليس مطلباً من IETF.

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

نُشرت المراجعة 02 من DNSSEC Key Restore في 10 أغسطس 2026. وهي Internet-Draft نشطة ضمن مجموعة DNSOP، ويصف النص المعروض مقصدها بأنه Informational. لا تزال عملاً جارياً قد يتغير أو يُستبدل أو تنتهي صلاحيته؛ ليست RFC ولا BCP ولا التزام خدمة من RIPE NCC التي ينتمي إليها المؤلفان. يقتصر نطاقها على المناطق الموقعة مسبقاً، ويستبعد التوقيع الفوري ومنطقة الجذر.

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

منطقة سليمة ظاهرياً لكنها مجمدة

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

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

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

فقدان ZSK يربط الاسترداد بانتشار الطفل

إذا تعطلت ZSK وظلت KSK تعمل، يمكن إدخال ZSK جديدة في مجموعة DNSKEY وتوقيع المجموعة بالمفتاح العامل. ظهور المفتاح في الخادم الأساسي لا يجعله جاهزاً. يجب انتظار انتشار الخوادم الموثوقة وTTL الخاص بـDNSKEY: Ipub = Dprp + TTLkey.

بعد ذلك تبدأ المنطقة استخدام ZSK الجديدة. تبقى القديمة حتى يكتمل التوقيع والانتشار وتخرج RRSIG القديمة من الذاكرات. تعطي المسودة فترة الاعتزال بصيغة Iret = Dsgn + Dprp + TTLsig. العطل والنشر والجاهزية والتفعيل والإزالة الآمنة أحداث مستقلة.

تشير محاضر IETF 126 إلى أن فقدان ZSK وحدها لا يقطع الاستمرارية فوراً. لكن بقاء التحقق لا يعني بقاء القدرة على تعديل المنطقة. قد تستمر الإجابات القديمة فيما تتوقف كل كتابة جديدة.

فقدان KSK يُدخل الأب في المسار الحرج

تحتاج KSK البديلة إلى DS جديد في منطقة الأب. تبدأ طريقة Double-DS بإرسال DS، ثم انتظار التسجيل والنشر، ثم الانتشار وانقضاء TTL، وبعدها فقط تُفعّل KSK الجديدة في الطفل.

زمن النشر هو Tpub = Tsbm + Dreg، وتضيف الجاهزية IpubP = DprpP + TTLds. يوضح RFC 7583 أن أوقات KSK المرتبطة بالأب ليست تحت سيطرة مدير المنطقة بالكامل. لا يستطيع تحسين محلي في الموقّع تسريع طابور الأب أو إفراغ ذاكرة محلل بعيد.

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

عندما تتعطل CSK تجتمع التبعيتان. المفتاح نفسه يربط DNSKEY بالأب ويوقّع بيانات المنطقة. يحتاج البديل إلى Double-DS وإلى إعادة وظيفة توقيع البيانات. تظل CSK والتوقيعات القديمة حتى تنتهي مدة تشمل التوقيع وانتشار الطفل وأكبر TTL بين DNSKEY وRRSIG.

توقف الأتمتة يكشف سلطة الإجراء اليدوي

في الظروف الطبيعية تسمح CDS وCDNSKEY بأتمتة صيانة DS عند الأب. لكن ZSK أو CSK غير القابلة للتشغيل لا تستطيع توقيع السجلات الجديدة التي تطلب التغيير. لذلك تعيد المراجعة 02 المسار المتأثر إلى تحديث يدوي لدى الأب.

الإجراء اليدوي لا يلغي الإثبات. قد يملك مزود DNS حساب التشغيل، والمسجل علاقة العميل، والسجل أو مشغل الأب حق النشر النهائي. يجب توثيق من يمثل الطفل، ومن تحقق من المفتاح، ومن أجاز تجاوز الأتمتة، ومن راقب النشر الحقيقي.

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

كما أن تغيير DNSKEY يبطل ملخص ZONEMD السابق. يجب إنشاء ملخص جديد وتوقيعه. تذكر فقرة التنفيذ الخاصة بـKnot DNS أن الإجراء المجرب لا يدعم إنشاء الملخص الجديد يدوياً. هذه حدود لتنفيذ واحد، وليست نتيجة مقارنة شاملة.

في IETF 126 طلب المشاركون تفصيلاً أكبر للعلاقة بين TTL وانتهاء التوقيع، ودليلاً على التنفيذ في برامج التوقيع. أفاد العارض بأن الطريقة تعمل مع Knot DNS، وطلب الرئيس إضافة قسم تنفيذ. هذا يثبت تجربة محدودة ولا يثبت توافقاً متعدد الموردين.

إيصال لا يختزل المراحل في كلمة «تعافى»

يبدأ إيصال ساعات الاسترداد بتصنيف الحادث ودور المفتاح والخوارزمية، ثم يحسب أقرب انتهاء فعلي للتوقيعات المخدومة. يسجل بقاء DNSKEY وRRSIG القديمين، وظهور المفتاح الجديد في كل خادم موثوق، وقيم الانتشار وTTL التي اعتمد عليها القرار.

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

كما يفصل اكتمال التوقيع الجديد عن اختبار عينة من RRsets، وعن أول وقت آمن لاعتزال DNSKEY وDS وRRSIG القديمة، وعن الإزالة الفعلية. لكل خطوة يدوية مالك قرار ومسار تصحيح.

لا يتطلب ذلك نشر أسرار. تبقى المفاتيح الخاصة وإعدادات HSM والبيانات الشخصية محمية. تكفي بصمات المواد وkey tags والأوقات وإصدارات السياسات والسجلات المرصودة والأدوار المؤسسية لبناء تسلسل قابل للمراجعة.

ولا يمكن الادعاء برؤية كل ذاكرة مؤقتة. توفر TTL حدوداً محافظة، وتوفر القياسات من مواقع متعددة عينات. إبقاء قيم Dprp وTTLkey وTTLds وTTLsig وDsgn يجعل القرار قابلاً للفحص. إشارة خضراء بلا مدخلات لا تفعل ذلك.

تقدم المسودة طريقاً تقنياً معقولاً لاستغلال التوقيعات الباقية من دون جعل المنطقة عمداً غير آمنة أو bogus. لكنها لا تقدم SLA عالمياً ولا وعداً من الأب ولا تعداداً لكل المحللات ولا نموذج تدقيق. الدرس المؤسسي هو أن صلاحية التوقيعات الباقية ميزانية زمنية مشتركة. لا يصبح الاسترداد مسؤولاً إلا حين يرتبط كل توقيت بالجهة القادرة على تحريكه وبالدليل الذي تسلمه للمرحلة التالية.

المصادر

  1. DNSSEC Key Restore — المراجعة 02
  2. سجل الوثيقة في Datatracker
  3. تاريخ الوثيقة
  4. محاضر DNSOP في IETF 126
  5. وثائق DNSOP النشطة
  6. ميثاق DNSOP
  7. RFC 9364: امتدادات أمن DNS
  8. RFC 7583: توقيت تدوير مفاتيح DNSSEC
  9. RFC 8078: إدارة DS بواسطة CDS/CDNSKEY
  10. RFC 8976: ملخص مناطق DNS
  11. RFC 9499: مصطلحات DNS