هل DNS عبر VPN خاطئ؟ قد يكون أحد الخوادم المرجعية قديمًا

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

تتغيّر الأعراض مع المُحلِّل

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

لهذا قد يعمل الاسم نفسه في مكتب ويفشل من فندق، ولهذا لا يفيد مسح الذاكرة المحلية إلا أحيانًا. فمسح الذاكرة يعيد إرسال السؤال إلى المرجع نفسه.

الاختبار الفاصل هو استعلام مباشر إلى كل خادم منشور.

استعلم من كل مرجع مباشرةً

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

dig +short NS example.com
dig @ns1.dns.example app.example.com A
dig @ns2.dns.example app.example.com A

افعل الشيء نفسه لسجلات NS عند قمة المنطقة، لأن تفويض الأب ومجموعة NS الخاصة بالمنطقة قد يختلفان بعد الترحيل. الأرقام التسلسلية في SOA هي الشيء التالي للمقارنة، والخادم الثانوي المتأخر كثيرًا مشكلة نقل لا مشكلة جواب.

نفّذ تلك الاستعلامات من الشبكة التي تفشل، لا من مكتبك فقط.

افصل الآراء المقصودة عن المعطوبة

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

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

الخادم الذي يجيب بـ SERVFAIL أسهل في التشخيص من خادم يجيب بثقة وبشكل خاطئ.

الترحيل يكشف ما أخفته الذاكرة

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

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

تغيير المُحلِّل على حاسوب محمول يصلح ذلك الحاسوب ولا شيء غيره.

أصلح المنطقة، لا المُحلِّل

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

ثم أعد تشغيل الاستعلامات المباشرة من كلتا الشبكتين وانتظر انتهاء TTL للسجل الذي غيّرته.

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