الخلاصة

  • RFC 8901 وثيقة Informational ناتجة عن إجماع IETF، وليست معيار Standards Track ملزماً ولا دليلاً على أن مزوّداً مسمى يطبق DNSSEC متعدد الموقّعين.
  • في النموذجين يجب أن تضم مجموعة DNSKEY لدى كل مزوّد مفاتيح ZSK النشطة لجميع المشاركين. وإلا فقد يخزن المحلّل مفاتيح A ثم يتلقى توقيع B عند التحويل ويرفض الجواب.
  • ينسّق مالك المنطقة تبادل المفاتيح، وربط KSK بسجل DS في المنطقة الأب، والخوارزميات المشتركة، وتوقيت التدوير قبل العطل. يبقى المزوّد الثاني مساراً محتملاً إلى أن تكتمل هذه الأدلة.

بقيت الإجابة وانقطعت سلسلة التحقق

تخدم مزودتان مستقلتان منطقة واحدة وتوقعانها كل على حدة. يتبع محلّل متحقق التفويض الآمن، ويحصل من Provider A على مجموعة DNSKEY، ويوثقها عبر DS في الأب ثم يخزنها. وبينما ما زالت صالحة يتعذر الوصول إلى A، فيسأل B. يعيد B السجل المطلوب مع RRSIG أنشأه مفتاح ZSK الخاص به.

B يعمل، لكن الجواب قد لا يصلح. إذا لم تتضمن مفاتيح A المخزنة مفتاح B النشط، فلا يملك المحلّل مفتاحاً عاماً موثقاً للتحقق. قد يجرب خادماً آخر ويدفع زمناً إضافياً، أو يستنفد المحاولات، أو تنتهي مهلة العميل. لا تغيّر RFC 8901 سلوك المحلّل؛ بل تحدد الحالة العامة التي يجب أن يبنيها الموقّعون كي ينجو التحقق المعتاد من تغيير المسار.

تفصل الشبكات والعقود وسجلات NS بين مسارات سلطة محتملة. لكنها لا تثبت أن توقيع B قابل للتحقق برؤية المفاتيح القادمة من A. يكتمل التكرار فقط عندما يعبر المسار التشفيري التحويل أيضاً.

نموذجان للحيازة وثابت واحد

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

يحصل الأب على مدخل واحد ويعرض الجميع الكائن الموقّع نفسه. لكن حيازة KSK وإعادة التوقيع الدوري وصلاحيات API والتوزيع تتحول إلى سطح تحكم مشترك. نسخة قديمة عند مزوّد واحد تكفي لتقسيم الواقع.

في النموذج الثاني يملك كل مزوّد KSK وZSK مستقلين. يستورد كل واحد ZSK العامة للآخرين إلى DNSKEY ويوقعها بـKSK الخاص به. يحتوي DS في الأب سجلاً لكل KSK. تتوزع المفاتيح الخاصة، لكن الحالة العامة المتزامنة تكبر: تدوير KSK لدى A يغير مساره في الأب، وتدوير ZSK لديه يغير DNSKEY الذي يجب أن ينشره B.

التدوير معاملة موزعة

في النموذج الأول لا يبدأ A التوقيع فور إنشاء ZSK جديد. يحصل المالك عليه، ويضيفه إلى المجموعة الموحدة، ويوقعها وينشرها لدى الجميع. ينتظر التفعيل الانتشار وTTL الخاص بـDNSKEY؛ وينتظر حذف المفتاح القديم زوال اعتماد البيانات والتواقيع وTTL عليه. ويمر تدوير KSK أيضاً بنشر DS وذاكرة الأب.

في النموذج الثاني يستطيع A توقيع DNSKEY محلياً، لكنه يسلّم ZSK الجديد إلى المالك كي يستورده B. ينتظر A اكتمال الاستيراد والانتشار على جميع الخوادم وTTL قبل استخدامه في البيانات العادية. ويتبع الحذف التنسيق نفسه بالعكس.

لذلك لا تكفي عبارات «أُنشئ المفتاح» أو «أعادت API رمز 200». يسجل الإيصال السليم التصدير، وقبول المالك، والاستيراد لدى كل مزوّد، والنشر على كل سطح سلطوي، وانقضاء TTL، والتحقق المستقل من إجابات A وB، ثم التفعيل أو الإخراج.

الخوارزميات والإجابات السلبية

يستخدم المشاركون خوارزمية DNSSEC مشتركة أو المجموعة نفسها. عندما تعلن DNSKEY عدة خوارزميات تمتد متطلبات RFC 4035 إلى RRsets في المنطقة. لا تتحول خيارات غير متوافقة إلى توافق لمجرد توزيعها على شركتين.

تسافر براهين NSEC أو NSEC3 مع الإجابة السلبية، ولذلك يمكن تقنياً اختلاف الطرق. لكن مزج NSEC مع NSEC3 يهزم حماية NSEC3 من التعداد السهل، وقد يخفض الاختلاف الدائم كفاءة التخزين السلبي. تفضل RFC 8901 طريقة واحدة وتقليل الفروق التي لا يمكن تجنبها.

فحص A أو AAAA فقط لا يغطي هذا المسار. قد تنجح الإجابة الإيجابية بينما يكشف غياب اسم أو نوع عن توقيع وبرهان وذاكرة مختلفة.

ما لا تثبته الوثيقة

لا تثبت RFC 8901 دعم API أو تطبيق مزوّد أو حادثاً أو مكسب توافر أو نسبة تبنٍّ. كما لا يثبت DNSSEC التفويض التجاري أو صحة التطبيق أو تحول المرور؛ إنه يثبت علاقة تشفير محدودة للبيانات المرصودة.

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

المصادر