مقدمه 

سیستم نام دامنه (DNS) نقش کلیدی در تبدیل نام‌های قابل‑خواندن برای انسان (مانند `example.com`) به آدرس‌های IP دارد. هر گونه نقص در این تبدیل می‌تواند باعث عدم دسترسی به وب‌سایت‌ها، شکست ارسال ایمیل یا قطع سرویس‌های داخلی شود. PowerShell، به‌عنوان یک محیط خط فرمان شی‌محور، cmdlet `Resolve‑DnsName` را برای پرس‌وجوی DNS فراهم می‌کند؛ این cmdlet خروجی ساختاریافته (آبجکت) می‌دهد که امکان فیلتر، ترکیب و ذخیره‌سازی داده‌ها را به‌صورت بومی فراهم می‌کند. در ادامه به‌صورت گام‌به‌گام به بررسی قابلیت‌های این cmdlet، روش‌های عیب‌یابی و نکات کاربردی می‌پردازیم.

1. ساختار خروجی `Resolve‑DnsName`

هنگامی که `Resolve‑DnsName` اجرا می‌شود، یک یا چند شی از نوع Microsoft.DnsClient.Commands.ResolveDnsNameResponse برمی‌گرداند. مهم‌ترین ویژگی‌های این شی عبارتند از:

– Name – نام دامنه‌ای که پرس‌وجو شده است.

– QueryType – نوع پرس‌وجو (A، AAAA، MX، CNAME و …).

– Type – نوع رکورد DNS که در پاسخ یافت شده (مثلاً `A`).

– TTL – زمان ماندگاری رکورد بر حسب ثانیه.

– IPAddress – آدرس IP (برای رکوردهای A/AAAA).

– Section – بخش پاسخ (Answer، Authority یا Additional).

– Server – آدرس سرور DNS که پاسخ را ارائه داده است.

– Status – وضعیت پاسخ (Success، NoAnswer، ServerFailure و …).

به‌دلیل این ساختار شی‌محور، می‌توانید به‌راحتی با `Select‑Object`، `Where‑Object` یا `Export‑Csv` فقط فیلدهای موردنیاز را استخراج کنید.

2. استفادهٔ پایه

2.1 پرس‌وجوی پیش‌فرض (رکوردهای A/AAAA) 

Resolve-DnsName -Name example.com

این فرمان به‌صورت پیش‌فرض رکوردهای A (IPv4) و AAAA (IPv6) را برای دامنهٔ `example.com` برمی‌گرداند.

2.2 دریافت رکوردهای خاص 

Resolve-DnsName -Name example.com -Type MX

پارامتر `-Type` باعث می‌شود فقط رکوردهای MX (Mail Exchange) برای دامنهٔ موردنظر نمایش داده شوند. سایر مقادیر معتبر شامل `CNAME`, `TXT`, `SRV`, `NS` و … هستند.

2.3 استفاده از سرور DNS دلخواه 

$dnsServers = @('8.8.8.8','1.1.1.1')    Google Public DNS و Cloudflare

Resolve-DnsName -Name example.com -Server $dnsServers

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

3. عیب‌یابی رایج DNS با `Resolve‑DnsName`

3.1 عدم دریافت پاسخ (NoAnswer) 

اگر خروجی `Status` برابر NoAnswer باشد، سرور DNS درخواست را دریافت کرده اما رکوردی برای نام موردنظر پیدا نکرده است. برای رفع این مشکل می‌توانید:

1. بررسی نوشتار نام – اطمینان حاصل کنید که دامنه به‌درستی وارد شده است (مثلاً `www.example.com` در مقابل `example.com`).
2. تغییر سرور DNS – ممکن است سرور محلی شما کشی قدیمی داشته باشد؛ با `-Server` به یک سرور عمومی (مثل 8.8.8.8) سوئیچ کنید.
3. بررسی زون داخلی – در محیط‌های شرکتی، ممکن است رکورد فقط در سرورهای DNS داخلی موجود باشد؛ در این صورت باید از سرور داخلی استفاده کنید.

3.2 خطای ServerFailure 

این وضعیت نشان می‌دهد سرور DNS به‌دلیل مشکل داخلی (مثلاً سرویس DNS متوقف یا بار زیاد) نتوانسته پاسخ دهد. راه‌حل‌ها:

