الخطأ الذي استطاع أن يشرح نفسه من دون أن يغيّر الإجابة

الخلاصة

• ضغطت رموز الاستجابة التقليدية في DNS أسباباً كثيرة في نتائج قليلة. خصص RFC 8914 الخيار 15 في EDNS لأخطاء DNS الممتدة، حيث يحمل INFO-CODE بطول 16 بت، ويمكن أن يتبعه EXTRA-TEXT بترميز UTF-8 لشرح موجّه إلى الإنسان.
• يمكن أن ترافق EDE نتائج مثل SERVFAIL وNXDOMAIN وREFUSED وحتى NOERROR، ويمكن أن تظهر عدة خيارات في الرسالة الواحدة. لكنها لا تغيّر معنى RCODE ولا طريقة معالجته؛ فهي دليل تشخيصي وليست إذناً بقبول بيانات رُفضت أمنياً.
• ولأن الشرح قد يُنشأ أو يُحذف أو يُعاد نقله عبر سلسلة من المحللات، فإن فائدته تعتمد على حفظ مصدره وسياقه. كما أن النص الحر قد يكشف معلومات خاصة، والخيار قد يُحذف أولاً عند ضيق حجم الحزمة، ولا تكون دقته الظاهرية دليلاً على صحته إذا لم تكن المعاملة محمية.

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

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

كان على DNS أن يشرح هذا الفرق من دون أن يفقد الاقتصاد الذي جعل رموزه قابلة للتشغيل بين أنظمة لا تعرف تفاصيل بعضها. ومن هنا جاءت قيمة EDE: توسيع المعرفة بالسبب مع إبقاء السلطة التشغيلية في مكانها.

نتيجة صغيرة حملت أكثر مما تستطيع

وضع RFC 1035 البنية الأساسية لرأس استجابة DNS. حقل RCODE يعبّر عن فئات عامة: لا خطأ، خطأ في الصياغة، فشل الخادم، اسم غير موجود، عملية غير مدعومة أو رفض. هذا الاختصار ليس عيباً في ذاته؛ فهو يسمح للمحللات والعملاء باتخاذ قرار أولي متسق من دون معرفة ما يجري داخل كل خادم.

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

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

لم يكن الحل زيادة عدد RCODE بلا حدود. فالرمز الأصلي يجيب عن سؤال التشغيل المشترك: ما النتيجة التي يجب أن أتعامل معها الآن؟ ما كان مفقوداً هو سجل مرافق يجيب عن سؤال مختلف: ما السبب الذي يرشّح الاختبار التالي؟

فتح EDNS ممراً جانبياً مضبوطاً

سبق أن أنشأ RFC 6891 سجل OPT الزائف وسجلاً لخيارات EDNS. يظهر OPT في رسالة DNS لكنه ليس بيانات نطاق عادية. وبهذه الآلية أمكن إضافة قدرات وبيانات وصفية من دون توسيع كل حقل قديم أو مطالبة الأنظمة الأقدم بفهم كل امتداد جديد.

في عام 2020 خصص RFC 8914 رمز الخيار 15 لخطأ DNS الممتد. يبدأ محتوى الخيار بحقل INFO-CODE من 16 بت. وإذا بقيت بايتات بعده، فهي EXTRA-TEXT اختياري بترميز UTF-8.

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

يمكن أن يأتي الخيار مع SERVFAIL أو NXDOMAIN أو REFUSED أو NOERROR أو غيرها، ما دامت الاستعلامات تستخدم OPT. ويمكن أن تحمل الرسالة أكثر من EDE واحدة لأن الفشل قد تكون له طبقات متعددة. قبول هذه المعلومات لا يفرض على العميل تنفيذها، ولا يبدّل طريقة معالجة الرمز الأصلي.

تلك هي الحافة التي حمت التصميم. SERVFAIL مع DNSSEC Bogus يظل فشلاً. وNOERROR مع Stale Answer يظل إجابة ناجحة في شكلها، لكن مصدرها الزمني يجب أن يبقى ظاهراً. يضيّق الشرح مجال التحقيق؛ ولا يعيد فتح النتيجة للمساومة.

الفرق بين بيانات زائفة وحالة لا يمكن حسمها

تظهر ضرورة الدقة بوضوح في DNSSEC. يميز RFC 4035 بين Bogus وIndeterminate. في الحالة الأولى، ينبغي أن تكون هناك سلسلة ثقة قابلة للبناء، لكن التحقق يفشل. قد يكون السبب هجوماً أو خطأ إعداد أو تلفاً في البيانات. أما الحالة الثانية فتعني أن المحلل لا يستطيع تقرير وجوب التوقيع لأنه لم يحصل على سجلات DNSSEC اللازمة.

خصص RFC 8914 رموزاً مختلفة لهاتين الحالتين، ثم أضاف مفردات أدق: خوارزمية DNSKEY غير مدعومة، نوع بصمة DS غير مدعوم، توقيع منتهي أو لم يبدأ مفعوله، غياب DNSKEY أو RRSIG، غياب دليل NSEC، أو عدم ضبط بت مفتاح النطاق.

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

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

أحياناً تحمل الإجابة الناجحة تحذيراً

لم تُصمم EDE للأخطاء الصريحة وحدها. قد يعجز المحلل التكراري عن تحديث سجل انتهت صلاحيته العادية، لكنه يقرر أن إجابة قديمة أفضل من انقطاع كامل. يضع RFC 8767 حدوداً لهذه الاستمرارية. يشير الرمز 3 إلى إجابة موجبة قديمة، بينما يشير الرمز 19 إلى نتيجة NXDOMAIN قديمة.

لذلك يمكن أن تكون النتيجة NOERROR ويصحبها تنبيه Stale Answer. لا يوجد تناقض: RCODE يصف فئة الاستجابة الحالية، وEDE يصف حالة البيانات أو منشأها. قرار استخدام ذاكرة قديمة لا يعيد إليها حداثتها.

وينطبق الفصل نفسه على Forged Answer، وهو الرمز المستخدم عندما تغيّر سياسة ما الإجابة مع استمرار إرجاع بيانات. وإذا منعت السياسة الإجابة، تميز الرموز بين مصادر السلطة: Blocked لسياسة أمنية داخلية يطبقها مشغل المحلل، وCensored لالتزام خارجي، وFiltered لترشيح طلبه العميل.

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

حتى الفشل المحفوظ احتاج إلى منشأ

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

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

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

في سلسلة المحللات يلتبس صاحب الكلام

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

يترك RFC 8914 قرار التمرير للسياسة المحلية. يستطيع المحلل حذف EDE التي تلقاها، أو نقلها، أو إنشاء خيار جديد يعبّر عن معناها. وإذا مرّر التشخيص، فمن الأفضل أن يحدد مصدره في EXTRA-TEXT حتى لا يبدو الكلام كأنه صادر من الجار المباشر وحده.

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

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

عند ازدحام الحزمة يخرج الشرح أولاً

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

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

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

التفصيل لا يساوي المصادقة

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

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

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

يسجل سجل معلمات DNS لدى IANA الخيار 15 وتخصيصات INFO-CODE المتغيرة. يثبت السجل أن الأرقام والمراجع منسقة. لكنه لا يثبت أن محللاً بعينه يرسلها، أو ينقلها بأمانة، أو يحمي نقلها، أو يعرضها للمستخدم، أو يصنف العطل تصنيفاً صحيحاً.

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