الخلاصة

  • قصر RFC 3445 سجلات KEY الجديدة على قيمة البروتوكول 3 الخاصة بـDNSSEC، لأن الاستعلام لا يختار نوعاً فرعياً والتوقيع يغطي كل أعضاء RRset.
  • كان الانتقال غير متماثل عمداً: يتوقف الخادم الموثوق عن كتابة القيم القديمة، لكن القارئ يحتفظ بها أثناء التحقق حتى لا يغيّر المجموعة الموقعة أو يجعل الذاكرات المخبأة تختلف.

حاوية عامة بلا فواصل

عرّف RFC 2535 بيانات KEY بأعلام وحقل بروتوكول وخوارزمية ومفتاح عام. كانت القيمة 1 للبريد، و2 لـIPsec، و3 لـDNSSEC، و4 لـTLS؛ وبقيت 5–254 متاحة، فيما عنت 255 أي بروتوكول. كان استخدام DNS دليلاً موزعاً للمفاتيح فكرة جذابة.

غير أن العميل يطلب النوع KEY لا قيمة البروتوكول داخله. فيتلقى كل RRset للاسم. وكذلك يغطي توقيع DNSSEC المجموعة بكاملها، لا الجزء المتصل بتطبيق واحد. تعددت الأغراض، لكن الاسترجاع والإثبات والتخزين ظلّت كتلة واحدة.

حوّل RFC 3445، الصادر في ديسمبر 2002 بعد نشر تجريبي محدود، المشكلة إلى حد معياري. يثبت النص وسجل RFC Editor وDatatracker والتاريخ والمراجع والاستشهادات والتصويبات المسار الوثائقي، لا حجم النشر أو صحة كل محلل.

ستة اختلافات أخفاها الشكل الواحد

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

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

ألزم RFC 3445 البيانات الموثوقة الجديدة بالقيمة 3، وحجز كل الأعلام عدا بت المنطقة رقم 7، وأغلق القيم 1 و2 و4 و255 والنطاق المفتوح. صارت أي إضافة تحتاج Standards Action. بقيت استخدامات DNSSEC المتعلقة بـRFC 2930 وRFC 2931 وRFC 3007، ولم يبق التمييز القديم بين المضيف والمستخدم.

رفض السلطة من دون محو الدليل

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

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

استبدلت RFC 4033 وRFC 4034 وRFC 4035 لاحقاً عائلة 2535 واستخدمت DNSKEY. وتوضح SSHFP وCERT وTLSA حاويات أكثر تخصصاً، من دون إثبات أن RFC واحد سببها كلها. يثبت سجل IANA الحالة الرمزية، لا التبني أو سلامة الكود.

أصغر مجموعة تشترك فعلاً في قواعد الثقة

يفصل منهج طبقات الواقع لدى Heng Lu بين الرقم المسجل، وصحة التوقيع، والسلطة الإدارية، والكود المنشور، والنتيجة. لا تدمجها حاوية واحدة. وتفسر أولوية الكود العامل لماذا صحح الاختبار التجريبي التجريد: أظهرت الاستعلامات والتواقيع والذاكرات كلفة لم يرها الرسم النظيف، من دون أن يصبح الكود صاحب سيادة.

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

الشكل السلكي المشترك لا يصنع مجال ثقة مشتركاً. إذا أجبر الاستعلام والتوقيع والذاكرة أشياء مختلفة على التحرك معاً، يصبح حد المجموعة حداً أمنياً وحداً للمساءلة.

المصادر