الخلاصة

  • بدأ DNSOP مرحلة Last Call على مستوى مجموعة العمل للمسودة draft-ietf-dnsop-integration-04 في 24 أغسطس 2026، وحدد 7 سبتمبر موعداً للنهاية. وما زال Datatracker المحفوظ يعرض In WG Last Call؛ فالمسودة ليست RFC معتمداً.
  • تطلب المسودة النظر إلى دورة حياة الاسم: انتهاء التسجيل، وتغير حالة DNSSEC، وإزالة السجل المتوقع، وطريقة إعادة مزامنة التطبيق، لا إلى إثبات السيطرة الأول فقط.
  • يقترح هذا المقال اختباراً من أربعة انتقالات: الإنشاء، والتحديث، والحذف، والنقل أو إعادة التسجيل. ولكل انتقال ينبغي تحديد المحفز والمدقق والحالة الناتجة والحد الأقصى لبقاء الحالة القديمة.
  • يوضح AT Protocol مساراً يعتمد التحقق في الاتجاهين وإعادة الحل دورياً. أما مثال ENS في المسودة فيبين أن حذف السجل لا يلغي وحده الادعاء الإيجابي السابق على السلسلة عندما لا يدعم ذلك المسار أدلة NSEC السلبية.
  • جدول الانتقالات من اقتراح Daniel Kade التحليلي، وليس نصاً اعتمده IETF. وهو يختبر النتائج القابلة للمشاهدة مع إبقاء حرية اختيار التقنية.

حلول الموعد لا يعني صدور الحكم

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

تظهر صفحة Datatracker النسخة 04 بصفتها Internet-Draft مقترحاً للحالة Informational. حالة مجموعة العمل هي In WG Last Call، وحالة IESG لا تتجاوز I-D Exists. لذلك لا يصح وصفها بأنها RFC أو القول إن انتقالها إلى مرحلة لاحقة مضمون.

والفصل بين اللحظة والنتيجة ليس احتياطاً لغوياً فقط. موضوع الوثيقة نفسه هو منع التطبيق من الخلط بين معلومة كانت صحيحة ومعلومة ما زالت صحيحة.

التطبيق يستورد تغيرات الاسم أيضاً

تذكر النسخة 04 انتهاء النطاق، وتغير حالة DNSSEC، وإزالة سجل الموارد الذي يعتمد عليه التكامل. وقد تؤدي هذه الأحداث إلى تغير السيطرة أو الحالة منذ لحظة الربط الأولى. فإذا لم يتفاعل التطبيق، قد يبقى للمسجل السابق نفوذ بعد زوال أساسه في DNS.

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

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

يمكن تحويل المطلوب إلى اختبار مختصر:

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

ويحتاج كل سطر إلى محفز ومدقق وقاعدة تخزين مؤقت ومدة قصوى وطريق استرداد يدوي. لم يعتمد DNSOP هذا الجدول؛ إنه استنتاج يجمع متطلبات دورة الحياة والسيطرة والشمول والمزامنة في تجربة قابلة للتكرار.

لدى AT Protocol نتيجة اسمها «غير صالح»

يفصل AT Protocol بين DID المستمر واسم النطاق المقروء الذي يعمل كـ handle. وتشترط مواصفة الـhandle التحقق في الاتجاهين: يشير الاسم إلى DID، وتعيد وثيقة DID الإشارة إلى الاسم نفسه. فلا يكفي أن ينشر شخص رابطاً من طرف واحد ليصنع اسماً موثوقاً لحساب الغير.

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

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

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

في مثال ENS، الغياب لا يساوي إثباتاً إيجابياً جديداً

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

لكن المسودة تحدد القيد الحاسم: لا يدعم ENS حالياً أدلة NSEC السلبية في هذا المسار، لذلك لا يمكن إثبات عدم وجود السجل أو حذفه على السلسلة. يبقى الادعاء الإيجابي القديم حتى يستبدله إثبات إيجابي أحدث، ولا يُلغى لمجرد حذف السجل الأصلي أو انتهاء الاسم.

لم تظهر هذه العبارة للمرة الأولى في النسخة 04؛ فهي موجودة في النسخة 03، ويؤكد ذلك الفرق بين النسختين. أما سجل 04 فيصف التغيير بأنه تحديث لنص الشمول.

وتوضح إرشادات ENS لاستيراد النطاق أن المالك الجديد يستطيع تعديل سجل _ens ثم استخدام وظيفة التحديث لعكس الحالة الجديدة. تلك عملية لإدخال إثبات إيجابي أحدث، وليست كشفاً تلقائياً لمجرد الحذف.

يجب إبقاء النتيجة في حدودها. هذا قيد لمسار بعينه، وليس وصفاً لكل استخدام لـENS أو لكل تكامل DNS. لكنه يكشف سؤالاً يصلح للجميع: إذا كان النظام يعرف كيف يقبل ادعاءً، فكيف يتعلم أن الادعاء لم يعد موجوداً؟

تكلفة الخروج لا تظهر في واجهة التسجيل

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

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

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

تصلح فكرة Heng Lu عن مواصفة أولية دنيا وقرارات لاحقة محلية وتبنٍّ طوعي كأساس: تتشارك التطبيقات الانتقالات الأربعة وتحتفظ بحرية اختيار المحلل والإثبات والتخزين والاسترداد.

وإذا كان الكود العامل هو الدليل الأول، فإن عبارة «موثق عبر DNS» أقل قيمة من تجربة تضيف السجل وتغيره وتحذفه ثم تعيد تسجيل الاسم. عندها فقط نرى أين بقيت السلطة.

المصادر

  1. إعلان Last Call لمجموعة DNSOP
  2. تذكير DNSOP بموعد الانتهاء
  3. صفحة الوثيقة في Datatracker
  4. سجل تاريخ الوثيقة في IETF
  5. مسودة تكامل DNS، النسخة 04
  6. مسودة تكامل DNS، النسخة 03
  7. المقارنة الرسمية بين النسختين 03 و04
  8. تعديلات بروتوكول DNSSEC، ‏RFC 4035
  9. مواصفة handle في AT Protocol
  10. مزامنة المستودعات في AT Protocol
  11. إرشادات ENS لاستيراد DNS إلى السلسلة
  12. دورة حياة gTLD لدى ICANN
  13. Heng Lu — المواصفة الأولية الدنيا والقرارات اللاحقة المحلية
  14. Heng Lu — أولوية الكود العامل