الخلاصة

  • جعل RFC 9904 سجلات IANA المصدر القانوني لتوصيات منفصلة بشأن الاستخدام والتنفيذ في التوقيع والتفويض والتحقق ضمن DNSSEC.
  • منع RFC 9905 إنشاء مواد DNSKEY وRRSIG وDS جديدة قائمة على SHA-1، لكنه أبقى دعم التحقق. لذلك لا تثبت موافقة حالة السجل أن المنطقة أكملت انتقالها؛ بل تفتتح سجل العمل التشغيلي.

ظهر بجوار RSASHA1 في خانة الاستخدام للتوقيع الحكم MUST NOT. ومع ذلك، كانت منطقة حية ما تزال تقدم DNSKEY وتوقيعات تعتمد SHA-1، وكان الأب يحتفظ بمادة التفويض القديمة. لم يتناقض شيئان صحيحان: لقد تغير قرار التنسيق، فيما بقيت المنظومة الموزعة داخل تسلسل انتقال تملكه جهات متعددة.

نقل RFC 9904، المنشور في نوفمبر/تشرين الثاني 2025، توصيات خوارزميات DNSSEC التي كان يجمعها RFC 8624 إلى سجلات IANA. يثبت سجل RFC Editor وضع الوثيقة وعلاقتها بالنصوص الأسبق، ومنها RFC 9157. لم يغير RFC 9904 درجات التوصية الموروثة دفعة واحدة؛ بل غيّر الموضع الذي تُسجل فيه القرارات اللاحقة بوصفها مرجعاً قانونياً.

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

جاء RFC 9905 ليشغّل هذه البنية. لا يجوز استخدام RSASHA1 أو RSASHA1-NSEC3-SHA1 لإنشاء DNSKEY أو RRSIG أو DS جديد. في المقابل، يجب أن تواصل تطبيقات المحللات المتحققة دعم خوارزميات التوقيع تلك خلال انحسارها. الرسالة التشغيلية دقيقة: لا تُنشئ اعتماداً جديداً، ولا تسحب قدرة التحقق قبل أن تغادر المناطق المتبقية.

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

كما يجب تسمية نتيجة التحقق بدقة. يضع RFC 9364 DNSSEC داخل عائلة أوسع من ممارسات توثيق المصدر، ويميز RFC 4035 بين secure وinsecure وbogus وindeterminate. يحدد RFC 9905 معاملة insecure في حالات SHA-1 محددة حين لا ينجح بديل مقبول في توثيق التفويض أو الاستجابة. ولا يقول إن كل منطقة يظهر فيها SHA-1 هي bogus أو غير متاحة.

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

إغلاق العمل بصورة قابلة للدفاع يحتاج سلسلة إيصالات: لقطة سجل IANA ووثيقة RFC المخولة، إصدار برنامج الموقّع وإعداده، الرقم التسلسلي للمنطقة، مجموعات DNSKEY/RRSIG/DS الدقيقة، إيصال معاملة الأب، رصداً مخولاً من نقاط مستقلة، نوافذ TTL، إصدارات المحللات ونتائجها، قياسات الأخطاء، حالة الرجوع، والهدف التطبيقي النهائي. تجيب كل قطعة عن سؤال واحد، ولا يجوز أن تستعير سلطة السلسلة كلها.

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

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

Sources