الخلاصة

  • يقترح مشروع DNS Delegation Extensions التزام ADT داخل مجموعة DNSKEY الموثقة، بحيث يجب أن ترافق الإحالةَ أدلةُ NSEC أو NSEC3 على وجود أنواع التفويض أو غيابها.
  • يمكّن هذا الدليل المحلّل من اكتشاف السجلات المنزوعة ورفض استجابة مخفّضة، لكنه لا يخلق خادماً بديلاً ولا يثبت نجاح النقل أو وصول المستخدم إلى الاسم.

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

بعد ذلك بقي التطبيق بلا جواب.

هذه المسافة بين الرفض الصحيح والنتيجة التشغيلية هي جوهر القراءة المفيدة للمراجعة 11 من DNS Protocol Modifications for Delegation Extensions. صدرت المسودة في 17 سبتمبر 2026 وتنتهي في 21 مارس 2027، وهي Internet-Draft نشطة ضمن مجموعة DNSOP ومقصودة لمسار المعايير. ليست RFC نهائية، ولا تقرير تنفيذ، ولا برهاناً على أن مشغلاً بعينه نشر الآلية. ما تقدمه هو نموذج دقيق لما يمكن لكل طبقة إثباته، وما لا تستطيع أن تستعيره من الطبقة التالية.

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

خريطة الأنواع التزام قابل للتحقق

تقترح المسودة البت 14 في DNSKEY لعلامة Authoritative Delegation Types، أو ADT. لا يستنتج المحلّل هذه العلامة من الاستجابة الجاري فحصها؛ بل يحدد حالتها من مجموعة DNSKEY سبق التحقق منها للمنطقة المفوِّضة.

إذا كانت ADT مفعّلة في أي مفتاح ضمن المجموعة، وجب أن تحمل الإحالة دليلاً من NSEC أو NSEC3 يبين وجود أنواع التفويض أو غيابها عند الاسم المفوَّض. يقارن المدقق سجلات NS-Omitting وNS-Preserving وPrivate الظاهرة في قسم Authority بخريطة الأنواع الموثقة. إذا أثبتت الخريطة وجود نوع ولم تحمله الإحالة، تعد الاستجابة متلاعباً بها ويجب تجاهلها.

لا يلزم أن تظهر أنواع On-Demand في الإحالة العادية حتى إن ظهرت في الخريطة، لأن عقدها هو أن تُطلب صراحة. هذا الاستثناء مهم: لا يكفي أن تسأل الأداة «هل كل بت يقابله سجل؟»؛ عليها أن تفهم فئة النوع والسياق الذي يفترض أن يظهر فيه.

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

شروط الحماية لا يجوز اختصارها

لا تعمل هذه الحماية إلا إذا كانت المنطقة المفوِّضة موقعة بـDNSSEC، وكانت ADT مفعلة، وكان المحلّل يجري التحقق، وكان يفرض فحص الاتساق المحدد. فقدان أي شرط يعني أن الآلية لا تقدم حماية تشفيرية من نزع أنواع التفويض أو حذف DE.

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

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

التفاوض يقول من يفهم اللغة

يطلب النص تخصيص البت 2 من EDNS(0) لعلامة Delegation Extensions، أو DE. يضعها المحلّل الواعي في الاستعلام. ويعيدها المحلّل التكراري الواعي في جوابه إلى stub واعٍ، دلالة على الدعم.

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

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

رقم النوع يحدد ما يحدث لـNS

المجال المقترح مقسم إلى أربع فئات. 0xF0000xF07F لأنواع NS-Omitting التي تكفي لمعالجة التفويض من دون NS. 0xF0800xF0FF لأنواع NS-Preserving التي تكمل NS. 0xF1000xF1EF لأنواع On-Demand التي لا تُرسل عادة في الإحالات. و0xF1F00xF1FF للاستخدام الخاص مع الحفاظ على NS.

عندما تكون DE مفعلة، يرسل الخادم أنواع NS-Omitting وNS-Preserving وPrivate الموجودة، ولا يرسل On-Demand إلا عند طلبها. وجود نوع NS-Omitting واحد يجعله يحذف NS مهما كانت الأنواع الأخرى، وحتى لو كان QTYPE هو NS.

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

بذلك يصبح رقم النوع نفسه جزءاً من السياسة. توزيع نوع يستبدل NS داخل فئة تحافظ عليه سيجعل البرامج العامة تنفذ سلوكاً مخالفاً للمقصود. ولهذا يجب أن يراجع الخبراء ملاءمة الفئة، وأمان المعالجة لدى برنامج واعٍ بالإطار لكنه لا يعرف النوع المحدد، وصلته بمتطلبات DNSSEC. السجل ليس دفتراً إدارياً؛ إنه ينشر فرعاً تنفيذياً للبرمجيات المستقبلية.

الرفض يمنع ارتداداً صامتاً

إذا عرف المحلّل وجود بيانات NS-Omitting لكنها غير صالحة للاستعمال، فلا يحق له العودة إلى NS. يعامل الحالة كما لو أن SLIST امتلأت بخوادم غير قابلة للوصول. هذه قاعدة قاسية على التوفر، لكنها تمنع الفشل من إعادة الاستعلامات خفية إلى نقل DNS تقليدي وغير مشفر ربما.

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

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

الدليل السلبي يحتاج شكلاً صحيحاً

إذا كان الأب ينشر أنواع التفويض فقط ولا يملك NS، فإن محللاً غير واعٍ يرسل DE=0 لن يحصل على إحالة يستطيع استعمالها. يرسل الخادم استجابة سلبية ويُستحسن أن يرفق EDE 34، “New Delegation Only”. الرمز يشخص عدم التوافق، لكنه لا يمنح العميل القدرة الناقصة.

قد يحذف مهاجم DE ليجبر الخادم على هذه السلبية ويحدث حجب خدمة. المحلّل الذي تحقق من ADT يتوقع دليلاً من NSEC أو NSEC3، ويرفض جواباً عارياً. ومع Compact Denial of Existence لا يصلح جواب NXNAME مطابق للاسم المطلوب، لأنه يخفي بتات أنواع التفويض عند نقطة الإحالة. يجب استخدام دليل Name Error تقليدي.

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

SLIST ليست سجلاً للاتصال

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

غير أن RFC 1034 وهذه المسودة يحددان كيفية ملء SLIST، لا كيفية استعمالها. ظهور خادم في المجموعة لا يثبت اختياره، ولا إنشاء اتصال به، ولا استخدام نقل مشفر، ولا استلام جواب.

السجل القابل للتدقيق ينبغي أن يفصل: DE عند كل حد، DNSKEY وADT الموثقتين، دليل NSEC/NSEC3، فئة رقم النوع، قرار أولوية NS، مرشحي SLIST، الخادم المختار فعلاً، النقل، والنتيجة النهائية. عند دمج هذه المراحل في عبارة «استخدم التفويض الجديد»، تستعير كل مرحلة ثقة الأخرى من دون دليل.

الخريطة التي أثبتت وجود النوع أدت وظيفتها. أعطت المحلّل أساساً لرفض الاستجابة الناقصة. أما الوصول، فظل سؤالاً آخر. القيادة المسؤولة لا تقلل من قيمة الدليل بسبب غياب الخدمة، ولا تدّعي أن الدليل أعاد خدمة لم يعدها.

المصادر