الخلاصة

  • المراجعة 05 من DNSSEC automation مسودة Internet-Draft نشطة في DNSOP، وليست RFC ولا دليلاً على تنفيذ أو انتقال ناجح.
  • تجمع المسودة نموذج تعدد الموقّعين مع CDS/CDNSKEY وCSYNC، وتفصل مهلات DS وDNSKEY وNS وRRSIG لأن كل واحدة تحمي تعرضاً مختلفاً.
  • في النموذج اللامركزي قد يحسب كل موقّع زمناً صحيحاً من رؤية مختلفة؛ لذلك يجب أن يكون الاتفاق على المدخلات جزءاً من الدليل، لا افتراضاً.
  • تزامن محتوى المنطقة العادي خارج نطاق المسودة. توافق المفاتيح والبنية لا يثبت توافق الإجابات التي يتلقاها التطبيق.

صحة الحساب لا تكفي

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

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

قد يرى موقّع TTL مختلفاً، أو عضوية قديمة، أو نشر DS في وقت غير الذي رآه الآخرون. حينئذ تكون المعادلة سليمة والقرار خاطئاً للمجموعة. لا يكفي أن يسجل كل طرف “انتهت المهلة”؛ يجب حفظ القيم والمصدر والوقت ورؤية بقية الأعضاء.

أربع مهل لأربعة أسطح

تبدأ DS-Wait-Time بعد أن ينشر الأب مجموعة DS الجديدة، ولا تقل عن TTL الخاص بها. نشر CDS/CDNSKEY لدى الطفل طلب، واكتشافه أو استلام إشعار حدث معالجة؛ أما DS العام فهو حالة يملكها الأب.

تبدأ DNSKEY-Wait-Time بعد نشر مجموعات المفاتيح المقصودة لدى جميع الموقّعين. يشمل حدها الأكبر من TTLات DNSKEY وزمن وصول المنطقة إلى كل الخوادم الثانوية. نجاح الكتابة في خادم أولي لا يثبت الاستجابة من الثانويات.

تبدأ NS-Wait-Time بعد نشر الأب للتفويض الجديد، وتأخذ أكبر TTL ذي صلة من الأب والموقّعين. سجل CSYNC الصحيح لا يثبت أن منطقة الأب تغيرت.

تبدأ RRSIG-Wait-Time حين يتوقف المفتاح عن إنشاء توقيعات جديدة. يبقى DNSKEY القديم منشوراً ما دامت بيانات وقّعها قد تظهر من الكاش. انتهاء مهمة التدوير ليس انتهاء التوقيع.

تشابه العدادات بصرياً لا يجعلها رقابة واحدة. لكل عداد نقطة بدء مرصودة، وكائن محمي، وافتراضات، ومالك قرار.

البداية يجب أن تكون واقعة مرصودة

إذا بدأ المتحكم عداد DS عند إرسال CDS، فهو يحتسب زمناً ربما لم يكن الأب خلاله قد نشر شيئاً. وإذا بدأ NS من قبول طلب في نظام السجل، فهو يستبدل حالة سير العمل بحالة DNS العامة. وإذا بدأ DNSKEY من تعديل محلي، فهو يخفي تأخر الثانويات.

يحتوي إيصال البداية على RRset الدقيق، ونقطة الرصد السلطوية، والوقت، وTTL، وحالة التحقق، وجيل المنطقة والسياسة. بعد مرور الحد، يرصد النظام الحالة اللاحقة من جديد. الانتظار يستهلك الزمن؛ لا ينتج ملاحظة.

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

الانضمام التزام جماعي

يجب أن يخدم الموقّع الداخل منطقة موقعة تعمل، وأن يستخدم خوارزميات متوافقة، وأن يميز مفاتيحه وسجلات NS الخاصة به عن المواد المستوردة من بقية المجموعة.

توزع المجموعة المفاتيح العامة، وتحسب CDS/CDNSKEY لجميع KSK أو CSK، ثم تنتظر نشر الأب لمجموعة DS المجمعة. بعد ذلك تُجمع NS وتُسقط على الأب، وقد يستخدم CSYNC للتعبير عن الحالة المطلوبة.

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

الخروج يفصل المسار عن حياة التوقيع

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

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

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

البنية المتفقة قد تخفي محتوى مختلفاً

تستبعد المسودة تزامن بيانات المنطقة العادية. يمكن للموقّعين نشر DNSKEY وNS متطابقين، مع أن أحدهم يقدم سجلاً حديثاً والآخر يقدم نفياً موقعاً من جيل سابق. قد تكون الإجابتان صالحتين في DNSSEC.

يثبت DNSSEC أصالة الإجابة وفق السلسلة، ولا يختار أي نسخة تمثل أحدث قصد لمالك المنطقة. يلزم عقد مستقل لنقل البيانات، وجيل أو SOA متوقع، ومقارنة المحتوى، واتساق سياسة التوقيع، واختبار كل سلطة.

لذلك تبقى حالات “تقارب البنية” و“تقارب المحتوى” و“ملاحظة المحلل” و“نتيجة التطبيق” منفصلة. لا يجوز للوحة المفاتيح أن توقع نيابة عن لوحة البيانات.

آلية الثقة سلطة تحتاج حوكمة

تطلب المسودة قناة موثقة لتغيير DNSKEY وCDS/CDNSKEY وCSYNC وNS، لكنها تترك التفاصيل خارج النطاق. يلزم رغم ذلك اسم للفاعل، ونطاق للمنطقة وأنواع السجلات، وموافقة، وتدوير، وسحب، وسجل تدقيق.

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

حالة الوثيقة تحد الادعاء

في تاريخ التجميد يعرض Datatracker المراجعة 05 كمسودة DNSOP نشطة تنتظر موافقة رئيس المجموعة، وحالة IESG هي I-D Exists. يصف Datatracker الحالة المقصودة بأنها Informational، بينما يقول رأس النص Standards Track، وتنتهي المسودة في 6 يناير 2027.

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

دفتر انتقال مشترك

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

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

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

المصادر