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 رکوردی که تغییر دادید صبر کنید.

تأیید کنید که پاسخ از هر مرجع پایدار است، و دید موردنظر را در مستندات منطقه بنویسید تا تفاوت بعدی آسان طبقه‌بندی شود.