الخلاصة

  • تعبّر سجلات CDS وCDNSKEY عن معاملات التفويض التي يريدها مشغل DNS للمنطقة الابنة. ولا يتصرف الوكيل الأبوي إلا بعد توثيق الإشارة، وفحص جميع عناوين خوادم الأسماء السلطوية، والتأكد من اتفاق الصيغتين، والإبقاء على مسار صالح واحد على الأقل للتحقق.
  • يسرّع NOTIFY(CDS) اكتشاف التغيير لكنه لا يأذن به. القبول والنشر في المنطقة الأم وانقضاء النسخ القديمة في الذاكرة المخبأة ونجاح المدقق الخارجي حالات تحتاج إلى أدلة مستقلة.

عنوان واحد أعاد الجواب القديم

اكتمل تجهيز مفتاح التوقيع الجديد، وأصبح RRset الخاص بـDNSKEY موقعاً. يرى نظام التحكم سجلات CDS وCDNSKEY الجديدة على الخادم الأساسي ويعلن أن التدوير جاهز.

يجمع الوكيل الأبوي كل عنوان IPv4 وIPv6 لكل اسم خادم وارد في التفويض، ثم يسأل كل عنوان. تعيد الأغلبية السجلات الجديدة، لكن عنواناً تابعاً لخادم ثانوي لا يزال يعيد المجموعة القديمة. يتوقف التحديث ولا يمس DS القائم.

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

كما يكشف تعدد معنى كلمة «نُشر». قد تكون البيانات دخلت نظام الإعداد ولم تصل إلى كل خادم. وقد تظهر CDS في الابن ولا يظهر DS بعد في الأب. وحتى بعد ظهور DS في الخوادم السلطوية للأب، قد يحتفظ محلل تكراري بالقيمة السابقة حتى نهاية TTL.

حد المنطقة يوزع المسؤولية

ينشر الأب RRset من نوع DS يشير إلى DNSKEY لدى الابن، بينما ينشر الابن RRset الخاص بمفاتيحه ويوقعه. يعبر المدقق حد المنطقتين لبناء سلسلة الثقة، ولا يستطيع أي طرف أن يلغي مسؤولية الطرف الآخر.

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

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

هذه الحدود لا تمنح الأب سيادة واسعة. الابن يتحكم في مفاتيحه وتوقيعه ونشره السلطوي، والأب مسؤول عن رابط الثقة الذي سيوقعه وينشره. وظيفة القواعد المشتركة هي حماية قابلية التشغيل والأمن بأضيق شروط قابلة للتحقق.

الفحص يشمل كل عنوان لا كل اسم فقط

يحسم RFC 9975 نطاق الاتساق. يستخدم الوكيل الأبوي محللاً متحققاً للحصول على كل عناوين IP لكل اسم خادم في تفويض الأب، بما في ذلك سجلات glue المتاحة، ثم يستعلم من كل عنوان.

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

تدخل NODATA ضمن الإجابات المستلمة. إذا اختلفت الإجابات، يجب إلغاء العملية: لا إنشاء ولا تعديل ولا حذف للسجلات التي كانت ستتأثر. لا يصوت الوكيل بين الأجوبة ولا يخمن أيها أحدث.

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

صيغتان لنية واحدة

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

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

كذلك لا ينبغي تجميد الخوارزميات داخل البرنامج. سجلات IANA لخوارزميات DNSSEC وخلاصات DS هي المرجع الجاري. القرار القابل للتدقيق يحفظ المدخلات وDS المحسوب وإصدار السياسة المطبق.

الاستمرارية هي مبرر سلطة القبول

قد تكون الإشارة موحدة على كل الخوادم ومع ذلك تنتج DS يكسر السلسلة. يفرض RFC 10026 التحقق من أن المجموعة الناتجة تسمح باستمرار التحقق من DNSSEC، وإلغاء التحديث إذا لم تنجح المراجعة.

ينبغي أن يشير DS الناتج إلى مفتاح واحد على الأقل يستطيع التحقق من توقيع RRset الخاص بـDNSKEY لدى الابن بخوارزمية وخلاصة مناسبتين. يوفر تداخل المفاتيح القديمة والجديدة أثناء التدوير مساراً لمن لا يزال يرى DS القديم ولمن بدأ يرى الجديد.

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

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

التسجيل الأول لا يستطيع توثيق نفسه

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

يقدم RFC 9615 إشارات موثقة داخل مناطق إشارة موقعة يديرها مشغل DNS. يتحقق الوكيل الأبوي من هذه المناطق ويستخدم معلومات _dsboot الخاصة بالابن لتوثيق CDS/CDNSKEY في التفويض غير الآمن.

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

ويعرّف RFC 8078 إشارة حذف صريحة: CDS بخوارزمية 0 ونوع خلاصة 0 وخلاصة 00. غياب CDS لا يعني طلب إلغاء DNSSEC؛ فقد يكون تأخر نشر أو خطأ إعداد. لا يجوز أن يتحول الصمت إلى حذف لا رجعة فيه.

الإشعار جرس وليس مفتاحاً

قد يتأخر المسح الدوري عند الأب. يتيح RFC 9859 للأب نشر هدف إشعارات عبر DSYNC، ويرسل الابن NOTIFY(CDS) بعد تغيير CDS/CDNSKEY.

يعني الإشعار «افحص الآن»، ولا يعني «غيّر الآن». بعد استلامه يجلب الوكيل البيانات السلطوية، ويتحقق من التوقيع، ويفحص كل العناوين، ويقارن الصيغتين، ويحسب DS، ويفحص الاستمرارية.

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

ولهذا تفصل القياسات بين اكتشاف الهدف واستلام الإشعار وبدء الجمع والوصول إلى الاتساق والقبول والنشر والتحقق. وصول الجرس لا يثبت فتح البوابة.

النشر يبدأ رحلة الذاكرة المخبأة

قد ينجح القبول ويبقى في طابور إعداد المنطقة. دليل النشر الأقوى هو رؤية بصمة DS على خوادم الأب السلطوية مع إصدار المنطقة وTTL ووقت الرصد.

بعد ذلك يحتفظ المحللون التكراريون بـDS السابق حتى انتهاء TTL. قد يرى مدققان حالتين مختلفتين خلال الانتقال من دون أن يكون أحدهما معطلاً. يجب أن يبقى مسار صالح لكلا المجموعتين.

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

لذلك تغطي اختبارات الخارج أفق TTL القديم وتستخدم شبكات متعددة. يسجل كل اختبار DS المرئي وDNSKEY المستخدمة ونتيجة التحقق. نجاح واحد دليل على مسار واحد في لحظة واحدة، لا على تقارب عالمي.

الأتمتة تحتاج إلى طريق نجاة مستقل

صيانة المفاتيح عمل أمني عادي. لا ينبغي لقفل تحديث عادي لدى المسجل أو السجل أن يوقف وحده صيانة DS الموثقة؛ فهذه الأقفال تحمي غالباً بوابة العميل ولا تمنع أفعال الوسيط نفسه.

وفي الوقت ذاته يفرض RFC 10026 قناة أخرى، بما فيها القناة اليدوية، لصيانة DS. قد تضيع مفاتيح الابن أو يرفض المزود التعاون أو تتنافس جهتان أثناء النقل. يجب توثيق مسار الاسترداد بعيداً عن المفتاح المفقود وترك سجل قرار مكافئ.

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

المصادر