تست DNS با nslookup؛ پاسخ، timeout و محدودیت نتیجه را چطور بخوانیم؟

۰ دیدگاه ۷ دقیقه مطالعه ۰ بازدید
نویسنده

SickDNS

نویسنده وبلاگ SickDNS

nslookup کمک می‌کند ببینید یک حل‌کنندهٔ DNS به پرس‌وجوی یک نام چه پاسخی می‌دهد. برای شروعِ تشخیص مفید است، اما پاسخ موفق آن به معنی بازشدن بازی، فعال‌بودن اشتراک SickDNS یا پینگ مناسب مسابقه نیست.

در این راهنما، دستورها برای Command Prompt یا PowerShell در ویندوز ۱۰ و ۱۱ نوشته شده‌اند. خود این پرس‌وجوها تنظیم DNS ویندوز را تغییر نمی‌دهند. ابتدا نام مورد آزمون و حل‌کننده را مشخص می‌کنیم، سپس خروجی و خطا را می‌خوانیم.

با یک نام عمومی و تنظیم پیش‌فرض شروع کنید

Command Prompt یا PowerShell را باز کنید و دستور زیر را اجرا کنید. example.com در این راهنما نام نمونه است؛ نتیجهٔ آن را معادل دسترسی به دامنه‌های موردنیاز بازی نگیرید. برای تکرار یک خطای بازی، نام دقیق مرتبط باید از راهنمای رسمی یا بررسی فنی معتبر مشخص باشد؛ آن را از نام تجاری بازی حدس نزنید.

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

nslookup example.com

برای مقایسه، حل‌کننده را صریح مشخص کنید

طبق مستند Microsoft، آرگومان اول نام مورد پرس‌وجو و آرگومان دوم نام یا آدرس سرور DNS است. در مثال زیر، 8.8.8.8 آدرس عمومی Google Public DNS است؛ آدرس SickDNS نیست. این دستور همان پرس‌وجو را به مقصد مشخص می‌فرستد و DNS کل دستگاه را روی گوگل قرار نمی‌دهد.

برای آزمون SickDNS، به‌جای آدرس نمونه، آدرس رسمی نمایش‌داده‌شده در حساب خود را وارد کنید. اعتبار و IP ثبت‌شده را جدا بررسی کنید. داشتن پاسخ از یک نام عمومی، به‌تنهایی وضعیت مجوز استفاده از مسیرهای منتخب سرویس را معلوم نمی‌کند.

nslookup -type=A example.com 8.8.8.8

سند رسمی دستور nslookup در Windows

نشانی حل‌کننده را با آدرس دامنهٔ مورد پرس‌وجو اشتباه نگیرید

در خروجی، Server و Address ابتدای متن به حل‌کنندهٔ مورد پرس‌وجو مربوط‌اند. Name و Address یا Addresses در بخش پاسخ، نتیجهٔ نام مورد آزمون را نشان می‌دهند. اگر در پاسخ چند آدرس دیدید، آن‌ها را فهرست DNSهایی که باید در تنظیمات دستگاه وارد شوند حساب نکنید.

خروجی زیر صرفاً نمونهٔ آموزشی ساخته‌شده برای نمایش ساختار است؛ از اجرای واقعی این دستور یا آزمون SickDNS گرفته نشده و آدرس 192.0.2.10 در آن آدرس نمونه است. پاسخ واقعی نام و حل‌کنندهٔ شما ممکن است شکل یا تعداد آدرس متفاوتی داشته باشد.

Server:  resolver.example
Address:  192.0.2.53

Non-authoritative answer:
Name:    example.com
Address: 192.0.2.10

Non-authoritative و UnKnown الزاماً نشانهٔ خرابی نیستند

عبارت Non-authoritative answer یعنی پاسخ از سرور مرجع همان دامنه نیامده است؛ یک حل‌کننده می‌تواند با انجام پرس‌وجوهای لازم یا فرستادن درخواست به حل‌کننده‌ای دیگر پاسخ را به دست آورد. بنابراین این عبارت را به معنی «پاسخ نامعتبر» یا «DNS ناامن» نخوانید. از همین برچسب، وضعیت اعتبارسنجی امنیتی پاسخ هم به‌تنهایی مشخص نمی‌شود.

اگر Server با UnKnown نمایش داده شد، این برچسب به‌تنهایی شکست پرس‌وجوی نام را ثابت نمی‌کند؛ در نمونهٔ رسمی Microsoft هم UnKnown در کنار پاسخ موفق دیده می‌شود. نام‌گذاری معکوس آدرس حل‌کننده و رکورد PTR آن یکی از موارد بررسی است. به‌جای توقف روی این کلمه، بخش پاسخ و خطاهای بعدی را هم بخوانید.

نمونهٔ رسمی Microsoft از پرس‌وجوی موفق با Server: UnKnown

رکورد A و AAAA را جدا امتحان کنید

