الخلاصة

  • RFC 9905 هو معيار IETF ‏(IETF Standards Track) صدر في نوفمبر 2025، ويحدّث RFC 4034 وRFC 5155.
  • الخوارزميتان RSASHA1 وRSASHA1-NSEC3-SHA1 يجب ألّا تُستخدما لإنشاء سجلات DS أو DNSKEY أو RRSIG جديدة.
  • في المقابل، يجب أن تواصل تطبيقات المصدّقين تنفيذ التحقق بهما خلال بقاء بيانات منشورة قديمة؛ وهذا ليس إذناً بإنشاء توقيعات جديدة.

المعنى التشغيلي ليس «أوقف SHA-1 في كل مكان»، بل افصل الأدوار. عند السلطة الموقِّعة يتوقف إنتاج DNSKEY وRRSIG القائمين على الخوارزميتين. وعند التفويض لا يجوز إنشاء DS بهما. وإذا بقي تفويض لا يملك إلا DS من هذا النوع، فعلى المصدّق معاملته كتفويض غير مؤمَّن وفق RFC 9905، لا كفشل تحقق ولا كحالة bogus. وإذا لم يوجد DS آخر بخوارزمية مقبولة، تُعامل البيانات أسفل نقطة التفويض على هذا الأساس.

أما واجب التنفيذ فمختلف: يجب أن تبقى برمجية المصدّق قادرة على التحقق من الخوارزميتين لأن بعض النطاقات كانت لا تزال تستخدمهما عند النشر. لذلك لا يجوز الاستنتاج بأن جميع مشغلي أدوات التحقق يستطيعون إزالة دعم SHA-1 الآن. والبرنامج الذي أزال هذا الدعم قد يحتاج إلى بناء يدوي ليستوفي مستوى تنفيذ التحقق المطلوب.

تسلسل التشغيل

  1. السلطة والتوقيع: جرد DNSKEY وRRSIG وخوارزمية التوقيع في كل منطقة. أنشئ مساراً بخوارزمية أقوى توصي بها سجلات IANA، ولا تنشئ سجلات جديدة بـ RSASHA1 أو RSASHA1-NSEC3-SHA1.
  2. التفويض وDS: بعد ثبوت صحة DNSKEY وRRSIG الأقوى خارجياً، انشر DS المقبول عند الوالد. لا تنشئ DS من الخوارزميتين القديمتين. احتفظ بسجل التغيير، وTTL، ووقت الانتشار، ونتيجة الاستعلام من أكثر من جهة.
  3. المحللات العودية: اختبر أن المحلل يستطيع التحقق من المسار الأقوى، وأنه لا يزال يملك تنفيذ التحقق القديم أثناء فترة التعايش. راقب نتائج التفويض القديم: غياب DS مقبول قد يعني insecure، لا bogus.

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

فحوص عملية

  • هل يرفض خط النشر محاولة إنشاء DS أو DNSKEY أو RRSIG بإحدى الخوارزميتين؟
  • هل توجد خوارزمية أقوى موصى بها، وهل يتحقق منها محلل عودي مستقل؟
  • هل فُصل اختبار «قدرة التحقق» عن اختبار «السماح بالتوقيع»؟
  • هل يظهر التفويض الذي لا يملك إلا DS SHA-1 كـ insecure في الاختبار، لا كـ bogus أو فشل؟
  • هل يثبت سجل البناء أن إزالة SHA-1 من برنامج التحقق لم تحدث قبل توفير تنفيذ يدوي يفي بالواجب؟

المطلوب من المشغّل قرار متدرج: إن كانت المنطقة لا تزال تنتج SHA-1، أوقف مسار الإنتاج وانتقل إلى خوارزمية أقوى؛ إن كان DS القديم وحده منشوراً، عالج التفويض ونسّق DS المقبول؛ وإن كان المصدّق يفتقد التنفيذ، أصلح البرمجية أو ابنها يدوياً قبل إعلان اكتمال الترحيل. لا تدّعي هذه الخطة نسبة انتشار أو سلوك مورّدين أو حوادث أو مكاسب أداء؛ فهذه أمور خارج مجموعة الادعاءات المجمدة.

المصادر