تحديث التفويض الموقّع ذاتياً يثبت المفتاح لا الصلاحية

الخلاصة

• تقترح draft-ietf-dnsop-delegation-mgmt-via-ddns-02 أن يرسل النطاق الابن إلى جهة استقبال لدى الأب تغييرات NS أو glue أو DS المحددة عبر DNS UPDATE موقّع بـ SIG(0)، مع اكتشاف الوجهة بواسطة DSYNC.
• طلب التمهيد الأول موقّع بالمفتاح الجديد نفسه. يثبت ذلك حيازة المفتاح الخاص ولا يثبت الإذن بإدارة الابن. لذلك يبقى المفتاح known، ولا يصبح trusted إلا بعد تحقق مستقل تقبله سياسة الأب.
• ينبغي إنشاء إيصال لانتقال الصلاحية يربط المفتاح القديم، وطريقة التمهيد، والدليل المستقل، وقرار السياسة، وقبول التحديث، والنشر الفعلي في منطقة الأب. هذا اقتراح حوكمة في المقال، لا شرط من DNSOP.

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

نُشرت النسخة 02 من Automating DNS Delegation Management via DDNS في 17 يونيو 2026، وهي Internet-Draft نشطة لدى مجموعة DNSOP وقابلة للتعديل أو الاستبدال أو الانتهاء. يذكر رأس النص Standards Track، بينما لا تعرض خلاصة Datatracker حالة RFC مستهدفة. المسودة ليست RFC، ولا يثبت نشرها أن جهة سجل قد طبقتها.

المشكلة التي تتناولها واقعية. يجب أن تتطابق معلومات التفويض لدى الابن والأب: مجموعة NS، وأي glue مطلوب، وسجلات DS عند وجود DNSSEC. قد يبقى النطاق عاملاً عبر مسار قديم واحد مع فقدان بقية التكرار، فيبدو الخلل محدوداً إلى أن يسقط آخر مسار سليم.

تبحث ماسحات CDS وCSYNC دورياً في مناطق الأبناء. أما الاقتراح فيجعل الابن، الذي يعرف متى غيّر خدمته، يحسب الفرق ويرسله فوراً. ينشر الأب سجل DSYNC ليعلن عنوان UPDATE Receiver ومنفذه. تقل كلفة المسح وزمن الاكتشاف، ويمكن للنطاق غير الموقّع أن يستفيد أيضاً.

هذه نقلة للكلفة، لا إلغاء للحكم على الصلاحية.

التوقيع يحمي الأمر ولا يمنح صاحبه ولاية

يحمل DNS UPDATE الإضافة والحذف المطلوبين، بينما يوفّر SIG(0) سلامة المعاملة وإثبات التحكم بالمفتاح الخاص قياساً إلى مفتاح عام موثوق سلفاً. كلمة «موثوق» هي موضع القرار الأول.

توضح المسودة أن خوارزمية SIG(0) قد تكون بقوة خوارزمية DNSSEC، لكن نموذج الثقة مختلف. يتتبع DNSSEC عادة سلسلة إلى مرساة ثقة، في حين يحصل مفتاح UPDATE على الثقة منفرداً بعد التمهيد. قوة الرياضيات لا تحدد الجهة المؤسسية صاحبة التفويض.

لهذا لا ينبغي أن يكون Receiver أنبوب كتابة مفتوحاً إلى منطقة الأب. يمكن فصله عن الخادم الأساسي وتشغيله لدى الأب أو طرف ثالث مثل المسجّل. وعليه تقييد الأسماء وأنواع السجلات، وإجراء اختبارات الصحة المرتبطة بـ CDS وCSYNC، وحفظ التدقيق، ثم تمرير القرار المقبول إلى نظام التزويد.

تقيد القاعدة المعتادة كل مفتاح باسم ابنه: لا يُعالج تغيير child.parent. إلا إذا وقّعه مفتاح موثوق يحمل الاسم نفسه. تمنع القاعدة ابنًا من تغيير ابن آخر. وإذا استُخدم مفتاح لمسجّل يدير أبناء كثيرين، تنتقل إلى Receiver مسؤولية إثبات صلاحية كل تغيير بوسيلة أخرى، ويتسع أثر اختراق المفتاح المشترك.

حالة known تحفظ حق التوقف

عند نجاح التوقيع الذاتي، يعرف Receiver أن المرسل يملك المفتاح الجديد؛ فيسجله known. لا يتحول إلى trusted قبل اجتياز مسار تحقق مستقل. وإذا فشل التحقق، لا يدخل المفتاح مجموعة الثقة ويبقى المفتاح السابق.

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

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

طريقة التمهيد تحدد من جرى التحقق منه