– تست چندین سرور – با `-Server` چند سرور دیگر را امتحان کنید.

– بررسی وضعیت سرویس DNS – در سرور Windows می‌توانید با `Get-Service DNS` وضعیت سرویس را بررسی کنید.

3.3 زمان پاسخ طولانی (High Latency) 

می‌توانید زمان پاسخ را با `Measure-Command` محاسبه کنید:

Measure-Command { Resolve-DnsName -Name example.com -Server 8.8.8.8 }

اگر زمان بیش از چند صد میلی‌ثانیه باشد، ممکن است مشکل شبکه یا بار زیاد بر روی سرور DNS باشد.

3.4 مقایسهٔ نتایج بین سرورها 

برای اطمینان از صحت رکوردها می‌توانید نتایج دو سرور مختلف را مقایسه کنید:

$primary   = Resolve-DnsName -Name example.com -Server 8.8.8.8

$secondary = Resolve-DnsName -Name example.com -Server 1.1.1.1




if ($primary.IPAddress -ne $secondary.IPAddress) {

    Write-Warning "IP addresses differ: $($primary.IPAddress) vs $($secondary.IPAddress)"

}

4. اسکریپت خودکار برای مانیتورینگ DNS

در بسیاری از سازمان‌ها نیاز به نظارت دوره‌ای بر رکوردهای مهم (مانند MX یا NS) وجود دارد. در ادامه یک اسکریپت ساده آورده شده که لیستی از دامنه‌ها را در چند سرور DNS بررسی می‌کند و نتایج را به‌صورت آبجکت نهایی برمی‌گرداند.

--- تنظیمات -------------------------------------------------

$DomainList = @('example.com','contoso.local','mail.google.com')

$DnsServers = @('8.8.8.8','1.1.1.1')

$RecordType = 'MX'           می‌توانید A, AAAA, TXT و ... تغییر دهید

-------------------------------------------------------------




$Results = @()




