الخلاصة

  • يعرض دليل Delegation Key العام لدى ARIN النوع 3 من الملخصات باسم MD5 وبطول 32. أما سجل IANA فيخصّص نوع ملخص DS رقم 3 لـ GOST R34.11-94، المصنّف حالياً على أنه متقادم.
  • لا يحدد جدول الطول وحدته. ملخص GOST المكوّن من 256 بت يساوي 32 بايتاً من ثمانية بتات، أو 64 محرفاً بالنظام الست عشري. لا يكشف هذا الفرق ما تقبله واجهة API الفعلية أو ترفضه.
  • تحمل خانات التوصية الأربع الحالية لدى IANA عبارة MUST NOT لهذا النوع، وفق RFC 9906. إصلاح الاسم ليس توصية باستخدامه. لم تُختبر واجهة إعداد أو منطقة DNS أو برامج توقيع أو محلّلات أسماء في هذا التحقيق.

الدليل يصف رقماً لا يملك إعادة تعريفه

تبدأ المقارنة من سؤال محدد: ما الوظيفة المسجلة للرقم داخل هذا الحقل؟ في مرجع Reg-RWS العام، تضع ARIN الاسم MD5 أمام نوع الملخص 3، ثم تسجل طولاً مقداره 32. في سجل أنواع ملخص DS لدى IANA، يشير الرقم نفسه إلى GOST R34.11-94. ليست المسألة اختلافاً في الاختصار أو الترجمة، بل اختلافاً بين وظيفتين تشفيريتين.

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

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

من هنا تنشأ نتيجة محتملة بصيغة شرطية: إذا حسب مطوّر عميل قيمة MD5 اتباعاً للاسم المنشور، ثم ربطها بالنوع 3، فقد ينتج اقتران لا يطابق الوظيفة المسجلة. لم يُرصد عميل يفعل ذلك، ولم تُفحص عملية إرسال أو إجابة DNS ناتجة عن هذا المسار. حذف الشرط من العبارة سيحوّل احتمالاً منطقياً إلى واقعة لم تثبت.

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

لم يُستخدم حساب خاص لدى ARIN أو مفتاح API، ولم يُنشأ أو يُرسل أو يُحذف سجل DS. لا يقدم التحقيق إثباتاً بأن الخدمة تقبل MD5 تحت هذا الرقم، أو تخزنه، أو تنشره. الأدلة أقوى عندما تبقى مرتبطة بما لوحظ فعلاً، بدلاً من إسناد نتائج تنفيذية إلى جدول لم ينفّذ شيئاً أمامنا.

حقلان للخوارزمية، وليس قائمة واحدة

يضع الدليل Delegation Key ضمن Delegation Payload، ويعرض algorithm وdigestType كحقلين منفصلين. يتعلق الأول بخوارزمية DNSKEY، والثاني بوظيفة ملخص DS. ظهورهما في وثيقة إعداد واحدة لا يجعل أرقامهما جزءاً من مجال ترقيم واحد. يجب اختيار سجل التخصيص الملائم للحقل قبل مقارنة أسمائه.

تضم قائمة الخوارزميات المنشورة قيماً مثل 5 و7 و8 و10 و13 و14 و15 و16، مع أسماء من عائلات RSA وECDSA وEdDSA. أما جدول الملخصات فيضع SHA1 للنوع 1 وSHA256 للنوع 2 وMD5 للنوع 3 وSHA384 للنوع 4. وترد الأطوال بالترتيب 40 و64 و32 و96. هذه قراءة للمحتوى المنشور، لا شهادة بقائمة قبول جرى اختبارها في الخدمة الفعلية.

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

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

يوضح RFC 5933 فصل الأرقام بصورة مباشرة: خصص 12 لخوارزمية توقيع DNSKEY المسماة ECC-GOST، و3 لنوع ملخص DS المسمى GOST R34.11-94. نوع DS رقم 3 ليس خوارزمية DNSKEY رقم 3. وليس قيمة 3 في حقل بروتوكول DNSKEY، ولا وسم مفتاح يحتوي ذلك الرقم. يحدد الحقل المعنى، لا تشابه الأعداد وحده.

المدخل ليس مجرد سلسلة مفتاح على شاشة

يعرّف RFC 4034 نوع ملخص DS بأنه معرّف الخوارزمية المستخدمة لبناء الملخص. ويشرح المدخل: اسم مالك DNSKEY بصورته المعيارية، متبوعاً ببيانات سجل DNSKEY، بما فيها الأعلام والبروتوكول والخوارزمية والمفتاح العام. لا يكفي وصف العملية بأنها تلخيص أي سلسلة مفتاح تظهر في واجهة ما.

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

تتفق التخصيصات الأصلية في RFC 5933 والسجل الحالي لدى IANA على أن النوع 3 هو GOST. وسمه بالتقادم لا يحرر الرقم ليصبح MD5. يمكن الاحتفاظ بمعنى تاريخي لغرض التعرف على مادة قديمة، مع بيان أن التوصيات الحالية تمنع استخدامها. الوصف التاريخي والتوصية بإنشاء مادة جديدة ليسا قراراً واحداً.

لا يزعم المقال أن MD5 غائب عن جميع البروتوكولات المتعلقة بـ DNS أو عن أي استعمال تقني آخر. تلك مسألة أوسع وتحتاج مصادر مختلفة. الحكم هنا محصور في تخصيص نوع ملخص DS رقم 3. هذا التحديد يجعل موضع التصحيح قابلاً للفحص، ويمنع تحميل المصادر ما لم تتناوله.

اثنان وثلاثون من ماذا؟

الاسم المختلف نتيجة مقارنة مباشرة. أما الطول فيحتاج قراءة أكثر تحفظاً. عنوان العمود لدى ARIN هو Digest Length، من دون وحدة محددة. تتوافق القيم المجاورة 40 و64 و96 مع عدد المحارف الست عشرية. توحي هذه المجاورة بطريقة لقراءة 32، لكنها ليست تصريحاً بأن الخدمة تفرض حداً من 32 محرفاً.

يحدد RFC 5933 طول ملخص GOST بـ256 بت. كل بايت هنا يضم ثمانية بتات، فتكون البيانات 32 بايتاً. ويحتاج كل بايت محرفين في التمثيل الست عشري، فتكون النتيجة 64 محرفاً. يصف RFC 4034 عرض ملخص DS بالنظام الست عشري من دون تمييز حالة الأحرف، ويسمح بالمسافات. لذا لا يتطابق طول نص منسق بالضرورة مع حجم بياناته الأساسية.

إذا كان العمود يقصد المحارف الست عشرية، فلا تصف 32 طول GOST المسجل للنوع 3. وإذا كان يقصد البايتات، تتوافق 32 مع GOST، لكن القيم المجاورة تحتاج تفسيراً آخر. لا تحسم الصفحة الاختيار بين القراءتين. التصحيح المناسب يعلن الوحدة وكيفية التعامل مع المسافات، ولا يحوّل تخميناً معقولاً إلى قاعدة قبول مزعومة.

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

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

تصحيح GOST لا يعيد السماح به

هناك قيد آخر على الإصلاح المقترح. استبدال MD5 باسم GOST يعيد هوية الرقم الصحيحة، لكنه لا يجعل النوع 3 ملائماً لتفويض جديد. صدر RFC 9906 في نوفمبر 2025 وأخرج ECC-GOST وGOST R34.11-94 من استعمال DNSSEC. ويعكس سجل IANA الحالي هذا القرار في توصياته.

تقول الخانات الأربع MUST NOT: الاستخدام للتفويض، والاستخدام للتحقق، والتنفيذ للتفويض، والتنفيذ للتحقق. كان وصف التنفيذ الاختياري في RFC 5933 تعبيراً عن مرحلة سابقة. يفسر ذلك أصل الرقم، ولا يتقدم على قرار الإخراج اللاحق. الاستشهاد بـMAY تاريخية بوصفها إذناً سارياً للتحقق سيخلق خطأ زمنياً جديداً أثناء تصحيح الاسم.

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

يميز RFC 9906 أيضاً بين حالة تعتمد حصراً على الخوارزميات التي أُخرجت وبين إثبات توقيع غير صالح. عندما لا توجد طريق أخرى مقبولة للمصادقة، يكون التعامل المقرر insecure، لا استخدام الخوارزميات المتقاعدة للتحقق ثم تصنيف السلسلة bogus. ولا يعني أي من التعبيرين ببساطة أن الاسم غير قابل للوصول. لم تُقَس تلك الحالة في أي منطقة لدى ARIN.

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

حقل في الأب، لا خدمة DNS بكاملها

يحدد دليل DNS العكسي لدى ARIN السياق التشغيلي. بعد تأمين المنطقة العكسية، يستطيع المشغّل الإشارة إلى بيانات DS لدى الأب وإدارتها لكل تفويض عبر ARIN Online أو خدمة الإعداد RESTful. يقع الحقل عند حد حقيقي بين مادة مفتاح المنطقة الابنة ووصف تلك المادة من جهة الأب.

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

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

الطلب المتناسب هو توحيد الاسم مع التخصيص، وتوضيح قياس الطول، وبيان الوضع الحالي. إذا نوزع في القبول الفعلي، فله دليل تنفيذ منفصل مؤرخ وقابل لإعادة الإنتاج. لا يوصي هذا التحقيق بحذف DS قائم احتياطياً، ولا يوفر إجراء انتقال مفاتيح آمناً، ولا يبرر وصف تفويض محدد بأنه معطّل.

المصادر

  • مرجع صيغ Reg-RWS لدى ARIN: حقول Delegation Key، ووصف الأسماء المشتقة من الأرقام، وجدول الأنواع والأطوال.
  • سجل IANA لأنواع ملخص DS: تخصيص النوع 3 والتوصيات الأربع الحالية.
  • RFC 5933: أرقام GOST المنفصلة وملخص 256 بت؛ توصيات الاستخدام القديمة ليست التوصيات السارية.
  • RFC 9906: الإخراج من الاستعمال في نوفمبر 2025 ومعاملة التحقق المقررة.
  • دليل DNS العكسي لدى ARIN: سياق DS عند الأب، لا إثبات لحالة منطقة معينة.
  • RFC 4034: معنى حقول DS ومدخل الملخص وعرضه الست عشري، وليس نصيحة حالية لاختيار خوارزمية.