إذا كان الابن موقّعاً، ينشر مفتاح SIG(0) عند قمة المنطقة ويتحقق الأب من سلسلة DNSSEC. وإذا كان الابن غير موقّع لكن أحد خوادمه الاسمية داخل منطقة موقّعة، يستطيع مشغّل ذلك الخادم إعادة نشر المفتاح تحت اسم خاص. تحصل سلسلة قابلة للتحقق، لكن التنسيق العملي مع مزود DNS يبقى خارج تفاصيل المواصفة.

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

ويبقى التمهيد اليدوي ممكناً عبر بوابة أو نموذج أو قناة خارجية. ليست كلمة «يدوي» مستوى ضمان. القوة تتوقف على الدور الذي تم التحقق منه، والسجل المرجعي، وربط التحدي، واستعادة الحساب، والاستثناءات، وحفظ الأدلة.

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

إعلان الخيارات جزء من سلسلة الثقة

يمكن للأب نشر الوسائل المدعومة في معامل SVCB اسمه bootstrap عند هدف DSYNC: at-apex وat-ns وunsigned وmanual. يكتشف الابن بذلك ما يستطيع Receiver قبوله.

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

لا يكفي أن يقول التدقيق «نجح unsigned». يجب أن يحفظ مجموعة الخيارات المنشورة، ونتيجة التحقق من الإعلان، وقدرات الابن، وقاعدة الاختيار. فالنجاح في اختبار ضعيف بعد التلاعب بقائمة الاختبارات لا يساوي دليلاً قوياً.

NOERROR يعني القبول لا الظهور في المنطقة

بعد الوثوق بالمفتاح، يمر كل UPDATE بفحوص النطاق والصحة والسياسة. تؤكد استجابة NOERROR الاستلام والقبول، وتقول المسودة إن ظهور التغيير في منطقة الأب متوقع لاحقاً. تبقى خطوة التزويد والنشر مستقلة.

في انتقال خوادم الأسماء، قد يوقف الابن الخدمة القديمة مبكراً بينما ما زال الأب ينشر NS السابق. وفي تغيير DS، قد ينتج فشل تحقق إذا عومل القبول كأنه نشر. لذا توجد أربع لحظات: معرفة المفتاح، الوثوق به، قبول UPDATE، ونشر RRsets فعلياً.

كما أن الردود تحتاج مصادقة في الاتجاه الآخر. لكي يعتمد الابن آلياً على حالة المفتاح التي يعلنها Receiver، يجب أن يثق بمفتاح ردوده. الرد المزور لا يمنح المهاجم حق التغيير، لكنه قد يطلق تمهيداً غير لازم ويعطل التشغيل.

إيصال يفسر انتقال الصلاحية

أقترح إيصالاً مقيد الوصول لكل تمهيد وإعادة تمهيد. ليس سجلاً جديداً في DNS ولا متطلباً من IETF. وظيفته تفسير سبب انتقال المفتاح من known إلى trusted.

يثبت الإيصال الأب والابن وReceiver، وجواب DSYNC والتحقق منه، وإصدار البرمجية والسياسة، وبصمات المفتاح القديم والجديد، وملخص الطلب الموقّع وتوقيته. ويحفظ كل الطرق المعلنة والمتاحة وسبب الاختيار.

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

تصبح known وبداية التحقق والفشل وtrusted والاستبدال والإلغاء أحداثاً مستقلة بأوقات ومسؤولين. يثبت السجل بقاء المفتاح القديم حتى نجاح الجديد. ويربط كل UPDATE لاحق بالفرق الدقيق، والفحوص، وقرار السياسة، والاستجابة، ومهمة التزويد، ثم بمشاهدة RRsets الجديدة على خوادم الأب.

السرعة مفيدة عندما تحرك القرار ولا تختصره. يستطيع المفتاح أن يثبت حيازته؛ أما الصلاحية فتحتاج جهة موثوقة تمنحها ودليلاً يشرح المنح.

المصادر

1. أتمتة إدارة تفويض DNS عبر DDNS — النسخة 02
2. سجل المسودة في Datatracker
3. تاريخ المسودة
4. وثائق DNSOP
5. مجموعة عمل DNSOP
6. RFC 9859 — إشعارات DNS المعممة
7. RFC 2136 — التحديث الديناميكي في DNS
8. RFC 2931 — توقيعات طلبات ومعاملات DNS
9. RFC 3007 — تحديث DNS الديناميكي الآمن
10. RFC 8078 — إدارة DS لدى الأب بواسطة CDS/CDNSKEY
11. RFC 7477 — مزامنة DNS من الابن إلى الأب
12. The Policy Mirror