الخلاصة

  • تقترح draft-kaizer-dnsop-ml-dsa-mtl-dnssec-02 توقيع Merkle ladder واحدة بـ ML-DSA ثم إثبات إدراج كل RRset بمسار مستقل بدلاً من تكرار التوقيع الكامل.
  • يمكن التحقق من الرد الكامل، لكن ذلك لا يثبت أن authoritative signers حافظوا على node-set lineage عبر التحديث أو zone transfer أو failover أو الاستعادة.

نُشرت النسخة 02 في 28 سبتمبر 2026. غيّرت intended status إلى Standards Track وأضافت طلب سجل IANA لأنواع MTL. لكنها ما زالت Internet-Draft فردية، وليست وثيقة متبناة من DNSOP ولا إجماع IETF ولا RFC. رقم الخوارزمية لا يزال TBD. وتذكر المسودة تطبيقات اختبار في LDNS وNSD وUnbound ومكتبة C، مع تنبيه صريح إلى أن المعلومات قدمها مساهمون ولم تُتحقق ولا تعني اعتماداً من IETF.

الحاجة إلى التصميم واضحة. ML-DSA معيار توقيع ما بعد كمي أصدره NIST، لكن توقيعه الكامل كبير مقارنة بملفات DNSSEC التشغيلية الحالية. تكراره لكل RRset يزيد حجم zone والذاكرة والردود. Merkle Tree Ladders تجعل رسائل كثيرة تشترك في عملية التوقيع الثقيلة.

يحمل DNSKEY المفتاح العام لـ ML-DSA. يختار الموقّع randomizer لكل رسالة، ويحسب leaf hash ويمنحها index متسلسلاً يبدأ من الصفر. تدخل الأوراق في node set متطور يحمل SID من 32 octets. وتجمع rungs حالة المجموعة، ثم يوقّع ML-DSA على flags وSID وعدد rungs وبياناتها.

يحمل RRSIG الكامل index وrandomizer وsibling hashes والـ signed ladder. يتحقق resolver من توقيع ladder بواسطة DNSKEY، ثم يعيد حساب الورقة من RRset ويتبع authentication path إلى rung متوافق. وبعد ذلك تبقى سلسلة DNSSEC المعتادة. هكذا يستطيع توقيع كامل واحد حماية رسائل كثيرة.

لكن المشاركة لا تلغي التاريخ. يحدد SID السلسلة، ويحدد index موضع الرسالة، ويدخل randomizer في hash، وتتغير rungs كلما أضيفت أوراق. وقد تحتاج رسالة قديمة إلى path جديد بالنسبة إلى ladder الحالية. أصبحت هوية الحالة وترتيبها جزءاً من معنى الإثبات.

تمنع المسودة استخدام SID نفسه في MTL instantiations متعددة، وتذكر صراحة أن KSK node set وZSK node set يحتاجان SID مختلفين. لذلك لا تكفي حيازة private key. يجب معرفة أي سلسلة تخص أي دور، ومن يخصص index التالي، وأي generation أصبحت authoritative.

في cluster حقيقي قد يعمل signer أساسي وآخر احتياطي وHSM منفصل ونسخة disaster recovery. إذا عاد الاحتياطي من snapshot قديم، فقد يعيد استعمال index أو يعيد نشر ladder سابقة أو يبدأ SID جديداً. كل خيار قد يكون قابلاً للتصميم، لكن النسخة 02 لا تحدد الانتقال ولا المواد التي يجب نقلها أو إعادة بنائها.

النص واضح في حدود نطاقه. يحدد code points وصيغة DNSKEY وRRSIG والعمليات التشفيرية، ويترك zone signing وcomposition وupdates وtransfer ومعالجة name server وresolver وcaching لوثائق أو نسخ لاحقة. لا يجوز تحويل هذه الفجوة الصريحة إلى ادعاء بأن الاستمرارية حُلّت.

في batch signing، تُضاف رسائل عديدة قبل توقيع ladder جديدة. يقل متوسط كلفة ML-DSA وقد ينخفض حمل HSM، لكن البيانات الجديدة تنتظر إغلاق الدفعة. يختار المشغّل الحجم المناسب، ويجب أن يربطه بحد أعلى لزمن توفر التوقيع وقاعدة واضحة لترقية generation على كل الخوادم.

أما online signing فيمكن أن ينشئ node set جديداً لكل query response، كما تقترح المسودة مثالاً. يقل بذلك الاعتماد على تاريخ طويل، لكن amortization قد لا يتجاوز محتوى الرد. لذا يجب قياس CPU وHSM والlatency والتعافي لكل نموذج، لا الاكتفاء بعبارة «يدعم التوقيع الفوري».

مسار النقل تغير أيضاً. أزالت revision 01 خيار EDNS(0) الموجود في النسخة الأولى، وجعلت full MTL-Type الرد الوحيد لكل RRset. وتقول revision 02 إن هذه الردود تتجاوز دائماً DNS over UDP، وتتوقع TCP أكثر، وتوصي من يريد تجنب truncation ثم retry باستخدام TCP مباشرة عند مواجهة الخوارزمية.

TCP ينقل bytes ولا يثبت وحدة الحالة. نجاح الاتصال لا يثبت أن authoritative nodes تحمل generation نفسها. صحة Merkle path لا تثبت أن resolver يقبل الخوارزمية. ولا يغني توقيع ladder عن سلسلة DS/DNSKEY حتى trust anchor. وحتى DNSSEC صحيح لا يثبت نتيجة التطبيق.

مقال SigTag السابق في BTW يملك سؤالاً آخر: ما ladders التي يزعم العميل وجودها في cache، ومتى يرسل الخادم condensed response، وما أثر privacy وfallback. هذا المقال يسبق تلك الخطوة: كيف ينشئ الموقّع ladder متماسكة ويحفظها وينقلها ويستعيدها.

وفق running-code primacy، فإن intended status وطلب IANA وكود الاختبار مراحل نافعة وليست واقعاً تشغيلياً. تظهر adoption عندما تنجح تطبيقات مستقلة في update وtransfer وفصل KSK/ZSK وrollback وfailover وحمل TCP، ويمكن إعادة الاختبار من trust anchor حقيقي.

يجب أن يسجل ladder receipt دور المفتاح وSID ومجال indexes وrungs وSOA serial وهوية signer وإصداره ووقت الإنشاء وpredecessor. ويجب أن يعيد اختبار recovery عمداً snapshot متأخراً، ثم يبرهن استمرار السلسلة المقبولة أو الانتقال المعلن إلى سلسلة جديدة. التحقق من رد قديم لا يثبت قدرة الخدمة على توقيع الغد.

المصادر