اول تعیین کنید اصلاً پای DNS در میان است یا نه

جمله «سایت باز نمی‌شود» طیف بزرگی از خرابی‌ها را می‌پوشاند و DNS تنها یکی از لایه‌های آن است. تطبیق دادن نشانه با علت، بیشتر حدس‌وگمان را حذف می‌کند.

  • یک سایت خارجی به 127.0.0.1 یا 0.0.0.0 یا نشانی‌ای می‌رسد که هیچ ربطی به آن سرویس ندارد. نمونه کلاسیک آلودگی پاسخ.
  • بار اول چند ثانیه معطل می‌ماند و بعد همه چیز عادی است: یکی از سرورها جواب نمی‌دهد و پرس‌وجو پس از انقضای مهلت دوباره تلاش می‌کند.
  • بعضی نام‌ها باز نمی‌شوند اما همان سرویس با نشانی IP در دسترس است. مسیر سالم است و کار در مرحله تبدیل نام می‌شکند.
  • پروکسی روشن است و چند سایت باز نمی‌شوند. شاید تبدیل نام بیرون از پروکسی انجام شود، یا اصلاً ربطی به DNS نداشته باشد.
پیشنهاد همکاریلینک اشتراک را از کجا بیاوریم؟سرویس همکار ما هنگام ثبت‌نام ۱ گیگابایت ترافیک پرسرعت هنگ‌کنگ رایگان می‌دهد.دریافت سرور پرسرعت

یک نام را از دو سرور بپرسید

سریع‌ترین آزمون این است که یک نام را دو بار بپرسید: یک بار از هر DNS که سیستم اکنون به کار می‌برد و یک بار از سروری عمومی که خودتان نام می‌برید.

nslookup www.example.com
nslookup www.example.com 8.8.8.8
dig +short www.example.com @1.1.1.1

اگر یک طرف نشانی قابل استفاده بدهد و طرف دیگر 127.0.0.1 یا محدوده‌ای بی‌ربط، شاهد محکمی دارید که مسیر پیش‌فرض دستکاری می‌شود. یک هشدار: پرسش رمزنگاری‌نشده روی درگاه 53 از 8.8.8.8 هم در راه قابل جعل است، پس این مقایسه فقط تفاوت را ثابت می‌کند، نه درستی پاسخ دوم را.

اگر هر دو طرف یک جواب بدهند ولی هر دو کند باشند، محتوای پاسخ مشکل نیست، مسیر مشکل است. nslookup پس از انقضای مهلت دوباره تلاش می‌کند، پس دستوری که چند ثانیه طول می‌کشد تا چیزی چاپ کند خودش نشانه است.

با Fake-IP، نشانی قرار است جعلی باشد

وقتی dns.enhanced-mode روی fake-ip باشد، سیستم یک نشانی جای‌نگهدار می‌گیرد که هسته همان لحظه از محدوده fake-ip-range می‌سازد و معمولاً 198.18.0.0/16 است. دیدن 198.18.x.x آلودگی نیست؛ جست‌وجوی واقعی سمت گره انجام می‌شود.

پس nslookup در سطح سیستم اینجا تقریباً بی‌فایده است، چون در هر حال همان جای‌نگهدار برمی‌گردد و ping کردنش چیزی ثابت نمی‌کند. برای نتیجه واقعی، نام مقصد و خروجی آن اتصال را در فهرست اتصال‌ها بخوانید یا برای یک آزمون به redir-host برگردید.

کش، DoH مرورگر، و پاسخی که درست به نظر می‌رسد

  1. بعد از هر تغییر در DNS کش را پاک کنید. ویندوز ipconfig /flushdns دارد؛ macOS به همان روال mDNSResponder نیاز دارد که دستور دقیقش بین نسخه‌ها عوض شده؛ در لینوکس بستگی دارد systemd-resolved اجرا می‌کنید یا dnsmasq. بدون این کار دارید رکورد قدیمی را آزمایش می‌کنید.
  2. مرورگرها خودشان تبدیل نام انجام می‌دهند. Secure DNS در Chrome و DNS over HTTPS در Firefox از سرور سیستم عبور می‌کنند؛ هنگام عیب‌یابی خاموششان کنید وگرنه خط فرمان و مرورگر دو دنیای متفاوت را توصیف می‌کنند.
  3. کلاینت هم کش دارد. بعد از ویرایش nameserver یا nameserver-policy پیکربندی را دوباره بارگذاری و اتصال‌های قدیمی را ببندید.

یک حالت را باید جدا کرد: nslookup یک IP کاملاً معمولی می‌دهد و مرورگر باز هم صفحه را نمی‌آورد. یعنی تبدیل نام موفق بوده است. حالا ببینید آن اتصال با کدام قاعده منطبق شده، از کدام خروجی رفته و خود گره سالم است یا نه.

هنگام عیب‌یابی سه چیز را با هم عوض نکنید. کش را پاک کنید، یک تنظیم را تغییر دهید، دوباره آزمایش کنید. وگرنه روزی که درست شد نمی‌دانید کدام تغییر کار کرده و دفعه بعد دقیقاً همان‌جا گیر می‌کنید.