رفع مشکل DNS در Windows Server؛ آموزش عیب‌یابی Server، Forwarder و Client

اگر کلاینت‌های شبکه به IP دسترسی دارند اما نام دامنه یا نام سرورها Resolve نمی‌شود، با تغییر تصادفی DNS یا Restart کردن سرویس‌ها شروع نکنید. در Windows Server بهتر است مسیر عیب‌یابی را از تنظیم IP و خود سرویس DNS آغاز کنید، سپس authoritative zone، رکوردها، recursion و Forwarder را جداگانه تست کنید. این راهنما یک مسیر عملی برای پیدا کردن محل خرابی و رفع آن ارائه می‌دهد.

خلاصه مسیر عیب‌یابی DNS در Windows Server

1. روی DNS Server با ipconfig /all آدرس IP، Gateway و DNSهای تنظیم‌شده را بررسی کنید.
2. از فعال بودن سرویس DNS مطمئن شوید.
3. با nslookup مستقیماً همان DNS Server را Query کنید.
4. مشخص کنید نام موردنظر داخل Zone محلی است یا باید از طریق Recursion/Forwarder Resolve شود.
5. Zone، رکوردهای A/AAAA/CNAME و Forwarderها را بررسی کنید.
6. Cache را فقط بعد از ثبت وضعیت فعلی پاک کنید و دوباره تست بگیرید.
7. در پایان از خود Server و یک Client واقعی Verify کنید.

سناریوی واقعی: اینترنت با IP باز می‌شود ولی نام دامنه Resolve نمی‌شود

فرض کنید یک Windows Server با IP فرضی 10.0.0.10 نقش DNS دارد. کلاینت‌ها می‌توانند 1.1.1.1 را Ping کنند، اما example.com یا یک نام داخلی مانند app1.corp.local Resolve نمی‌شود. این سناریو معمولاً به یکی از این دسته‌ها برمی‌گردد: پیکربندی IP اشتباه، توقف سرویس DNS، رکورد یا Zone اشتباه، مشکل Recursion/Forwarder، Cache قدیمی یا تنظیم DNS اشتباه روی Client.

برای درک تفاوت Cache و پاسخ‌گویی DNS، مقاله DNS Caching چیست؟ نیز مرتبط است.

پیش‌نیازها و نکات احتیاطی

• دسترسی Administrator به Windows Server.
• دانستن IP واقعی DNS Server و نام Zone داخلی.
• ثبت تنظیمات فعلی Forwarder و Zone قبل از هر تغییر.
• اگر سرور Domain Controller است، DNS را بدون شناخت ساختار Active Directory حذف یا Reinstall نکنید.
• در محیط Production، قبل از حذف رکورد، Zone یا تغییر Forwarder از تنظیمات فعلی خروجی بگیرید.

مرحله 1: تنظیم IP سرور DNS را بررسی کنید

مستندات Microsoft اولین مرحله را بررسی IP configuration می‌داند. در Command Prompt با دسترسی Administrator اجرا کنید:

ipconfig /all

آدرس IP، Subnet Mask، Default Gateway و DNS Servers را بررسی کنید. یک DNS Server سازمانی معمولاً باید IP ثابت داشته باشد. اگر سرور به خودش یا DNS داخلی دیگری وابسته است، تغییر بی‌دلیل DNS کارت شبکه به Resolver عمومی می‌تواند نام‌های داخلی Active Directory را خراب کند.

برای دیدن تنظیم DNS با PowerShell:

Get-DnsClientServerAddress -AddressFamily IPv4

خروجی را با NIC فعال و طراحی واقعی شبکه تطبیق دهید.

مرحله 2: وضعیت سرویس DNS را بررسی کنید

در PowerShell:

Get-Service DNS

خروجی سالم باید وضعیت Running را نشان دهد. اگر سرویس متوقف است، قبل از Start کردن علت را در Event Viewer بررسی کنید. سپس در صورت مناسب بودن:

Start-Service DNS

برای Verify:

Get-Service DNS | Select-Object Status,Name,DisplayName

اگر با PowerShell کمتر آشنا هستید، مقاله بررسی PowerShell و کاربردهای آن برای دستورات مدیریتی ویندوز مفید است.

