الخلاصة

  • يعبّر بت SEP عن الغرض التشغيلي المقصود من مفتاح DNSKEY، وقد يساعد أداة في إعداد سجل DS؛ لكنه لا يثبت أصالة المفتاح ولا ينشئ سلسلة ثقة.
  • تمنع RFC 4034 وRFC 4035 محلّل التحقق من تغيير فحص التوقيع لمجرد تفعيل البت 15. ويظل المفتاح الموسوم بـ SEP بحاجة إلى بت Zone Key كي يتحقق من توقيعات مجموعات سجلات الموارد.
  • كان إدوارد لويس واحداً من ثلاثة مشاركين في تأليف RFC 3757. يثبت السجل هذه المساهمة المحددة، ولا يثبت التأليف المنفرد أو تنفيذ برنامج بعينه أو وظيفة حالية.

علامة إرشادية لا حكم نهائي

عندما يطلب المستخدم موقعاً، يحتاج محلّل DNS إلى التحقق من أن سجلات الاسم جاءت عبر سلسلة تفويض صحيحة. يضيف DNSSEC هذه الطبقة من التحقق، لكنه لا يعتمد على علامة يضعها المشغّل وحدها. عند تغيير مفتاح منطقة فرعية، يجب أن ينشر والدها سجل DS المتوافق معه؛ وإذا لم تتطابق السجلات، فقد يفشل التحقق من التفويض. هنا يظهر دور SEP: يساعد بعض الأدوات على اختيار المفتاح المقصود، لكنه لا يثبت صحته ولا يصلح اختلاف السجلات.

صدرت RFC 3757 في أبريل 2004 بتأليف مشترك من أولاف كولكمان وياكوب شليتر وإدوارد لويس. أضافت SEP إلى حقل أعلام DNSKEY كي تشير إلى مفاتيح يُراد لها أداء دور نقاط الدخول الآمنة. وتشمل الاستخدامات المذكورة المساعدة في إنشاء سجلات DS والتعرّف على مفاتيح يراد ضبطها بصورة ثابتة. لكنها تنص أيضاً على أن بروتوكول التحقق من DNS لا يستخدم هذا البت. الاسم لا يجعل المفتاح موثوقاً؛ إنه يصف نية في طريقة التعامل معه.

يمكن لأداة التوقيع، مثلاً، أن تختار مفتاحاً موسوماً بـ SEP من مجموعة المفاتيح المنشورة في المنطقة الفرعية لإعداد DS يرسل إلى المنطقة الأب. لكن على المشغّل التأكد من أن القيمة المحسوبة تخص المفتاح الصحيح، وعلى المنطقة الأب نشر سجل DS المناسب. لا يثبت بت في المنطقة الفرعية ما فعلته المنطقة الأب، ولا يؤكد أن السجل وصل إلى النشر، ولا يجعل توقيعاً ما صالحاً. على محلّل التحقق تطبيق قواعد DNSSEC دون اعتبار هذه العلامة إثباتاً تشفيرياً.

استبدلت RFC 4034 وRFC 4035 مواصفة 3757 في 2005، وأبقتا على هذا الحد. تصف RFC 4034 SEP بأنها إشارة مفيدة لبرامج التوقيع أو تصحيح الأخطاء. وتفرض RFC 4035 ألا يتغير سلوك التحقق بسبب وجود البت. كما أن SEP لا يحل محل Zone Key: يحتاج DNSKEY إلى هذا العلم كي يكون مؤهلاً للتحقق من توقيعات مجموعات السجلات. الأول يصف معاملة تشغيلية مقصودة؛ والثاني يتعلق بدور ضمن قواعد التحقق.

تشرح RFC 6781 لماذا يبقى SEP ذا فائدة للمشغّلين. من الشائع وضعه على مفتاح توقيع المفاتيح KSK الذي يشارك في التعامل مع المنطقة الأب، لا على مفتاح توقيع المنطقة ZSK. لكن بعض التصاميم تستخدم نوعاً واحداً من المفاتيح لوظائف يفصلها نموذج KSK/ZSK. وقد تربك هذه الحالة أداة تفترض دائماً وجود النوعين المنفصلين. تحذير RFC يبرر فحص سلوك الأداة الفعلية، لا الادعاء بوقوع خطأ في التحقق.

وينبغي عدم الخلط بين SEP وبت REVOKE في RFC 5011. تضع الأخيرة آلية لتحديث مراسي الثقة تلقائياً، مع حالة إبطال مستقلة تستخدم علماً آخر. لكل بت سياق مختلف؛ وSEP ليس إشارة الإبطال ولا قاعدة تحديث مرسى الثقة.

تحدد الوثائق أيضاً ما يمكن قوله عن لويس. تسجله RFC 3757 واحداً من ثلاثة مؤلفين، ويورد ملفه في IETF Datatracker المواصفة، بينما توفر صفحة مؤلفه لدى Internet Society سياقاً مهنياً محدوداً. لا تثبت هذه المواد أنه صمم SEP وحده أو نفذ منتجاً محدداً. وذكر ARIN في RFC هو انتساب تاريخي، لا دليل على وظيفة حالية. ولا تقدم المواصفات إحصاءً للانتشار أو للأخطاء أو للحوادث. الخلاصة التي تدعمها الأدلة بسيطة: SEP يفيد في تنظيم التعامل مع المفاتيح؛ أما الثقة فمصدرها علاقة DS والتحقق وفق البروتوكول.

المصادر