كان التوقيع صحيحاً، لكن الإذن بقي سؤالاً منفصلاً

الخلاصة

• يتفاوض GSS-TSIG على سياق GSS عبر TKEY ثم يحمي رسائل DNS بواسطة TSIG، لكنه لا يمنح حق تعديل المنطقة.
• يحتاج السجل القابل للدفاع إلى إثبات مستقل للهوية والسياسة والإجراء المسموح والتنفيذ والانتشار وما ظهر في الاستعلام اللاحق.

لنبدأ من عبارة صحيحة لكنها ناقصة: «نجح التحقق من التوقيع». معناها أن رسالة معينة خضعت لفحص ضمن سياق أمني معين. لا تعني أن صاحب الهوية كان مخولاً حذف السجل، ولا أن الخادم الأولي حفظ التغيير، ولا أن خادماً آخر أو محللاً أعاد القيمة الجديدة في وقت لاحق.

يقسم RFC 3645 الآلية إلى مرحلتين. في الأولى، يتبادل العميل والخادم رموز GSS-API غير الشفافة داخل سجلات TKEY، عبر GSS_Init_sec_context وGSS_Accept_sec_context، حتى ينتقل السياق من غير مهيأ إلى قيد التفاوض ثم إلى قائم. وفي الثانية يستخدمان GSS_GetMIC وGSS_VerifyMIC لتوليد التوقيعات والتحقق منها داخل TSIG. وتقول النسخة النصية بوضوح إن النطاق هو المصادقة لا التفويض.

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

توزيع الأدوار ظاهر في المواصفات. يعرّف RFC 2743 إطار GSS-API، ويجعل RFC 2930 من TKEY وسيلة لنقل مادة إنشاء المفاتيح، بينما أنشأ RFC 2845 نموذج TSIG الأصلي وحدّثه RFC 8945. ويحدد RFC 4121 آلية Kerberos v5 في GSS. هذه طبقات للتشغيل البيني، وليست سياسة موحدة لمن يحق له تعديل DNS.

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

يوصي ملف التشغيل البيني بـ SPNEGO ويفرض دعم Kerberos v5 ضمن شروطه، مع السماح بآليات أخرى. وقوة الحماية لا تتجاوز قوة آلية GSS المختارة. لذلك لا تكفي خانة تسجل gss-tsig وحدها؛ يلزم تسجيل الآلية المتفاوض عليها، والاسم المستهدف، ومصدر بيانات الاعتماد، واسم المفتاح، وعمر السياق، وحالة منع الإعادة والترتيب، والطرف المقابل، ونتيجة التحقق.

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

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

يسجل سجل IANA لأسماء خوارزميات TSIG الاسم gss-tsig، وينسق سجل معاملات DNS قيماً أخرى وفق إجراءات من بينها RFC 6895. التسجيل يثبت وجود اسم مشترك، لا سياقاً حياً ولا إذناً محلياً ولا تغييراً منفذاً.

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

وتقدم كتابات Heng Lu عن طبقات الواقع، والحد الأدنى للمواصفة المشتركة، وأولوية الشفرة العاملة قراءة مؤسسية. تصنع المواصفات أرضية للتنسيق؛ تبقى الصلاحية في السياسة المحلية؛ ويحدد الخادم العامل والرصد اللاحق الحالة الموجودة فعلاً. الخلط بينها يمنح دليلاً تقنياً محدوداً سلطة لم يحصل عليها.