الخلاصة

  • مجموعة DS التي يعتمد عليها المحققون توجد في النطاق الأب. أما CDS/CDNSKEY فيصف الحالة التي يريدها جانب الابن. عند وجود DS سليم تستطيع السلسلة الحالية توثيق تدوير المفاتيح؛ وفي الإدخال الأول تكون تلك السلسلة نفسها غير موجودة.
  • تنقل RFC 9615 التوثيق من مناطق الإشارة الآمنة لكل خادم أسماء خارج نطاق الابن، وتشترط تطابق الإجابات من جميع المشغلين المعنيين. هذا يثبت موافقة تشغيلية، لا ملكية المسجّل أو علمه البشري.
  • تبقى سياسة القبول ونوع البصمة ونشر DS وانقضاء TTL والتحقق لدى المحلّل أدلة مستقلة. وإشارة الخوارزمية صفر تطلب حذف DS كله، ولذلك ليست تدويراً عادياً بلا مفتاح.

توقيع صحيح لا يعرف من أين تبدأ الثقة

تفعل مؤسسة DNSSEC لدى مزود DNS مُدار. ينشئ المزود المفاتيح، وينشر DNSKEY وCDS وCDNSKEY عند قمة النطاق، وتعيد جميع الخوادم السلطوية المحتوى نفسه بتوقيعات صحيحة. تظهر لوحة الخدمة أن الإعداد جاهز، بينما لا يحتوي النطاق الأب أي DS بعد.

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

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

تعالج الأتمتة عبئاً حقيقياً. فنقل البصمة يدوياً عند كل تغيير KSK أو CSK يسبب الخطأ والتأخير وتجنب التدوير. لكن إزالة النسخ واللصق لا تعني إزالة سجل التفويض الذي يبين لماذا يحق للجهة الأبوية أن تنفذ التغيير.

الابن يعلن الحالة المطلوبة والأب يكتب سجله

DS بيانات سلطوية في النطاق الأب، تربط وسم المفتاح والخوارزمية ونوع البصمة والبصمة بمفتاح DNSKEY لدى الابن. يحمل CDS حقول DS في نوع سجل مستقل، ويحمل CDNSKEY المفتاح العام الذي تستطيع الجهة الأبوية اشتقاق DS منه.

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

غياب CDS وCDNSKEY معاً يعني عدم التغيير. يجوز للابن إزالة الإشارة بعد اكتمال المزامنة. لذلك لا تعني نتيجة فارغة أو فشل في الجمع أو تنظيف عادي حذف DS.

يختار الأب استهلاك CDS أو حساب DS من CDNSKEY، وقد يقيد أنواع البصمة التي يدعمها. يمكن أن تختلف مجموعة DS الناتجة في بصماتها مع استمرارها في تمثيل المفتاح نفسه. هذه سياسة محلية معلنة وليست تصحيحاً خفياً لرغبة الابن.

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

وجود DS يحول المفتاح القديم إلى جسر

إذا كان DS الحالي يطابق DNSKEY صالحة، يمكن للسلسلة القائمة توثيق CDS/CDNSKEY الجديد. تشترط RFC 7344 أن توقع الإشارة عند قمة النطاق بمفتاح ممثل في DNSKEY الحالية وDS الأبوي معاً، وألا يكسر التطبيق استمرارية التفويض.

يسمح المدخل الآمن السابق بانتقال محدود إلى مدخل جديد. وما زالت الجهة الأبوية تجمع RRset وتتحقق وتقارن وتمنع ملاحظة قديمة من استبدال الحديثة. يساعد RRSIG inception وSOA serial في ترتيب الوقائع، لكن المستهلك يحتاج أيضاً إلى حفظ آخر حالة قبلها.

لا ينتهي تدوير المفاتيح عند ظهور DS الجديد في خادم واحد. تحتفظ المحلّلات بتركيبات مختلفة من DS وDNSKEY وRRSIG وفق TTL. يجب نشر المفتاح الجديد في جميع الخوادم السلطوية قبل أن يشير إليه الأب، والإبقاء على القديم ما دام DS القديم قابلاً للبقاء في الذاكرة المؤقتة.

