الخلاصة

  • قاس باحثون من University of Twente وSIDN Labs توقيع Falcon-512 المضغوط بوسيط قدره 655 بايت، مقابل 666 بايت ثابتة للتنسيق المحشو. وعند إعادة تشغيل استعلامات حقيقية إلى نطاق .nl، لم يُدخل هذا الفرق البالغ 11 بايت عدداً يُذكر من ردود DNSSEC الكاملة تحت حدود الحجم المدروسة.
  • ردود الأسماء غير الموجودة حملت أكثر من إثبات موقّع، وتجاوزت جميعها في العينة حدَّي 1,232 و1,500 بايت. بطاقة السعر على التوقيع الواحد لا تكشف تكلفة إرسال الرد كله.

فاتورة شحن لا تخفضها قصاصة ورق

تخيل شركة نقل تعرض خصماً لأنها خففت وزن الملصق على صندوق كبير بمقدار 11 غراماً. الصندوق ما زال يحتاج الشاحنة نفسها. هذا تقريباً ما يحدث حين يُروَّج لتوقيع تشفيري أقصر باعتباره علاجاً لحجم ردود DNSSEC. الشبكة لا تنقل التوقيع منفرداً؛ إنها تنقل اسماً وسجلات، وأحياناً عدة أدلة موقّعة على غياب اسم أو سجل.

في ورقة بحثية نشرتها University of Twente وSIDN Labs عام 2025، اختبر الفريق صيغتين لتوقيعات Falcon-512. الصيغة المضغوطة متغيرة الطول، والصيغة المحشوة ثابتة عند 666 بايت. بلغ وسيط المضغوطة 655 بايت في منطقة .nl التجريبية. الفارق حقيقي ويسهل وضعه في عرض تقديمي. لكن الباحثين وزنوا بعد ذلك الردود الكاملة وسألوا: كم رداً أصبح يقع تحت 1,232 أو 1,500 بايت؟

بدأت التجربة من ملف منطقة .nl واستعلامات يوم 3 أبريل 2025. أزال الباحثون بيانات DNSSEC الأصلية، ووقّعوا نسختين من المنطقة باستخدام Falcon-512، ثم أعادوا إرسال الاستعلامات المسجلة إلى خادمين تجريبيين من NSD. شملت المقارنة 59,312,128 رداً ظل تصنيفه NOERROR، و113,348,878 رداً ظل تصنيفه NXDOMAIN. جاءت أنماط الاستعلام من التشغيل الفعلي؛ أما ردود Falcon فنتجت عن إعادة تشغيل مختبرية. بذلك تقيس الدراسة أثراً تشغيلياً محتملاً على حجم الرسائل، ولا تروي قصة نشر Falcon في خدمة .nl الحية.

في فئة NOERROR، كانت معظم الردود أصلاً دون الحدين في الصيغتين. تجاوزت نسبة أصغر، لكنها ذات شأن، تلك الحدود. بعض الردود يحتاج سجلاً إضافياً من NSEC3 يحمل توقيعاً لإثبات غياب سجل DS عن نطاق فرعي غير موقّع. تقليص بضعة بايتات من التوقيع لا يلغي الإثبات الإضافي. لذلك بقي عدد الردود التي تعبر خط الحجم في الاتجاه المرغوب متقارباً بين الصيغتين.

أما NXDOMAIN، أي الرد الذي يقول إن الاسم المطلوب غير موجود، فقدم حساباً بلا مجاملة. تجاوزت كل الردود التي شملها التحليل الحدين. الردود ذات سجلي NSEC3 موقّعين تراوحت بين 2,269 و2,420 بايت؛ والتي ضمت ثلاثة سجلات تراوحت بين 3,075 و3,767 بايت. يزيد الوفر الكلي من الضغط مع زيادة التوقيعات، لكن الرد الكبير لا يصير فجأة أصغر من 1,500 بايت. تكلفة الأدلة المتعددة هي التي تحكم الشحنة.

حتى وصف «المضغوط» لا يعني طولاً واحداً مضموناً. عثر الباحثون على توقيع غير محشو طوله 667 بايت بين 9,912,711 توقيعاً في المنطقة التجريبية. الصيغة المحشوة تبقى عند 666 بايت لأن برنامج التوقيع يعيد المحاولة إذا تجاوز الناتج هذا الحد. الحالة نادرة جداً، لكنها تذكّر مطوري البرمجيات بأنهم يتعاملون مع توزيع أحجام، بما فيه الأطراف، لا مع الرقم الوسيط وحده.

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

توضح صفحة NIST الرسمية، المحدثة في 27 أكتوبر 2026، أن Falcon اختير للتقييس وأن FIPS 206 ما زال قيد التطوير. وتسرد مسودة إنترنت فردية قدمها Paul Hoffman من ICANN عناصر الاختيار في DNSSEC: حجم السجلات، سرعة النشر، عبء المعالجة، تغييرات البروتوكول، وحدات الأمن العتادية، تحليل المتانة التشفيرية، وتراخيص البراءات. ليست لهذه المسودة مكانة رسمية في مسار معايير IETF، غير أنها تمنع اختزال القرار في خانة واحدة جذابة.

وضع برنامج RIPE 93 عرض Ginevra Fabrizio لهذا البحث في 29 أكتوبر. في 28 أكتوبر لم يُعقد العرض بعد، والورقة المنشورة هي السجل الذي يمكن فحصه. الأسئلة المناسبة للقاعة واضحة: ما أنواع الاستعلامات، وكم إثباتاً في كل رد، وكم رداً يتخطى الحدود، وكم مرة يلزم الرجوع إلى TCP؟ ملصق أخف وزناً لا يكفي لتغيير أجرة الشحن.

من يختار وحدة القياس يختار الفائز

تفضّل اللجان رقماً مرتباً: بايتات التوقيع الواحد. لكن رد DNS يحمل طول الاسم، ونوع السؤال، وحالة التفويض، وإثباتات العدم. وتلاحظ الدراسة أن تفاوت أطوال الأسماء قريب في مرتبته من تفاوت أطوال التوقيعات المضغوطة. لا يحق لرقم جميل أن يتحدث باسم الرسالة كلها.

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