رفع خطای DNS اتصال ویندوز به دامین

اگر هنگام اتصال کامپیوتر ویندوزی به دامین با خطای DNS روبه‌رو می‌شوید، ابتدا بررسی کنید DNS کلاینت بتواند رکوردهای دامین داخلی را پاسخ دهد. باز شدن اینترنت یا پاسخ گرفتن از IP سرور، به‌تنهایی پیدا شدن Domain Controller را ثابت نمی‌کند. در این راهنما، تنظیمات کلاینت، رکورد SRV و نام سرور را جداگانه آزمایش می‌کنیم تا محل اختلال مشخص شود.

این راهنما چه مشکلی را حل می‌کند؟

تمرکز این مقاله خطای 0xa8b و وضعیت‌هایی است که ویندوز نمی‌تواند نام DNS کنترل‌کننده دامین را پیدا کند. اگر رکوردها درست پاسخ داده می‌شوند اما اتصال با خطای مجوز یا حساب کامپیوتر متوقف می‌شود، باید مسیر عیب‌یابی دیگری را دنبال کنید. برای بررسی مشکلات گسترده‌تر، راهنمای عیب‌یابی شبکه کامپیوتری را بخوانید.

قبل از شروع، اطلاعات واقعی شبکه را آماده کنید

نام کامل دامین Active Directory، IP سرور DNS داخلی و نام کارت شبکه فعال را از مدیر شبکه بگیرید. در مثال آموزشی این مقاله، دامین ad.example.com و DNS داخلی 192.168.10.10 است. این مقادیر صرفاً مثال هستند؛ در دستورها باید نام و آدرس واقعی شبکه خودتان را جایگزین کنید.

۱. DNS تمام کارت‌های شبکه فعال را بررسی کنید

Command Prompt را باز کنید و دستور زیر را اجرا کنید:

ipconfig /all

در کارت متصل به شبکه شرکت، بخش DNS Servers را پیدا کنید. کارت Wi-Fi، کارت VPN و تنظیمات IPv6 را هم بررسی کنید؛ وجود چند رابط فعال می‌تواند مسیر بررسی را پیچیده کند. هدف، پیدا کردن DNSهایی است که واقعاً برای این ارتباط تنظیم شده‌اند، نه خاموش کردن تصادفی رابط‌ها.

DNS عمومی یا DNS مودمی که دامین داخلی را نمی‌شناسد، انتخاب مناسبی برای پیدا کردن کنترل‌کننده دامین نیست. همه DNSهای مورد استفاده باید بتوانند نام‌ها و رکوردهای AD را درست پاسخ دهند. DNS دوم هم نباید صرفاً برای باز شدن اینترنت یک DNS عمومی باشد. رفع نام‌های اینترنتی را در زیرساخت DNS داخلی بررسی کنید.

۲. رکورد سرویس دامین را از DNS داخلی بپرسید

در Command Prompt، درخواست را مستقیماً به DNS داخلی بفرستید:

nslookup -type=SRV _ldap._tcp.dc._msdcs.ad.example.com 192.168.10.10

پاسخ باید اطلاعات رکورد SRV و نام میزبان کنترل‌کننده دامین را نشان دهد. هیچ خروجی نمونه‌ای را معیار نام سرور خودتان قرار ندهید؛ نام برگشتی باید متعلق به زیرساخت واقعی شرکت باشد.

Timeout: پاسخ در زمان انتظار دریافت نشده است؛ مسیر شبکه، سرویس DNS و فیلترهای بین کلاینت و سرور را بررسی کنید.
Non-existent domain یا نبود رکورد: نام پرس‌وجو، Zone و رکوردهای AD را بررسی کنید. اشتباه تایپی هم می‌تواند همین نتیجه را ایجاد کند.
پاسخ SRV معتبر: به مرحله بررسی نام میزبان بروید؛ این پاسخ هنوز موفقیت کامل اتصال به دامین را ثابت نمی‌کند.

۳. نام کنترل‌کننده دامین را جداگانه آزمایش کنید

نام میزبان برگشتی از مرحله قبل را از همان DNS بپرسید. اگر نام برگشتی dc01.ad.example.com بود، دستور آموزشی چنین است:

nslookup dc01.ad.example.com 192.168.10.10

IP برگشتی باید درست و از شبکه کلاینت قابل دسترسی باشد. وجود رکورد قدیمی یا آدرس یک کارت شبکه غیرقابل دسترسی، نیازمند بررسی مدیر سرور است. در PowerShell نیز می‌توانید رکورد IPv4 را دقیق‌تر درخواست کنید:

Resolve-DnsName -Name dc01.ad.example.com -Type A -Server 192.168.10.10 -DnsOnly

