الخلاصة

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

لنتخيل مراسم مجدولة انتهت بلا إنذار. ظهر مفتاح DNSKEY الجديد، وأنتج الموقّع تواقيع صحيحة، وسجلت لوحة التحكم النجاح. عند الموعد حُذف المفتاح القديم. بعد قليل بدأت فئة من العملاء الذين يستخدمون محللات متحققة تتلقى SERVFAIL، بينما بقيت المجسات القريبة من خوادم DNS صاحبة السلطة سليمة.

لم يتغير التشفير فجأة. الذي حدث أن النموذج التشغيلي اختزل ساعات مختلفة في ساعة المراسم.

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

الساعة الأولى هي انتشار البيانات بين خوادم DNS صاحبة السلطة. نشر المفتاح في الخادم الرئيسي لا يضعه فوراً في كل خادم. يضم RFC 7583 زمن الانتشار إلى الفترة اللازمة قبل الجاهزية. ويطبق RFC 6781 الانضباط نفسه على النشر المسبق لـZSK: يُضاف DNSKEY الجديد، ويوزّع على مجموعة الخوادم صاحبة السلطة، ويبقى منشوراً مدة TTL الخاصة بـDNSKEY قبل استخدامه لتوقيع بيانات الإنتاج.

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

الساعة الثالثة لدى النطاق الأب. يمكن أن يبقى تدوير ZSK داخل نطاق واحد، أما تدوير KSK فيربط عادة DNSKEY في النطاق الابن بسجل DS ينشره الأب. إرسال DS إلى السجل لا يثبت أنه أصبح منشوراً في DNS. يجب رصد DS الجديد فعلياً، واحتساب TTL للسجل القديم، والحفاظ على مسار التحقق السابق حتى يثبت المسار اللاحق.

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

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

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

ولفئات RFC 5011 يضيف السجل نقطة الثقة وأول مشاهدة متحققة ونهاية الانتظار والمشاهدة اللاحقة التي تكمل القبول. ولكل الفئات يحتفظ بنتائج التحقق عبر مجموعات ممثلة من المحللات، ويسمي صاحب صلاحية الانتقال والدليل الذي يطلق الرجوع.

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

المصادر

RFC 7583 — توقيت تدوير مفاتيح DNSSEC؛ RFC 6781 — الممارسات التشغيلية لـDNSSEC؛ RFC 5011 — تحديث مراسي ثقة DNSSEC آلياً.