الخلاصة

  • يفصل RFC 9718 مادة مفتاح جذر DNSSEC عن الآليات التي تصادق على ملف توزيعها؛ فلا سلطة شهادات ICANN ولا بنية مفاتيح الويب هي مرساة DNSSEC.
  • تتطلب المرساة القابلة للاستخدام خمسة أحكام مستقلة: ملف أصيل، ونافذة زمنية مؤهلة، وتمثيل متسق، وتحليل مدعوم، وقبول صريح من المشغّل.

يسهل وصف سلسلة الثقة من الأعلى إلى الأسفل. يبدأ المدقق بمفتاح موثوق، ويتحقق من الجذر، ثم يتبع التفويضات الموقعة. أما السؤال الصعب فيتجه إلى الأعلى: من تحقق من المفتاح الأول؟

لا يخفي RFC 4033 هذا الحد. مرساة الثقة هي DNSKEY موثوقة أو ملخص DS مضبوط في المدقق، وتصل قيمتها الأولى عبر وسيلة آمنة أو موثوقة خارج DNS. يصادق DNSSEC على ما يأتي بعد المرساة، لا على القرار الذي جعل المرساة موثوقة.

هذه هي القيمة الدائمة في RFC 9718، الذي شارك Joe Abley في تأليفه وصدر في يناير 2025 بصفة RFC معلوماتي من IETF. يحل النص محل RFC 7958 ويحدد طريقة نشر IANA لمعلومات مراسي منطقة الجذر. لا يلغي الثقة خارج النطاق؛ بل يسمّي حدودها.

يفصل الحد الأول بين الشيء وغلافه. تنشر IANA وثيقة XML تحوي سجلات KeyDigest. ويمكن لتوقيع CMS منفصل أن يتسلسل إلى سلطة شهادات تسيطر عليها ICANN، بينما يصادق HTTPS على التسليم ضمن بنية مفاتيح الويب. تساعد هذه الآليات في إثبات أن الوثيقة جاءت من الناشر المتوقع ولم يتغير محتواها.

لكن RFC 9718 يصرح بأن سلطة شهادات ICANN ليست مرساة DNSSEC. فسلسلة الشهادات تصادق على كائن النشر؛ أما الملخص أو المفتاح العام داخله فلا يصبح مرساة DNSSEC إلا بعد المعالجة والقبول. تسمية الاثنين «جذر الثقة» تمحو نظامين مختلفين واللحظة التي يغيّر فيها المشغّل حالة المدقق.

يزيد الانتقال عن RFC 7958 هذا الفصل وضوحاً. كان التصميم القديم يتضمن شهادات PKIX وطلبات توقيع لكل مفتاح، ومسار OpenPGP منفصلاً. أزال RFC 9718 تلك المسارات لأنها خلطت الثقة الخارجية بمفاتيح المصادقة مع الثقة الخارجية بمفاتيح جذر DNSSEC. لم تكن زيادة الأغلفة التشفيرية تلغي قرار البداية.

وتحمل وثيقة XML حالات مستقلة. تحدد validFrom وvalidUntil الفترة التي يجوز فيها استعمال KeyDigest. لا تثبتان أن كل المحللات ثبتته ولا تأمران بذلك. ولذلك لا يصبح الملف صحيح التوقيع لكنه قديم إعداداً مقبولاً تلقائياً.

قد يضيف publickeyinfo الاختياري مفتاح DNSKEY العام وحقول flags إلى الملخص. يتيح ذلك بناء DNSKEY مباشرة، لكنه يفرض الاتساق: إذا اختلف المفتاح العام والملخص فلا يجوز استعمال ذلك KeyDigest. لا يصلح توقيع CMS صحيح تناقضاً داخل الوثيقة.

وتكشف الاختيارية قدرة محلية أيضاً. قد ينتج محللان متوافقان مجموعتين مختلفتين من XML أصيل واحد إذا فهم أحدهما publickeyinfo ولم يفهمه الآخر. وحدة المصدر لا تضمن وحدة التفسير؛ لذا يجب تسجيل إصدار المحلل والتحويل والناتج.

حتى سمة source في XML إرشادية فقط. يحدد الرابط مكان الوثيقة، ولا يكتسب سلطة لأنه مكتوب داخلها. العنوان ليس تفويضاً.

ثم يأتي القبول. يترك RFC 9718 للمشغّل أن يقرر وفق سياسته قبول المراسي أو رفضها. تنشر IANA، وتساعد أنظمة الشهادات في فحص المصدر، ويحلل المطورون، ويحزم الموردون، ويقرر المشغّل ما يدخل حالة ثقة المحلّل.

لا يلغي RFC 5011 القرار الأول. فهو يمكّن مدققاً يثق مسبقاً بمرساة من تعلم خلفائها داخل البروتوكول بعد مدد الرصد والانتظار. توثق الثقة القائمة الانتقال، لكنها لا تستطيع تبرير التثبيت الأول بأثر رجعي.

تعرض صفحة IANA الحالية أسطح التوزيع بوضوح: يحمل root-anchors.xml البيانات، ويحمل root-anchors.p7s التوقيع المنفصل، ويوفر icannbundle.pem شهادات التحقق منه. وتشير الصفحة إلى اختلاف الموردين في كيفية توزيع التحديثات وتوقيتها.

وفي إشعار نوفمبر 2024، طلبت IANA جلب XML دورياً واختبار الصيغة المعدلة. نجاح النشر ليس نجاح الانتشار: قد يكون الملف أصيلاً وحديثاً بينما يرفضه محلل، أو تتأخر حزمة، أو لا يقبله مشغّل.

يمثل ملف root-anchors.xml الحالي كائن النشر المقروء آلياً، وليس إعلاناً بأن محللاً بعينه قبل إدخالاته.

تذكر سيرة NSRC أن Abley قاد عمليات DNS في ICANN وشارك في نشر DNSSEC في الجذر. لا يجعله ذلك صاحب سيادة على الجذر، بل يفسر الانضباط التشغيلي في النص: لا ينبغي لدليلين متجاورين أن ينتحل أحدهما وظيفة الآخر.

ينبغي لإيصال قابل للتدقيق أن يحفظ خمسة أجوبة: كيف تم التحقق من مصدر الملف ومحتواه؟ هل كان الإدخال داخل فترة الصلاحية؟ هل اتفقت تمثيلاته؟ أي محلل وتحويل أنشأ المرساة المرشحة؟ من قبلها وفي أي مدقق وبأي سياسة؟ عبارة «التوقيع صحيح» تجيب عن السؤال الأول فقط.