در محیط IPv6، رکورد AAAA و مسیر IPv6 را هم بررسی کنید؛ این مقاله توصیه به غیرفعال کردن IPv6 برای دور زدن مشکل نمی‌کند.

۴. نتیجه DNS داخلی را با تنظیمات فعلی کلاینت مقایسه کنید

این بار همان درخواست SRV را بدون مشخص کردن سرور اجرا کنید:

nslookup -type=SRV _ldap._tcp.dc._msdcs.ad.example.com

اگر پرس‌وجوی مستقیم موفق بود ولی این درخواست شکست خورد، تنظیمات DNS کلاینت، DHCP یا رابط VPN را بررسی کنید. توجه کنید nslookup ابزار پرس‌وجوی DNS است و تمام رفتار نام‌یابی برنامه‌های ویندوز را بازسازی نمی‌کند؛ از آن برای محدود کردن محل مشکل استفاده کنید.

۵. تنظیمات اشتباه را در محل درست اصلاح کنید

برای کلاینتی با DNS دستی، کلیدهای Win+R را بزنید، ncpa.cpl را اجرا کنید و Properties کارت فعال را باز کنید. در تنظیمات TCP/IPv4، آدرس DNS داخلی تأییدشده را وارد کنید. پیش از تغییر، تنظیمات قبلی را ثبت کنید تا امکان بازگشت داشته باشید.

اگر DNS از DHCP دریافت می‌شود و چند کلاینت همین مشکل را دارند، مدیر شبکه باید تنظیمات DNS در Scope مربوط را بررسی کند. تغییر دستی یک کامپیوتر مشکل توزیع تنظیمات را برای بقیه حل نمی‌کند. در اتصال راه دور نیز مسیر رسیدن به DNS داخلی باید برقرار باشد.

۶. کش را پاک کنید و دوباره آزمایش کنید

پس از اصلاح تنظیمات، Command Prompt را با دسترسی مدیر باز کنید:

ipconfig /flushdns

این دستور کش نام‌یابی کلاینت را پاک می‌کند؛ رکورد حذف‌شده سرور یا مسیر قطع‌شده را تعمیر نمی‌کند. درخواست‌های مراحل قبل را تکرار کنید و سپس اتصال به دامین را با نام کامل DNS دامین دوباره انجام دهید. برای پاک کردن کش، اجرای release ضروری نیست و ممکن است ارتباط شبکه را قطع کند.

چه زمانی مشکل را به مدیر Windows Server ارجاع دهیم؟

اگر DNS داخلی رکورد SRV یا نام کنترل‌کننده دامین را درست پاسخ نمی‌دهد، بررسی Zoneهای AD، رکوردهای میزبان، سرویس DNS و ثبت رکوردهای کنترل‌کننده دامین لازم است. حذف Zone یا ساخت رکوردهای حدسی، اقدام مناسبی برای رفع سریع مشکل نیست. برای شناخت نقش سرویس‌ها، راهنمای راه‌اندازی سرور سازمانی را ببینید.

برای ارجاع، زمان خطا، متن دقیق آن، خروجی ipconfig /all، نتیجه دو پرس‌وجوی DNS و وضعیت اتصال VPN را آماده کنید. اطلاعات داخلی را در کانال عمومی منتشر نکنید. اگر تست‌های DNS موفق‌اند اما اتصال همچنان شکست می‌خورد، گزارش اتصال دامین در مسیر زیر به تشخیص مرحله بعد کمک می‌کند:

C:\Windows\Debug\NetSetup.log

پرسش‌های رایج

چرا اینترنت دارم ولی کامپیوتر به دامین متصل نمی‌شود؟

DNS مورد استفاده ممکن است نام‌های عمومی را پاسخ دهد اما رکوردهای دامین داخلی را نشناسد. درخواست SRV به DNS داخلی و سپس بررسی نام کنترل‌کننده دامین، این دو مسئله را از هم جدا می‌کند.

آیا Ping موفق به سرور یعنی DNS سالم است؟

خیر. Ping به IP، نام و رکورد SRV دامین را آزمایش نمی‌کند. حتی پاسخ DNS درست هم به‌تنهایی سلامت تمام سرویس‌های لازم برای اتصال به دامین را تضمین نمی‌کند.

آیا flushdns همیشه مشکل را حل می‌کند؟

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

آیا باید همه خطاهای اتصال دامین را مشکل DNS بدانیم؟

خیر. پس از تأیید پاسخ رکوردها، خطاهای مجوز، حساب کامپیوتر و ارتباط با سرویس‌های دامین باید بر اساس متن خطا و گزارش اتصال بررسی شوند.

منابع رسمی و تاریخ بررسی

دستورها و مسیر عیب‌یابی در ۳ اکتبر ۲۰۲۶ با مستندات رسمی Microsoft بررسی شدند: