الخلاصة

  • تقترح النسخة 01 من dry-run DNSSEC حالة انتقالية: يتحقق المحلّل الداعم من المنطقة الموقعة ويبلغ عن الخلل، لكنه يعيد للعميل العادي الجواب غير الآمن الذي كان سيظهر من دون DS التجريبي إذا كانت نتيجة التحقق bogus.
  • يثبت تقرير NOERROR المقترح أن مشاركاً واحداً حضر ونجح في فحصه. لكنه لا يحصي المحلّلات الصامتة ولا العملاء خلفها؛ كما أن تقارير RFC 9567 تخضع للتخميد بالتخزين المؤقت ولا توثق هوية المرسل.
  • قبل أن يستبدل الأب DS التجريبي بـ DS الحقيقي، ينبغي حفظ إيصال انتقال يربط عينة المحلّلات واختبارات العميل وحالة الأب وحدود النقل ووضع سجل IANA والمجهولات الباقية. هذا اقتراح Daniel Kade وليس حكماً من IETF.

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

تحاول مسودة dry-run DNSSEC النشطة في مجموعة DNSOP وضع درجة قابلة للرصد بين الإعداد والإنفاذ. نشرت النسخة 01 في 21 يونيو 2026، ويذكر نصها مسار Standards Track. لكنها ما زالت Internet-Draft لمجموعة عمل، وليست RFC أو معياراً معتمداً أو دليلاً على نشر إنتاجي لدى جهة مسماة. وما زالت أرقام EDE وEDNS التي تقترحها غير محددة.

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

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

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

رؤية الفشل لا تعني فرضه

توفر Extended DNS Errors في RFC 8914 مفردات لوصف سبب العطل. وتحدد RFC 9567 قناة DNS Error Reporting: يبني المحلّل استعلاماً إلى نطاق وكيل مراقبة أعلنه الخادم السلطوي، ويدمج في اسم التقرير QNAME المعطوب وQTYPE ورمز EDE.

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

لا توثق RFC 9567 هوية المحلّل لدى وكيل المراقبة. يزيد TCP أو DNS Cookies صعوبة انتحال عنوان المصدر، من دون أن يحول العنوان إلى هوية مؤسسة مصادق عليها. وقد تكون تقارير UDP أو مصادرها الظاهرة زائفة. ويمكن للتقرير أيضاً أن يكشف خللاً محلياً لدى المحلّل، مثل مرساة ثقة قديمة؛ لذلك تبقى تصغيرات أسماء الاستعلام حماية مهمة للخصوصية.

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

يثبت NOERROR الحضور داخل العينة فقط

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

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

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

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

يحدد Wet-Run من وافق على تلقي الفشل

لا يرى العميل العادي خطأ DNSSEC بسبب الرجوع إلى الجواب غير الآمن، ولذلك لا تختبر تقارير المحلّل سلوك التطبيق عند الرفض الحقيقي. تقترح المسودة خيار EDNS باسم Wet-Run. يطلب العميل صراحة إظهار خطأ التحقق الفعلي؛ فيحفظ المحلّل الداعم حالة التجربة إلى جانب الحالة العادية للجواب المخزن، ويعيد الخيار مع الفشل. أما غير الداعم فيهمل الطلب.

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

للإجابات السلبية اختبار آخر. تسمح RFC 8198 للمدقق بتركيب إجابة من أدلة NSEC أو NSEC3 موثقة في المخبأ. وقد تخفي هذه الكفاءة دليلاً سلبياً معطوباً في الخادم السلطوي لأن الاستعلام لا يصل إليه. تطلب المسودة إيقاف التركيب مؤقتاً، وإرسال استعلام صريح، ومقارنة النتيجة، والإبلاغ عن الاختلاف برمز EDE مقترح.

يمسك الأب بمفتاح الانتقال

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

الانتقال إلى الإنفاذ هو أيضاً فعل عند الأب: يستبدل مجموعة DS التجريبية بالمجموعة الحقيقية. إرسال الطلب وقبوله وظهوره في البيانات السلطوية وانتهاء الحالات القديمة في المخابئ حقائق ذات أوقات مختلفة. لا يثبت حقل واحد بعنوان «تم التبديل» هذه السلسلة.

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

الإشارة المقترحة لم تحصل بعد على مجالها العام

تقترح النسخة 01 استخدام البت الأعلى من قيمة خوارزمية ملخص DS، وتطلب من IANA تعريف 128–255 بوصفها Dry-run DNSSEC. لا يعرض سجل IANA الحالي هذه التخصيصات. في تحديث 13 يناير 2026، يسجل 128–252 على أنها Reserved، و253–254 على أنها Private Use، و255 على أنها Unassigned، بالإحالة إلى RFC 9904.

إذا تقدمت المواصفة، يلزم توفيق صريح بين الحالتين. لا يثبت السجل أن IANA رفضت المقترح؛ فالطلب الوارد في Internet-Draft لا يصبح تخصيصاً إلا بعد العملية المناسبة. لكنه يعني أن التجربة لا يجوز أن تصف كامل النطاق كمساحة عامة مخصصة بالفعل.

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

إيصال انتقال يمكن مراجعته

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

ثم يصف العينة من دون تسميتها تعداداً. أي المحلّلات أمكن تمييزها بدليل مستقل؟ وأيها لم يقدم إلا عنوان مصدر زادت الثقة به قليلاً عبر TCP أو Cookie؟ كم إشارة NOERROR وخطأ بقيت بعد التخميد، وما الأسماء والأنواع والرموز التي ظهرت، وكيف أغلق كل إصلاح؟ يستطيع التجميع حماية الخصوصية من دون محو بنية الدليل.

تأخذ اختبارات العميل قسماً مستقلاً: Wet-Run بحسب الشبكة والمحلّل وفئة التطبيق؛ المقارنة بالرجوع العادي؛ الأجوبة الإيجابية والسلبية؛ استعلامات NSEC/NSEC3 الصريحة؛ آجال المخبأ؛ والفئات التي لم يمكن بلوغها. ترفق لقطة سجل IANA الجارية، وتوسم القيم التجريبية بأنها غير مخصصة.

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

لا يصادق الإيصال على كل محلّل. وظيفته أن يمنع العينة المختارة من أن يعاد تسميتها «الإنترنت» داخل سجل القرار. يمكن لدليل محدود أن يبرر فعلاً، إذا استطاع من يتحمل نتيجته رؤية حدوده وقبولها.

المصادر

  1. dry-run DNSSEC — النسخة 01
  2. سجل dry-run DNSSEC في Datatracker
  3. تاريخ الوثيقة
  4. وثائق DNSOP النشطة
  5. ميثاق DNSOP
  6. RFC 9567 — DNS Error Reporting
  7. RFC 8914 — Extended DNS Errors
  8. RFC 6840 — ملاحظات تنفيذ DNSSEC
  9. RFC 8198 — الاستخدام النشط للمخبأ الموثق
  10. RFC 8509 — حارس مرساة مفتاح الجذر
  11. RFC 8145 — الإشارة إلى معرفة مرساة الثقة
  12. RFC 9904 — تحديث توصيات خوارزميات DNSSEC
  13. سجل IANA لخوارزميات ملخص DS