فعّلت Cloudflare التحقق من توقيعات DNSSEC باستخدام خوارزمية ML-DSA-44 على محلل DNS العام 1.1.1.1، في خطوة تهدف إلى اختبار جاهزية منظومة أسماء النطاقات لمرحلة قد تصبح فيها خوارزميات التوقيع الحالية قابلة للكسر بواسطة حواسيب كمية قوية. وتقول الشركة إن هذه الخطوة هي بداية عملية انتقال أطول، لا تطبيقاً كاملاً لأمن DNSSEC ما بعد الكمي.
نشرت المعهد الوطني للمعايير والتقنية في الولايات المتحدة (NIST) خوارزمية ML-DSA-44 ضمن الخوارزميات المعيارية، وحصلت الخوارزمية على رقم 18 لخوارزميات DNSSEC من IANA. وتخطط Cloudflare للوصول إلى أمن ما بعد كمي كامل بحلول عام 2029، بعد أن ركز جزء كبير من عملها السابق على اتفاقيات المفاتيح في TLS.
توقيع واحد أكبر من حزمة DNS المعتادة
تتمثل العقبة العملية الأبرز في حجم التوقيع. فتوقيع ML-DSA-44 يبلغ 2,420 بايت، مقابل 64 بايت لتوقيع ECDSA P-256، كما يبلغ حجم مفتاحها العام 1,312 بايت. وبذلك يتجاوز التوقيع وحده حدوداً شائعة لاستجابات DNS عبر UDP، قبل إضافة السجلات وأسماء النطاقات ورؤوس البروتوكول وبقية سجلات DNSSEC.
تستخدم تطبيقات DNS كثيراً حداً محافظاً يبلغ 1,232 بايت لحزم UDP، وهو حد يرتبط بالحد الأدنى لوحدة النقل في IPv6. وعندما لا تكفي الحزمة، ينبغي للخادم authoritative أن يعيد استجابة مبتورة تدفع المحلل إلى إعادة المحاولة عبر بروتوكول آخر، غالباً TCP، بدلاً من الاعتماد على تجزئة UDP غير الموثوقة. وتظهر المشكلة بوضوح في استجابات DNSKEY التي تحمل المفاتيح اللازمة للتحقق من المنطقة، وقد تصبح أكبر عند نشر المفاتيح التقليدية وما بعد الكمية معاً أو أثناء تدوير المفاتيح.
منع الرجوع إلى التوقيع التقليدي
لا يمكن إيقاف الخوارزميات التقليدية فوراً، لأن المحللات القديمة لن تتمكن من التحقق من منطقة تنشر ML-DSA-44 وحدها. لكن إبقاء المسارين معاً قد يفتح مساراً للخفض الأمني: يستطيع مهاجم، بعد أن تصبح خوارزمية تقليدية مثل ECDSA غير آمنة كمياً، تزوير إجابة تعتمد عليها رغم قدرة المحلل على استخدام ML-DSA-44.
لمواجهة ذلك، تعتمد 1.1.1.1 على سجلات DS المنشورة في المنطقة الأب. فإذا احتوت مجموعة DS الموثقة على سجل لخوارزمية ما بعد كمية مدعومة، تفرض Cloudflare سياسة تحقق محلية أكثر تشدداً، بحيث يلزم وجود مسار تحقق صالح باستخدام ML-DSA-44؛ ولا يكفي المسار التقليدي وحده. وتوضح الشركة أن هذه ليست بعدُ آلية التحقق المعتادة في DNSSEC، لكنها تستند إلى صلاحيات السياسة المحلية التي يتيحها RFC 4035.
ما الذي يتغير عملياً؟
بالنسبة إلى مستخدمي 1.1.1.1، لا يلزم إجراء أي تغيير؛ فالتحقق يحدث تلقائياً عندما تنشر المنطقة سجلات DNSSEC المطلوبة، بينما تستمر المناطق الحالية في العمل بالطريقة المعتادة. وتقول Cloudflare إن نحو 85% من الاستعلامات إلى 1.1.1.1 تصل عبر UDP، ما يجعل قياس الاستجابات الأكبر وإعادة المحاولة عبر TCP جزءاً مهماً من الاختبار التشغيلي.
لكن تفعيل التحقق على المحلل لا ينشئ سلسلة ثقة ما بعد كمية مكتملة. إذ يجب أن تدعم الخوادم authoritative توقيع المناطق، وأن تقبل المسجلات سجلات DS المناسبة، وأن تنشرها السجلات في المناطق الأب، وصولاً إلى جذر DNS. وأي مستوى يفتقر إلى الحماية ما بعد الكمية يظل نقطة محتملة للخفض.
قراءة certi.news
القيمة الأساسية في هذا الإعلان ليست إضافة خيار للمستخدم النهائي، بل نقل ML-DSA-44 من معيار تشفيري إلى اختبار تشغيلي على نطاق واسع. فالمشكلة التي تكشفها Cloudflare مزدوجة: نقل رسائل أكبر بكثير من المعتاد، والحفاظ على صرامة التحقق أثناء بقاء الخوارزميات القديمة لأعوام. وتبقى الأسئلة المفتوحة مرتبطة بسرعة تبني الخوارزمية عبر كامل سلسلة DNS، وبقياس كلفة النطاق الترددي وزيادة استخدام TCP. وتعتزم Cloudflare لاحقاً إضافة دعم توقيع ML-DSA-44 إلى Cloudflare Authoritative DNS ودعم سجلات DS في Cloudflare Registrar مجاناً لعملائها، ما سيسمح باختبار المسار الكامل.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.