foreach ($domain in $DomainList) {

    $entry = "" | Select-Object Domain, RecordType, IPAddress, Status, Server, ErrorMessage




    try {

        $response = Resolve-DnsName -Name $domain -Type $RecordType `

                    -Server $DnsServers -ErrorAction Stop




        $entry.Domain       = $domain

        $entry.RecordType   = $RecordType

        $entry.IPAddress    = ($response.IPAddress -join ',')

        $entry.Status       = 'Success'

        $entry.Server       = ($response.Server -join ',')

        $entry.ErrorMessage = ''

    }

    catch {

        $entry.Domain       = $domain

        $entry.RecordType   = $RecordType

        $entry.IPAddress    = ''

        $entry.Status       = 'Failed'

        $entry.Server       = ''

        $entry.ErrorMessage = $_.Exception.Message

    }




    $Results += $entry

}




 نمایش جدول خلاصه

$Results | Format-Table -AutoSize




 ذخیره به CSV (اختیاری)

 $Results | Export-Csv -Path 'DnsMonitor.csv' -NoTypeInformation

این اسکریپت می‌تواند به‌صورت زمانبندی‌شده (مثلاً با Task Scheduler) اجرا شود و خروجی CSV را برای تحلیل‌های بعدی یا ارسال ایمیل هشدار استفاده کند.

5. نکات پیشرفته

5.1 استفاده از پارامتر `-DnsOnly` 

اگر می‌خواهید فقط پاسخ‌های DNS را بدون انجام پرس‌وجوی نام (Name Resolution) دریافت کنید، از `-DnsOnly` استفاده کنید:

Resolve-DnsName -Name example.com -DnsOnly

5.2 استخراج رکوردهای متنی (TXT) برای بررسی SPF یا DKIM 

Resolve-DnsName -Name example.com -Type TXT |

    Where-Object { $_.Strings -match 'v=spf1' } |

    Select-Object -ExpandProperty Strings

این روش برای بررسی رکوردهای SPF، DKIM یا DMARC مفید است.

5.3 ترکیب با `Test‑Connection` برای بررسی دسترسی به IP 

$ip = (Resolve-DnsName -Name example.com).IPAddress

Test-Connection -ComputerName $ip -Count 2

اگر پینگ موفق باشد، می‌توانید اطمینان حاصل کنید که مسیریابی به IP هدف درست کار می‌کند.

6. سرورهای مجازی ویندوز (Windows Virtual Server)

سرورهای مجازی ویندوز (Windows Virtual Server) به‌عنوان ماشین‌های مجازی (VM) بر روی سرور فیزیکی یا سرور ابری اجرا می‌شوند و سیستم‌عامل Windows Server را به‌عنوان مهمان (guest) می‌پذیرند. این سرورها در محیط‌های سازمانی، دیتاسنترهای ابری  یا حتی در سرورهای داخلی (on‑premises) برای میزبانی سرویس‌های مختلف—وب‌سایت، دیتابیس، Active Directory، DNS و …—به‌کار می‌روند.

6.1 نقش DNS در سرورهای مجازی ویندوز

– سرور DNS داخلی: اکثر سازمان‌ها یک یا چند سرور DNS داخلی بر پایه Windows Server راه‌اندازی می‌کنند تا نام‌های داخلی (مثلاً `corp.local`) را حل کنند. این سرورها معمولاً به‌عنوان Domain Controllers نیز عمل می‌کنند.

– پیش‌بارگذاری (Forwarding): سرورهای DNS داخلی می‌توانند درخواست‌های نام‌های عمومی را به سرورهای DNS خارجی (مانند 8.8.8.8) فوروارد کنند.

– پیکربندی در VM: هر ماشین مجازی می‌تواند به‌صورت خودکار از DHCP یا تنظیمات ثابت، آدرس سرور DNS داخلی یا خارجی را دریافت کند.

6.2 عیب‌یابی DNS در محیط‌های مجازی

در اولین گام، برای هر ماشین مجازی (VM) باید تنظیمات DNS کارت شبکه را بررسی کنید؛ این کار با `Get-DnsClientServerAddress -InterfaceAlias “Ethernet”` انجام می‌شود و لیستی از آدرس‌های سرور DNS که به اینترفیس متصل است را نشان می‌دهد. اگر این لیست خالی یا شامل آدرس‌های نادرست باشد، تمام درخواست‌های نام‌حل‌سازی به‌صورت خودکار شکست می‌خورند.

پس از اطمینان از صحت تنظیمات، گام بعدی تست حل نام‌های داخلی است. با اجرای `Resolve-DnsName -Name dc1.corp.local -Server 10.0.0.5` می‌توانید ببینید سرور DNS داخلی (معمولاً یک Domain Controller) قادر به پاسخ به درخواست‌های دامنهٔ محلی است یا خیر؛ اگر پاسخ موفق باشد، زون داخلی به‌درستی بارگذاری شده و ارتباط شبکه بین VM و سرور DNS برقرار است.

در ادامه، برای اطمینان از دسترسی به اینترنت و سرورهای DNS عمومی، همان فرمان را با یک سرور عمومی مثل Google Public DNS اجرا می‌کنید: `Resolve-DnsName -Name www.google.com -Server 8.8.8.8`. اگر این درخواست نیز موفق باشد، نشان می‌دهد مسیر شبکه تا اینترنت باز است و هیچ مانعی (مانند فایروال یا NSG) بر پورت 53 وجود ندارد.

اگر نتایج حل نام داخلی و عمومی متفاوت باشند (مثلاً IPهای متفاوت یا عدم پاسخ)، ممکن است رکوردهای زون داخلی نادرست یا قدیمی باشند. در این حالت می‌توانید خروجی دو درخواست را با هم مقایسه کنید؛ اختلاف در IP یا عدم وجود رکورد نشان‌دهندهٔ مشکل در پیکربندی زون یا کش DNS است.

در نهایت، برای تشخیص مشکلات عمیق‌تر می‌توانید لاگ‌های سرویس DNS سرور داخلی را با `Get-EventLog -LogName DNS -Newest 20` بررسی کنید؛ این لاگ‌ها خطاهای مربوط به بارگذاری زون، زمان‌سنجی یا مشکلات دسترسی را نشان می‌دهند. همچنین با `Test-NetConnection -ComputerName 10.0.0.5 -Port 53` می‌توانید از دسترس‌پذیری پورت 53 (UDP/TCP) بین VM و سرور DNS اطمینان حاصل کنید؛ اگر این تست شکست بخورد، احتمالاً فایروال، گروه امنیتی شبکه (NSG) یا تنظیمات مسیر (routing) مانع ارتباط می‌شود.

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

6.3 مثال عملی: اسکریپت مانیتورینگ DNS برای VMهای مجازی

لیست VMها (نام یا IP) که باید DNS آن‌ها بررسی شود

$VmList = @('10.1.2.10','10.1.2.11','10.1.2.12')




 سرور DNS داخلی سازمان

$InternalDns = '10.0.0.5'




 رکوردهای مهم برای هر VM (مثلاً نام دامنه داخلی)

$DomainToCheck = 'corp.local'




$Report = @()




foreach ($vm in $VmList) {

    $entry = "" | Select-Object VMIP, DNSStatus, ResolvedIP, ErrorMessage




    try {

        $result = Resolve-DnsName -Name $DomainToCheck -Server $InternalDns `

                  -ErrorAction Stop -DnsOnly




        $entry.VMIP       = $vm

        $entry.DNSStatus  = 'Success'

        $entry.ResolvedIP = ($result.IPAddress -join ',')

        $entry.ErrorMessage = ''

    }

    catch {

        $entry.VMIP       = $vm

        $entry.DNSStatus  = 'Failed'

        $entry.ResolvedIP = ''

        $entry.ErrorMessage = $_.Exception.Message

    }




    $Report += $entry

}




