Summary

  • تقترح المسودة الأولى لمجموعة DNSOP أنه إذا ضمت سجلات DS أو نقاط الثقة خوارزمية UNIVERSAL واحدة على الأقل، ولم تضم FORMERLY-UNIVERSAL، يكفي توقيع واحد بخوارزمية UNIVERSAL؛ تصبح التواقيع الأخرى اختيارية.
  • الخوارزميتان 8 و13 ستبدآن في الفئة الجديدة. يلزم سجل IANA الحالي تنفيذ دعمهما للتحقق، لكنه لم يضف بعد عمود الحالة الذي تقترحه المسودة.
  • إذا أغلق محلل DNS خوارزمية UNIVERSAL معلنة بقرار محلي، فسيعامل المنطقة كأنها غير موقعة حتى لو دعم خوارزمية أخرى معلنة. خسارة المصادقة تصبح نتيجة لسياسة المحلل نفسه.

يدفع موقّع منطقة DNS تكلفة جميع الخوارزميات، بينما يكفي المحلل طريق صحيح واحد للتحقق. تفرض RFC 4035 مع توضيح RFC 6840 تواقيع لكل خوارزمية تعلنها المنطقة على النحو المطلوب. ذلك تأمين ضد محلل مجهول القدرات. لكن التأمين يصبح عبئًا متكررًا على جهة النشر. مسودة DNSOP الجديدة تريد تخفيفه حين يكون هناك خيار يفترض أن جميع المحللات تدعمه.

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

كلمة UNIVERSAL ليست زينة في السجل

تطلب المسودة من IANA إضافة عمود Validation support status إلى سجل خوارزميات DNSSEC. القيم المقترحة UNIVERSAL وFORMERLY-UNIVERSAL وخانة فارغة. تبدأ الخوارزمية 8، RSA/SHA-256، والخوارزمية 13، ECDSA P-256/SHA-256، في الفئة الأولى. سجل IANA القائم يصف تنفيذهما للتحقق بأنه إلزامي. ولا توجد خوارزمية في فئة «كانت شاملة» عند البداية. يصبح توقع الدعم العام عندها سببًا يسمح للموقع بحذف توقيع زائد.

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

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

مفتاح المحلل المحلي له فاتورة أمنية

لنفترض أن المنطقة تعلن 8 و13، وأن مزودًا يرسل مسارًا صحيحًا موقّعًا بـ8. عطّل مسؤول محلل DNS الخوارزمية 8 في إعداداته المحلية، مع بقاء دعم 13. تلزمه المسودة بأن يصنف المنطقة غير موقعة. ليس من حقه وصف رد المزود بأنه bogus وإرجاع SERVFAIL لأن المزود اعتمد خوارزمية عامة اختار المسؤول نفسه إيقافها. ويشمل المنطق خوارزمية كانت UNIVERSAL ثم توقف المحلل عن دعمها.

قد تصل إجابة DNS إلى المستخدم بنجاح، لكن المصادقة غابت من وجهة نظر ذلك المحلل. لوحة تراقب عدد الإجابات فقط ستخفي القرار. ينبغي تسجيل secure وinsecure وbogus كل على حدة، وربط التغيير بمن أغلق الخوارزمية ومتى. قدرة البرنامج على التحقق، وسلطة المسؤول الذي سمح لها بالعمل، سجلان مختلفان.

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

المستند نسخة عمل أولى مؤرخة 31 أكتوبر 2026، وليس معيارًا نافذًا. لا يحصي المحللات المتأثرة ولا يقدم حادثة انتشار. الاختبار الفاصل لكل مشغل هو مصفوفة محللاته الفعلية: ما التصنيف الناتج عندما يقدم كل مزود مجموعة جزئية من التواقيع، وعندما تُعطل 8 أو 13 عمدًا؟ عبارة «يدعم DNSSEC» لا تحمل تلك التفاصيل.

تعطي المسودة للموقّع حرية تقليل العمل المتكرر. وتترك للمحلل حرية سياسة محلية صارمة. لكنها تمنع صاحب السياسة من إخفاء فقدان المصادقة خلف إجابة DNS ناجحة.

مسودة IETF · RFC 4035 · RFC 6840 · RFC 8901 · سجل IANA