مرحله 3: DNS Server را مستقیم Query کنید

Microsoft برای جدا کردن مشکل Client از Server پیشنهاد می‌کند Query را مستقیماً به DNS Server بفرستید. با IP فرضی 10.0.0.10:

nslookup app1.corp.local 10.0.0.10

برای نام عمومی:

nslookup example.com 10.0.0.10

اگر نام داخلی جواب می‌دهد اما نام عمومی Timeout می‌شود، تمرکز را روی Recursion، Forwarder و دسترسی خروجی DNS بگذارید. اگر هیچ‌کدام جواب نمی‌دهند، سرویس، Firewall، Bind شدن DNS به Interface یا پیکربندی Zone را بررسی کنید.

با PowerShell نیز می‌توانید Query بزنید:

Resolve-DnsName app1.corp.local -Server 10.0.0.10

خروجی موفق باید رکورد و IP مورد انتظار را نشان دهد.

مرحله 4: تشخیص دهید مشکل Authoritative است یا Recursion

این تفکیک بسیار مهم است. اگر DNS Server برای Zone موردنظر Authoritative است، مثلاً corp.local، باید Zone و رکورد همان Zone را بررسی کنید. اگر نام بیرونی مثل example.com است، Server باید از Recursion، Root Hints یا Forwarder استفاده کند.

Zoneهای موجود:

Get-DnsServerZone

یک Zone مشخص:

Get-DnsServerZone -Name "corp.local"

رکوردهای Zone:

Get-DnsServerResourceRecord -ZoneName "corp.local"

برای یک رکورد مشخص:

Get-DnsServerResourceRecord -ZoneName "corp.local" -Name "app1"

IP نمایش‌داده‌شده باید با سرویس واقعی مطابقت داشته باشد.

مرحله 5: Forwarderهای DNS را بررسی کنید

Forwarderهای فعلی:

Get-DnsServerForwarder

اگر Forwarder تعریف شده ولی پاسخ نمی‌دهد، ابتدا دسترسی شبکه به آن را بررسی کنید. توجه کنید DNS معمولاً از UDP/53 استفاده می‌کند و در برخی پاسخ‌ها یا شرایط از TCP/53 هم استفاده می‌شود؛ بنابراین تست فقط TCP به‌تنهایی اثبات نمی‌کند UDP DNS سالم است.

برای تست واقعی DNS بهترین Verify همان Query مستقیم است:

Resolve-DnsName example.com -Server <FORWARDER_IP>

سپس همان نام را از DNS Server داخلی Query کنید:

Resolve-DnsName example.com -Server 10.0.0.10

اگر Query مستقیم Forwarder موفق است ولی Query از DNS داخلی شکست می‌خورد، تنظیم Recursion/Forwarder یا Policyهای خود DNS Server را بررسی کنید.

مرحله 6: Cache سرور را با احتیاط پاک کنید

قبل از پاک کردن Cache، اگر مشکل تکرارشونده است زمان و نام رکورد خراب را یادداشت کنید. سپس طبق مستندات Microsoft می‌توانید در Command Prompt مدیریتی اجرا کنید:

dnscmd /clearcache

یا در PowerShell:

Clear-DnsServerCache -Force

بعد دوباره Query را اجرا کنید:

Resolve-DnsName example.com -Server 10.0.0.10

پاک کردن Cache درمان ریشه‌ای Forwarder خراب یا رکورد اشتباه نیست؛ فقط پاسخ‌های Cache‌شده را حذف می‌کند.

مرحله 7: Client را جداگانه بررسی کنید

روی Client:

ipconfig /all

مطمئن شوید DNS Server همان IP داخلی موردنظر است. سپس Cache کلاینت را پاک کنید:

ipconfig /flushdns

و تست بگیرید:

nslookup app1.corp.local

nslookup example.com

اگر Query با تعیین دستی Server موفق است ولی Query عادی شکست می‌خورد، معمولاً DNS تنظیم‌شده روی NIC، DHCP یا VPN Client متفاوت است.

مرحله 8: لاگ‌ها را بررسی کنید

برای مشاهده Eventهای اخیر DNS Server با PowerShell می‌توانید از لاگ مربوطه استفاده کنید:

Get-WinEvent -LogName "DNS Server" -MaxEvents 50