$Report | Format-Table -AutoSize

 برای ذخیره به CSV:

 $Report | Export-Csv -Path 'VmDnsHealth.csv' -NoTypeInformation

این اسکریپت می‌تواند به‌صورت زمانبندی‌شده (Task Scheduler یا Azure Automation) اجرا شود و در صورت بروز مشکل، ایمیل یا پیام Teams ارسال کند.

6.4 نکات مهم برای محیط‌های مجازی

– Synchronisation زمان: زمان نادرست بین VM و سرور DNS می‌تواند باعث عدم اعتبار کش DNS شود؛ از NTP یا سرویس زمان Windows استفاده کنید.

– پیکربندی NIC: در برخی پلتفرم‌های ابری (مثلاً Azure) ممکن است تنظیمات DNS بر روی NIC به‌صورت خودکار اعمال شود؛ اطمینان حاصل کنید که تنظیمات دستی (مانند `Set-DnsClientServerAddress`) با تنظیمات پلتفرم تداخل نداشته باشد.

– فایروال داخلی: پورت 53 (TCP/UDP) باید بین VMها و سرور DNS باز باشد؛ در Azure NSG یا AWS Security Group این پورت را بررسی کنید.

7. جمع‌بندی

– `Resolve‑DnsName` یک ابزار قدرتمند، شی‌محور و بومی در PowerShell برای پرس‌وجوی DNS است.

– خروجی ساختاریافته این cmdlet امکان فیلتر، ترکیب و ذخیره‌سازی داده‌ها را به‌صورت ساده فراهم می‌کند.

– با ترکیب پارامترهای `-Type`, `-Server`, `-DnsOnly` می‌توانید انواع مختلف رکوردها، سرورهای DNS دلخواه و حتی پرس‌وجوهای متنی (TXT) را به‌دست آورید.

– برای عیب‌یابی رایج (NoAnswer, ServerFailure, latency) می‌توانید از ترکیب `Resolve‑DnsName` با `Measure‑Command`, `Test‑Connection` و `Compare‑Object` استفاده کنید.

– در محیط‌های سرورهای مجازی ویندوز، DNS نقش حیاتی دارد؛ بررسی تنظیمات شبکه، تست حل نام داخلی/عمومی و مانیتورینگ دوره‌ای با اسکریپت‌های PowerShell می‌تواند از بروز اختلالات جلوگیری کند.

با به‌کارگیری این روش‌ها، می‌توانید به‌سرعت مشکلات DNS را شناسایی، عیب‌یابی و رفع کنید و سرویس‌های وابسته به نام دامنه را با اطمینان بیشتری مدیریت نمایید.