NXDOMAIN عبر VPN لا يعني انقطاع النفق

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

ما الذي تُثبته الإجابة فعلاً

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

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

الخرافة: اسم خاص مفقود يعني فشل النفق

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

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

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

اسأل المُحلِّل الصحيح بالاسم الصحيح

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

resolvectl query vpn.internal.example
resolvectl status | grep -A3 'DNS Servers'
dig +search app.intranet.example A
dig @10.8.0.1 app.intranet.example A

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

التخزين المؤقت السلبي يفسر التأخير بعد الإصلاح

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

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

افصل الاسم عن المسار

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

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