الخلاصة

  • منذ 10 سبتمبر 2026، صار محلل 1.1.1.1 لدى Cloudflare يتحقق من تواقيع ML-DSA-44 في نطاقات اختبار. عرض Joe Abley في RIPE 93 تجربة DNSSEC عبر المتصفح.
  • لدى المحللات التي تتحقق من التواقيع، زاد الزمن المسجل للتوقيع المزدوج عن الضبط التقليدي بمقدار 1 مللي ثانية عند الوسيط و1,405 مللي ثانية عند p99. وسمت الشرائح النتيجة الإجمالية صافي تعطل بنسبة 6.0%؛ كانت التجربة مبكرة ومشوّشة، ولم تقِس معدل تعطل لجميع المستخدمين.

الوسيط يطمئن، والذيل يستدعي المناوب

واحد مللي ثانية إضافي عند الوسيط هو الرقم الذي ستضعه نشرة ترقية بخط عريض. أما السطر الأقل راحة الذي عرضه Joe Abley في RIPE 93 فهو 1,405 مللي ثانية إضافية عند p99 لمسار التوقيع المزدوج مقارنة بالضبط التقليدي. هذا هو الطرف البطيء من التوزيع: ينتظر بعض المستخدمين بينما تجعل الأغلبية السريعة المتوسط يبدو أنيقاً.

يقارن رسم الشرائح الأصلية لـRIPE 93 الزمن المنقضي للتوقيع المزدوج مطروحاً منه ضبط الخوارزمية 13 لدى المحللات التي تتحقق من التواقيع. كانت الفروق +1 مللي ثانية عند الوسيط، و+147 عند p90، و+618 عند p95، و+1,405 عند p99. هذه أزمنة تحدي المتصفح، وليست قياساً منفصلاً لزمن التحقق التشفيري. وعرض Abley خطاً أساسياً لا يتحقق من التواقيع يقارن توقيعاً تقليدياً معطوباً عمداً بالضبط: 0 و+73 و+215 و+1,132 مللي ثانية عند النسب المئوية نفسها.

جمعت التجربة نحو 140 ألف نقطة بيانات بعد عرض التحدي على مستخدم واحد من كل ألف. أطلق كل تحدٍ أربعة طلبات HTTPS متوازية لأسماء DNS تخدمها Cloudflare: ضبط بالخوارزمية 13، وتوقيع 13 معطوب عمداً، ومسار ML-DSA-44 بالخوارزمية 18، واسم يحمل التوقيعين. وصفت الشريحة 19 النتيجة الإجمالية للمحللات المتحققة بأنها «صافي تعطل» 6.0%. وقال Abley إن نحو 20 نظاماً مستقلاً شهدت زيادة ملحوظة في التعطل، بينما لم يظهر اختلاف في معظم الأنظمة المرصودة. لم تحدد المحاضرة سبب كل إخفاق.

التوقيع الجديد قد يغلق مخرج القديم

أمكن إجراء الاختبار لأن 1.1.1.1 فعّل التحقق من ML-DSA-44 لجميع العملاء في 10 سبتمبر، ضمن نطاقات اختبار. كان ذلك دعماً للتحقق، لا إطلاقاً لتوقيع ما بعد الكم للعملاء. يسجل سجل IANA الخوارزمية 18 باسم ML-DSA-44، ويضع MAY لاستخدامها في التوقيع والتحقق. أما الخوارزمية 13، وهي ECDSA P-256 مع SHA-256، فتظهر بوصفها RECOMMENDED.

في DNSSEC المعتاد، يستطيع المحلل قبول مجموعة السجلات إذا صحّ أي توقيع RRSIG يغطيها. تقول RFC 6840 إن على المحلل قبول أي توقيع صالح، وألا يصف المجموعة بأنها bogus إلا إذا فشلت كل التواقيع. وتترك RFC 4035 التعامل مع التعارض لسياسة الأمان المحلية. تغلق قاعدة Cloudflare الأشد صرامة هذا المخرج: إذا وُجد توقيع بالخوارزمية 18، فيجب أن يصح. لا ينقذ توقيع 13 صالح توقيع ML-DSA-44 معطوباً. الهدف ألا تتحول ترقية ما بعد الكم إلى رجوع صامت نحو التوقيع التقليدي.

لكن الحماية تجعل التوقيع الجديد شرطاً للإتاحة أيضاً. إذا كان مشوهاً، قد يرفض المحلل إجابة كان التوقيع التقليدي وحده سيصادق عليها. هذا قرار سياسة محلية لدى المحلل، وليس تغييراً في بروتوكول DNSSEC الأساسي.

المتصفح لم يكن مختبراً معقماً

وصف Abley النتائج بأنها مبكرة جداً ومليئة بالتشويش. أعادت التجربة استخدام أسماء DNS نفسها، فكان التخزين المؤقت قادراً على التأثير في المقارنة؛ ولم تُبطل الاختبار ذاكرة التخزين. أضافت تحويلات HTTPS زمناً. أمكن لمن أنهى التحدي سريعاً أن يغادر قبل اكتمال القياس، كما قطع حد الثانيتين الطلبات البطيئة. وأدخلت ظروف المتصفح والشبكة المنزلية مزيداً من التفاوت. لذلك تعرض الشرائح إشارة تستحق الفحص، لا سبباً مثبتاً لكل فشل.

ظل قرار الإطلاق مفتوحاً. كانت Cloudflare لا تزال تختبر التوقيع عبر الإنترنت بـML-DSA-44، ولم تحدد موعداً لإتاحته للعملاء. قد تخلق متطلبات الامتثال طلباً على خيار اشتراك؛ أما التوقيع المزدوج افتراضياً فيحتاج إلى ثقة عالية بأنه لن يعطل الخدمة. يقترح مسودّة Joe Abley الفردية إشارة Extended DNS Error كي يميز العميل بين تطبيق المحلل لسياسة محلية صارمة وبين إجابة سلبية بلا تفسير.

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

المصادر