الخلاصة

  • يضع RFC 8914 خطأ Extended DNS Error في خيار EDNS رقم 15: INFO-CODE من 16 بت مع EXTRA-TEXT اختياري بترميز UTF-8. يضيف EDE سياقاً إلى RCODE الأساسي ولا يستبدله؛ ويواصل المستقبل معالجة RCODE من دون التزام بتنفيذ التشخيص.
  • يمثل EDE قول resolver أو forwarder عما رآه، لا برهاناً سببياً من طرف إلى طرف. تستطيع الوسائط إسقاطه أو إنشاءه من جديد، وعند ضيق حجم UDP تُحذف الشروح قبل نتيجة DNS الأساسية.
  • يجب أن تربط سلسلة الدليل bytes الخام، والعقدة المرسلة، وRCODE، وحالة cache، ومحاولات upstream، ومسار DNSSEC، وقاعدة policy، وإعادة المحاولة، والتأكيد المستقل. لا ينبغي لرمز واحد أن يعطل التحقق أو يختار resolver أقل أمناً.

حين يبدو اسم العطل كأنه حكم

كان SERVFAIL غامضاً: قد يكون validator وجد توقيعاً منتهياً، أو فقد resolver الوصول إلى authority، أو منعت policy محلية النتيجة. جاء EDE ليجعل هذه الفروق قابلة للنقل.

لكن شاشة تقول «DNSSEC Bogus» تخفي جهة النظر. قد يكون القرار ناتجاً من trust anchor مختلف، أو ساعة خاطئة، أو cache قديم، أو نسخة برمجية بعينها، أو حكماً ورثه forwarder من upstream. الوصف يجعل الواقعة قابلة للبحث، ولا يستبعد الأسباب المنافسة.

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

عقدان داخل option صغير

يعرّف RFC 8914 EDE باعتباره EDNS option code 15. يحمل أول octetين INFO-CODE، ويمكن للباقي أن يحمل EXTRA-TEXT للبشر. لا ينبغي للبرنامج تحويل النص إلى أوامر. قد تحتوي الإجابة أكثر من EDE، وقد يظهر الخيار مع أي RCODE بما في ذلك NOERROR.

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

يسجل IANA مفردات مشتركة. عرّف RFC 8914 في البداية الرموز من 0 إلى 24 لفئات DNSSEC وstale answer وforged وblocked وcensored وfiltered وprohibited وأخطاء الشبكة وتعذر بلوغ authority. استمر السجل في التوسع، مع مجالات عامة وخاصة. التسجيل ينسق معنى الرقم، ولا يصادق دقة كل واقعة.

تتغير نسبة التشخيص عند كل forwarder

قد يمر الطلب من stub إلى forwarder مؤسسي ثم filter ثم recursive resolver قبل authority. يسمح RFC 8914 للـ forwarder بإسقاط EDE الوارد أو إنشاء EDE وفق معالجته الخاصة. وإذا نقل معلومة upstream فمن الأفضل أن ينسب المصدر في النص.

هذه المرونة ضرورية للنشر، لكنها تجعل provenance شرطاً. حفظ آخر code فقط يمحو الفرق بين مشاهدة مباشرة ونتيجة موروثة وإعادة إنشاء. يلزم ربط الرمز بالعملية والendpoint والعقدة والنسخة وtransport ومحاولة upstream والقاعدة التي أطلقته وترتيب الخيارات كاملاً.

توثيق القناة يعالج سؤالاً آخر. قد يثبت DNS مشفراً أو موثقاً هوية peer على تلك القفزة، لكنه لا يثبت صحة تفسيره لعطل بعيد. وفي UDP أو TCP غير المحمي يمكن لفاعل on-path تغيير الخيار. سلامة القناة ليست سلطة سببية.

قد تختفي الشروح قبل الفشل

يوفر EDNS في RFC 6891 مساحة options، لكن لحزمة UDP ميزانية. عند تجاوز الحجم يطلب RFC 8914 حذف EXTRA-TEXT أولاً ثم EDE، وإن بقيت الإجابة كبيرة يُستخدم TC وفق DNS. لذلك قد تحتفظ الحزمة بـ SERVFAIL وتفقد السبب المعلن.

غياب EDE لا يثبت غياب التشخيص، ووجوده لا يثبت أن كل hop رأى الرسالة نفسها. يجب أن تختبر canary غياب الخيار، ورمزاً واحداً أو عدة رموز، وعكس الترتيب، والقيم المجهولة والخاصة، والنص الفارغ والطويل، وUTF-8 غير الصالح، والحذف في UDP، وإعادة TCP، وforwarder الذي يحفظ أو يسقط أو يعيد الإنشاء.

EXTRA-TEXT دليل محتمل وتسريب محتمل

قد يشرح النص الحر policy، وقد يكشف رقم حساب أو اسم عميل أو blocklist داخلية أو عنوان backend أو حكماً أمنياً لم يعلن. وقد يتضمن control characters أو bidi sequence تضلل واجهة أو log. يشير RFC 8914 صراحة إلى مخاطر الخصوصية.

يحفظ مستودع الدليل bytes الأصلية بصلاحيات ضيقة. تعرض واجهة المحلل نسخة مفكوكة بأمان. أما الواجهة العامة فتستخدم أقل قدر من النص بعد التنقية. يجب تحديد مدة retention، وألا تُستخرج أوامر آلية من EXTRA-TEXT.

Running code يربط EDE بسياسات حقيقية

يتيح Unbound إصدار EDE وشرح serve-expired وتشغيل DNS Error Reporting في RFC 9567. يستطيع BIND إرفاق forged أو blocked أو censored أو filtered أو prohibited بنتائج Response Policy Zone. ويرسل PowerDNS Recursor extended resolution errors ويشرح تطبيق Negative Trust Anchor.

يثبت ذلك أن EDE دخل التشغيل، كما يكشف أن سبب الرمز محلي. قد ينشأ code واحد من triggers مختلفة باختلاف المنتج والنسخة والإعداد. يجب أن يتتبع audit القيمة على السلك حتى القاعدة المنفذة، لا أن يتوقف عند اسم RFC.

يعرض RFC 8767 الفصل نفسه مع stale data. يستطيع EDE شرح قدم الإجابة، لكن مدة السماح وشروطه ونقطة الإيقاف تبقى policy لدى resolver. الشرح لا يمنح إذناً لخدمة بيانات قديمة بلا حدود.

RESINFO وReport-Channel يزيدان الرؤية والمسؤولية

يسمح RFC 9606 بإعلان الرموز المدعومة في خاصية exterr ضمن RESINFO. يساعد الإعلان في اكتشاف القدرات، لكن اختلاف عقد anycast أو النسخ أو الإعدادات قد يجعله غير دقيق. يظل قرار استعماله محلياً لدى client.

يرمز RFC 9567 عناصر QTYPE وQNAME وEDE في query تقرير جديد كي يرى مشغل authority فشل validator. يمكن أن يسرع الإصلاح، لكنه ينشئ كلفة وتكراراً ومخاطر خصوصية؛ لذلك يجب ضبط العمق والحجم. لا توفر القناة mutual authentication. يرفع TCP أو DNS Cookies الثقة في المصدر، ولا يثبت صدق المحتوى.

قوة التصميم في طبقته المشتركة الرقيقة: option وسجل ورقابة أساسية مشتركة، ثم قرارات العرض والاحتفاظ والتنبيه والتقرير وfallback محلية. يثبت packet canary وrunning code ما يحدث فعلاً في كل نسخة وعقدة.

المصادر