رکورد A آدرس IPv4 و رکورد AAAA آدرس IPv6 را درخواست می‌کند. اگر بررسی شما دربارهٔ IPv4 است، نوع رکورد را صریح A بگذارید؛ برای IPv6 از AAAA استفاده کنید. نبودن رکورد یک نوع، الزاماً به معنی نبودن کل دامنه نیست.

در دو دستور زیر، نام و حل‌کننده یکسان‌اند و فقط نوع پرس‌وجو فرق می‌کند. وجود پاسخ AAAA به‌تنهایی ثابت نمی‌کند اتصال IPv6 دستگاه تا آن مقصد کار می‌کند؛ اینجا فقط پاسخ DNS را بررسی کرده‌اید.

nslookup -type=A example.com 8.8.8.8
nslookup -type=AAAA example.com 8.8.8.8

timeout، NXDOMAIN و خطای سرور را یکسان نخوانید

timeout یعنی یک درخواست در زمان انتظار و تلاش‌های تعیین‌شده پاسخ نگرفته است. این مشاهده می‌تواند سرنخ مشکل دسترسی یا پاسخ‌گویی باشد، اما علت نهایی و وضعیت اشتراک را مشخص نمی‌کند. نام پرس‌وجو، مقصد و زمان را ثبت و آزمون را تکرار کنید؛ افزایش زمان انتظار هم به‌خودی‌خود تعمیر اتصال نیست.

گاهی قبل از یک پاسخ، پیام timeout دیده می‌شود. کل خروجی و نوع پرس‌وجو را نگه دارید؛ وجود پاسخ نهایی را نادیده نگیرید و در عین حال، پیام قبلی را هم موفقیت بی‌نقص حساب نکنید. برای تشخیص دقیق‌تر، باید معلوم شود کدام درخواست پاسخ نگرفته است.

پیام یا وضعیت برداشت محدود و درست بررسی بعدی
Nonexistent domain / NXDOMAIN پاسخ منفی دربارهٔ نام پرس‌وجوشده املای نام و پرس‌وجوی دقیق را بررسی کنید؛ پاسخ منفی با timeout فرق دارد
No records برای نوع رکورد درخواستی داده‌ای برنگشته است A و AAAA و نام موردنظر را جدا بررسی کنید
Server failure / SERVFAIL حل‌کننده نتوانسته پاسخ معتبر برگرداند خطا، نام، نوع رکورد و مقصد را ثبت کنید؛ علت از این پیام تنها معلوم نیست
Refused سرور از پاسخ‌گویی به درخواست خودداری کرده است سیاست دسترسی و اعتبار/IP را بررسی کنید؛ دلیل را قطعی فرض نکنید
timed out درخواست در مهلت و تلاش‌های مشخص پاسخ نگرفته تکرار روی همان نام و مقصد؛ سپس مقایسهٔ کنترل‌شده

از خروجی تا قدم بعدی، فقط همان چیزی را نتیجه بگیرید که سنجیده‌اید

اگر پاسخ نام درست برمی‌گردد ولی برنامه هنوز باز نمی‌شود، مرحلهٔ بعد بررسی خود برنامه، حساب، سرورها و مقصدهای موردنیاز آن است. موفقیت یک نام عمومی، سلامت همهٔ دامنه‌های بازی یا مسیر مسابقه را تأیید نمی‌کند. همچنین nslookup ابزار اثبات فعال‌بودن DoH یا DoT در مرورگر نیست.

اگر نیاز به تغییر تنظیمات Windows دارید، از راهنمای تنظیم DNS استفاده کنید؛ دستورهایی که اینجا اجرا کردید تغییری برای بازگرداندن ایجاد نکرده‌اند. برای گزارش مشکل، دستور دقیق، خروجی کامل، نسخهٔ ویندوز، زمان، اینترنت و مرحلهٔ خطا را نگه دارید. پیش از فرستادن تصویر یا متن، اطلاعات شخصی و نام‌های داخلی شبکه را از نسخهٔ عمومی حذف کنید.

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

راهنمای تنظیم و بازگرداندن DNS در ویندوز

پیگیری نتیجهٔ تست و خطای اتصال از پشتیبانی

سوالات متداول

پرس‌وجوهای این راهنما تنظیم سراسری DNS را عوض نمی‌کنند. آرگومان دوم، سرور مورد استفادهٔ همان دستور را مشخص می‌کند.

خیر. این برچسب می‌گوید پاسخ از سرور مرجع دامنه نیامده است؛ حل‌کننده می‌تواند با انجام پرس‌وجوهای لازم یا فرستادن درخواست به حل‌کننده‌ای دیگر آن را فراهم کند. برچسب به‌تنهایی خطا یا وضعیت امنیت پاسخ را ثابت نمی‌کند.

خیر. آن پاسخ به نام، نوع رکورد و حل‌کنندهٔ همان پرس‌وجو مربوط است. اعتبار، IP ثبت‌شده و عملکرد مرحلهٔ موردنیاز بازی باید جدا بررسی شوند.

مقاله‌های مرتبط

دیدگاه کاربران (۰)

هنوز دیدگاهی برای این مقاله ثبت نشده است.