يوضح دليل BIND الحالي هذا الفصل. يستطيع BIND نشر CDS/CDNSKEY وسؤال parental-agents وإيقاف تدوير المفاتيح حتى يعيد كل منهم DS المتوقع. إن لم يستهلك الأب الإشارة، يبقى التسليم اليدوي ضرورياً. جاهزية الابن لا تنشئ قدرة في الأب.

التهيئة الأولى تستعير سلسلة المشغّل

تذكر RFC 8078 سياسات لأول DS، مثل UI أو API موثق، وفحوص تسجيل إضافية، والمراقبة عبر وقت ومواقع، وchallenge، أو المعالجة عند إنشاء delegation. قد تناسب هذه وسائل علاقات مختلفة، لكنها لا تبني من الابن غير الآمن مسار DNSSEC ذاتياً.

تقدم RFC 9615 مساراً داخل DNS عندما يوجد خادم أسماء واحد على الأقل خارج نطاق الابن. تضيف _signal قبل اسم كل خادم أسماء في NS الأبوي، ثم تنشر تحت اسم _dsboot الخاص بالابن نسخة من CDS/CDNSKEY الموجودة عند قمة النطاق.

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

يتأكد الوكيل الأبوي أولاً من عدم وجود DS ويقرأ NS من الأب. يسأل كل خادم سلطوي للابن مباشرة ومن دون ذاكرة مؤقتة. ثم يتحقق عبر DNSSEC من كل إشارة خارجية قابلة للتطبيق ويطلب التطابق بحسب نوع السجل.

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

يحمي هذا الشرط التفويضات ذات المزودين المتعددين. لا يستطيع مشغّل واحد إدخال KSK تخصه إلى الأب بينما تعرض السلطات الأخرى حالة مختلفة. كما تتطلب RFC 8901 عند تعدد الموقّعين رؤية مشتركة لـCDS/CDNSKEY خلال التشغيل والتدوير.

موافقة المشغّل ليست سند المالك

يثبت إجراء RFC 9615 أن المشغلين الظاهرين في NS مستعدون للتوقيع للابن ويقدمون مادة المفاتيح نفسها. ولا يثبت من وقع العقد أو من يملك اسم النطاق أو هل وافقت المؤسسة على التغيير.

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

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

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

الخوارزمية صفر تسحب الثقة كاملة

تعني الصيغتان الدقيقتان CDS 0 0 0 0 وCDNSKEY 0 3 0 0 حذف مجموعة DS كلها من الأب. الرقم صفر ليس خوارزمية توقيع جديدة، والجواب الفارغ لا يحمل المعنى نفسه.

يحذف الأب DS بعد التوثيق واجتياز سياسة القبول. ينتظر الابن TTL الأبوي قبل أن يوقف التوقيع. إذا أزال DNSKEY أولاً، فسترى resolvers التي ما زالت تملك DS مرجعاً إلى مفتاح مفقود وتتعامل مع التفويض بصفته bogus.

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

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

الدليل يكتمل عند محلّل محقق

قبل التغيير يُحفظ NS وDS في الأب، وإجابات كل الخوادم السلطوية للابن، وأسماء الإشارة وسلاسلها، والتطابق والحداثة وحالة الحماية من الإعادة وسياسة البصمة وهوية التفويض والفرق المقترح في DS.

بعد النشر تُفحص كل authorities في الأب، وتُنتظر نافذة TTL، وتُراجع DNSKEY والتوقيعات في كل خوادم الابن، وتُجرى اختبارات عبر validating resolvers مستقلة. اللون الأخضر في الواجهة يثبت قبول أمر. وجود DS يثبت حالة سلطوية. نجاح السلسلة يثبت نتيجة على مسار حقيقي واحد.

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

المصادر