الخلاصة

  • تقترح النسخة 02 أن يرسل الابن تغييرات NS وglue وDS الدقيقة إلى الأب في DNS UPDATE عادي تحميه SIG(0)، بعد اكتشاف UPDATE Receiver بواسطة DSYNC.
  • لا تثبت المصادقة الذاتية سوى حيازة المفتاح الخاص. يسجل المستقبل KEY بوصفه known، ولا يرفعه إلى trusted إلا بعد مسار تحقق مستقل اختاره الأب.
  • عند إعادة التمهيد يجب إبقاء المفتاح القديم الموثوق حتى ينجح البديل. وحتى بعد NOERROR تظل الاستجابة دليلاً على القبول، لا على النشر السلطوي أو رؤية المحلل.

تكمن أخطر خطوة في أمر الحذف، لا في المفتاح الجديد.

يبدأ التمهيد في draft-ietf-dnsop-delegation-mgmt-via-ddns-02 برسالة موقعة بالمفتاح الذي تقترح إضافته. تطلب الرسالة حذف مجموعة KEY القديمة للابن وإضافة الجديدة. يستطيع المستقبل فحص التوقيع بالمفتاح المرفق، فيعرف أن المرسل يملك السر المقابل. لكن لو نفّذ الحذف فوراً، فلن يحتاج المهاجم إلى اجتياز تحقق السلطة؛ يكفي أن يصنع زوج مفاتيح ويبدأ طلباً زائفاً كي يطرد المفتاح الصحيح.

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

تأتي هذه الآلة في نقاش راهن. افتتحت DNSOP آخر دعوة للمراجعة في 20 أغسطس وحددت 7 سبتمبر موعداً للانتهاء. وفي 4 سبتمبر طلب أحد الرؤساء مزيداً من الدعم الإيجابي والتعليقات البنّاءة، مؤكداً أن غياب الاعتراض لا يكفي. أيد Geoff Huston الانتقال إلى النشر ورأى الدفع أكفأ من مسح الأب. وشدد Johan Stenstam على الأبناء غير الموقّعين وذكر موقعه من تنفيذ قائم. وقال Michael Richardson إن النص يكفيه لكتابة برنامج، لكنه أثار التمييز بين KEY وDNSKEY وحالة المفتاح والخوارزميات المقبلة والحاجة إلى رسم للآلة. هذه آراء أفراد، وليست إجماعاً أو اعتماداً من IETF أو إثبات تشغيل متبادل.

لا يخترع الاقتراح آلية تعديل جديدة. فالابن يستخدم DNS UPDATE المحدد في RFC 2136، ويوقع المعاملة بـSIG(0) وفق RFC 2931 وRFC 3007. وينشر DSYNC من RFC 9859 ما إذا كان الأب يقبل المسار ومكان UPDATE Receiver. ويمكن فصل المستقبل عن الخادم الأولي للأب، ليمرر الطلب إلى قاعدة تجهيز أو API بدلاً من تعديل المنطقة الجارية مباشرة.

هذا الفصل يمنع التوقيع من أن يتحول إلى أمر تنفيذ. يقيّد المستقبل السجلات القابلة للتغيير، ويربط افتراضياً اسم الابن بمفتاح SIG(0) موثوق يحمل الاسم نفسه، ثم يجري فحوص CDS/CDNSKEY وCSYNC الموضوعية. أما مخطط تفويض أوسع فيحتاج قراراً صريحاً ويتحمل الأب تبعاته. النقل أسرع؛ سلطة الأب لم تختف.

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

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

كذلك يجب حفظ الفرق بين أنواع السجل. تستخدم SIG(0) سجل KEY، لا DNSKEY. تدخل DNSKEY في بنية توقيع منطقة DNSSEC، بينما تصادق KEY هنا معاملة. تسميتهما معاً «مفاتيح DNS» تمحو اختلاف الحفظ والتدوير والاستجابة للاختراق ومدى التفويض.

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

يحتاج السجل المهني إلى حفظ اكتشاف DSYNC ونسخة السياسة، وبصمة UPDATE وشروطه، وهوية KEY، وطريقة التمهيد، ودليلي الانتقال إلى known ثم trusted، وقرار المستقبل وردّه الموثق، ومعاملة التجهيز، وتسلسل منطقة الأب، وملاحظة RRset السلطوية، ورؤى المحللات بعد TTL، ثم نتيجة الخدمة.

ينسجم ذلك مع فصل Heng Lu بين طبقات الواقع. يمكن لسجل أن يصف المفتاح بأنه معروف بدقة، من دون أن يملك حق تسميته موثوقاً. ويمكن لمشروع أن يُنشر من دون أن يُعتمد، ولطلب أن يُقبل من دون أن يتغير DNS العام. حماية هذه الحدود هي ما يمنع دليلاً صحيحاً على الحيازة من الاستيلاء على معنى السلطة.

المصادر