اگر نام Log در نسخه یا Role شما متفاوت است، ابتدا Event Viewer را بررسی کنید و از حدس زدن نام Log خودداری کنید. به خطاهای startup، zone loading، transfer، recursion و network binding توجه کنید.

خطاهای رایج و معنی آن‌ها

nslookup با IP خود DNS Server جواب می‌دهد، ولی روی Client نه

مشکل به احتمال زیاد سمت Client، DHCP، Firewall بین Client و Server یا DNS تنظیم‌شده روی NIC است.

نام داخلی Resolve می‌شود ولی دامنه‌های اینترنتی نه

Zone محلی سالم است؛ Forwarder، Recursion، Root Hints یا دسترسی خروجی DNS را بررسی کنید.

نام عمومی Resolve می‌شود ولی رکورد داخلی نه

Zone authoritative، نام رکورد، نوع رکورد و IP آن را بررسی کنید. همچنین مطمئن شوید Client به DNS داخلی Query می‌زند نه Resolver عمومی.

بعد از تغییر IP سرور، بعضی کلاینت‌ها هنوز IP قدیمی می‌گیرند

TTL و Cache را بررسی کنید. اگر رکورد authoritative هنوز IP قدیمی دارد، اول رکورد را اصلاح کنید؛ صرفاً Flush کردن Client مشکل رکورد اشتباه را حل نمی‌کند.

تست نهایی و Verify

پس از اصلاح، این چهار تست را انجام دهید:

1. از خود DNS Server یک نام داخلی را مستقیم Query کنید.
2. از خود DNS Server یک نام عمومی را Query کنید.
3. همان دو تست را از یک Client واقعی انجام دهید.
4. IP برگشتی را با سرویس واقعی و رکورد مورد انتظار مقایسه کنید.

نمونه:

Resolve-DnsName app1.corp.local -Server 10.0.0.10
Resolve-DnsName example.com -Server 10.0.0.10

اگر هر دو پاسخ درست دارند، مسیر Server تا Zone و Recursion سالم است. سپس Query عادی Client بدون پارامتر -Server را تست کنید تا مطمئن شوید DHCP/NIC نیز DNS درست را توزیع می‌کند.

Rollback و Recovery

قبل از تغییر Forwarderها، Zone یا رکوردهای حساس، تنظیم فعلی را ثبت کنید. برای نمونه:

Get-DnsServerForwarder | Format-List *
Get-DnsServerZone | Select-Object ZoneName,ZoneType,IsDsIntegrated

اگر پس از تغییر Forwarder مشکل بیشتر شد، مقدارهای قبلی را برگردانید و دوباره Query مستقیم بگیرید. Zone یا رکورد را صرفاً برای تست حذف نکنید؛ در Active Directory-integrated DNS حذف اشتباه می‌تواند روی چند DNS Server Replicate شود.

نکات امنیتی

• DNS Server سازمانی را بدون نیاز برای Recursion عمومی روی اینترنت باز نگذارید.
• پورت 53 را فقط برای شبکه‌ها و مسیرهایی باز کنید که واقعاً نیاز دارند.
• برای نام‌های Active Directory از Resolver عمومی به‌عنوان جایگزین DNS داخلی استفاده نکنید.
• تغییرات Zone و Forwarder را مستندسازی کنید تا Rollback ممکن باشد.
• اگر DNS روی VPS ویندوزی ارائه می‌شود، Firewall و دسترسی شبکه را همراه با خود Role بررسی کنید.

برای سناریوهایی که به سرور با دسترسی مدیریتی کامل نیاز دارند، سرور مجازی وان‌سرور مرتبط است.

جمع‌بندی

رفع مشکل DNS در Windows Server زمانی سریع‌تر و امن‌تر است که مشکل را لایه‌به‌لایه جدا کنید: IP configuration، سرویس DNS، Query مستقیم، Zone و رکورد authoritative، سپس Recursion و Forwarder، و در پایان Client. ipconfig /all، nslookup، Resolve-DnsName، Get-DnsServerZone و Get-DnsServerForwarder ابزارهای اصلی این مسیر هستند. بعد از هر تغییر، از Server و Client واقعی Verify بگیرید و تنظیم قبلی را برای Rollback نگه دارید.