راه‌اندازی DNS داخلی در ویندوز سرور

مبنای آموزش Windows Server 2025 Standard با Desktop Experience است. سرور DC1 با IP ثابت 192.168.50.10، کنترلر دامین ad.example.com و میزبان DNS است؛ همان محیط ساخته‌شده در آموزش نصب اکتیودایرکتوری. کلاینت Windows 11 Pro در همان شبکهٔ 192.168.50.0/24 قرار دارد. این راهنما برای DNS داخلی مبتنی بر AD است؛ انتخاب DNS عمومی، ثبت دامنهٔ اینترنتی و میزبانی DNS عمومی موضوع آن نیست.

نام‌های example.com و زیرنام‌هایش در این متن نمونه‌اند. در سازمان از نام تحت کنترل خود استفاده کنید. سناریوی پایه روتر و اینترنت ندارد؛ فقط بخش Forwarder به مسیر واقعی خروجی نیاز دارد. تفاوت Zone، Resolver و انواع رکورد را در DNS چیست؟ توضیح داده‌ایم.

هنگام ساخت اولین دامین در آموزش قبلی، DNS Server همراه ارتقای کنترلر نصب شد. از Server Manager → Tools → DNS، کنسول DNS Manager را باز کنید. اگر این نقش در سناریوی دیگری نصب نیست، از Add Roles and Features، نقش DNS Server و ابزار مدیریتی آن نصب می‌شود؛ اما ذخیرهٔ Zone در AD فقط روی کنترلر دارای AD DS امکان دارد، نه هر سرور مستقلی که نقش DNS گرفته است.

روی DC1، ناحیهٔ ad.example.com و ساختار رکوردهای _msdcs را پیدا کنید. برای ادامه، آن‌ها را حذف یا دوباره ایجاد نکنید. نوع ناحیه، دامنهٔ همانندسازی و تنظیم Dynamic updates را ثبت کنید؛ در ناحیهٔ AD-integrated این سناریو، به‌روزرسانی پویا باید Secure only باشد. اگر نام سرویس جدید داخل ناحیهٔ موجود است، معمولاً افزودن همان رکورد کافی است و لازم نیست برای هر میزبان Zone جدید بسازید.

برای اینکه ساخت Zone را بدون دست‌کاری ناحیهٔ اصلی دامین تمرین کنیم، نام apps.ad.example.com را به سرویس‌های آزمایش اختصاص می‌دهیم. همهٔ کلاینت‌های این نمونه از DC1 پرسش می‌کنند و این Zone نیز روی DC1 قرار دارد. اگر DNSهای دیگری پاسخ‌گوی کلاینت‌ها هستند، همانندسازی یا مسیر ارجاع آن‌ها باید در طرح واقعی بررسی شود.

• در DNS Manager، روی Forward Lookup Zones راست‌کلیک کنید و New Zone را بزنید. Primary zone و Store the zone in Active Directory را انتخاب کنید.
• برای این سناریوی تک‌دامین، همانندسازی به DNS Serverهای کنترلرهای همین دامین را انتخاب کنید. دامنهٔ همانندسازی یک تصمیم واقعی دربارهٔ محل نگهداری داده است؛ آن را بدون نیاز به کل Forest گسترش ندهید.
• نام apps.ad.example.com را وارد کنید. برای Dynamic Update، فقط به‌روزرسانی امن را انتخاب و Wizard را تمام کنید. اگر این Zone از قبل وجود دارد، به‌جای ایجاد دوباره، نوع و محتوای همان را بررسی کنید.

Zone تازه، مسئول پاسخ نام‌های زیر خودش می‌شود. ساخت بی‌دلیل Zone به نام دامنهٔ عمومی شرکت می‌تواند دسترسی داخلی به نام‌های عمومیِ فاقد رکورد در آن Zone را مختل کند. ابتدا مرز نام‌گذاری را مشخص کنید، سپس Zone بسازید.

برای زیرشبکهٔ آزمایش، در Reverse Lookup Zones گزینهٔ New Zone را بزنید. Primary و ذخیره در AD با همان محدودهٔ همانندسازی دامین را انتخاب کنید؛ سپس IPv4 Reverse Lookup Zone و Network ID برابر 192.168.50 را وارد کنید. عددها را در فیلد Network ID برعکس ننویسید. نام حاصل باید 50.168.192.in-addr.arpa باشد. به‌روزرسانی امن را انتخاب کنید؛ Reverse Zone موجود را دوباره نسازید.

در این مثال، IP برابر 192.168.50.30 را برای میزبان سرویس app1 در نظر می‌گیریم. پیش از استفادهٔ واقعی باید این IP آزاد و متعلق به همان میزبان باشد. اگر فقط رکورد را برای تمرین می‌سازید، پاسخ DNS به‌تنهایی ثابت نمی‌کند سروری روی آن IP روشن یا سرویسش قابل استفاده است.

• در Zone برابر apps.ad.example.com، گزینهٔ New Host (A or AAAA) را باز کنید. Name را app1 و IP address را 192.168.50.30 قرار دهید. پیش از Add Host، نام کامل app1.apps.ad.example.com را کنترل کنید.
• اگر Reverse Zone آماده است، Create associated pointer (PTR) record را انتخاب کنید و نتیجه را بررسی کنید. اگر PTR ساخته نشد، در Reverse Zone گزینهٔ New Pointer را باز کنید؛ IP میزبان و نام کامل app1.apps.ad.example.com را وارد کنید.
• پس از ساخت، رکورد A باید نام را به .30 و PTR باید همان IP را به نام کامل موردنظر برگرداند. وجود رکورد قبلی با IP یا نام متفاوت را با بازنویسی عجولانه حل نکنید.

A و PTR دو رکورد جدا هستند؛ وجود یکی، وجود یا به‌روز بودن دیگری را تضمین نمی‌کند. همچنین اگر بعداً CNAME برای یک سرویس می‌سازید، نام مستعار DNS به‌تنهایی تنظیمات برنامه، گواهی یا احراز هویت آن سرویس را تغییر نمی‌دهد.

برای حل نام‌های خارج از ناحیه‌های داخلی، DNS Server می‌تواند از Forwarder یا مسیر بازگشتی مبتنی بر Root Hints استفاده کند. Forwarder اجباریِ هر شبکه نیست و سرعت یا دسترس‌پذیری آن را نمی‌توان از روی نام سرویس تضمین کرد. در آزمایش بدون Gateway، انتظار حل نام‌های اینترنتی نداریم.

اگر روتر، مسیر خروجی و DNS بالادست موردتأیید دارید، در Properties سرور DNS، زبانهٔ Forwarders و Edit، آدرس‌های واقعی بالادست را اضافه و امکان ارتباط با آن‌ها را بررسی کنید. DC1 را Forwarder خودش نکنید و بین دو DNS حلقهٔ ارجاع نسازید. تنظیم Disable recursion روی سرور، استفاده از Forwarder را هم متوقف می‌کند؛ آن را هم‌زمان با انتظار Forwarding فعال نکنید.

رکوردهای داخلی باید روی DNS داخلی پاسخ داده شوند؛ افزودن DNS عمومی به کارت شبکهٔ کلاینت، راه اصلاح Forwarder نیست. دسترسی به Resolver داخلی را به شبکه‌های لازم محدود کنید و آن را بی‌دلیل از اینترنت در دسترس نگذارید.

در کلاینت آزمایش، DNS را 192.168.50.10 قرار دهید. اگر IP دستی است، DNS را در تنظیمات همان رابط شبکه وارد کنید. اگر IP از DHCP می‌آید، Option 006 باید آدرس DNS داخلی و Option 015 پسوند ad.example.com را توزیع کند؛ مراحل آن در راه‌اندازی DHCP ویندوز سرور آمده است. DNS دوم فقط در صورت وجود یک DNS داخلیِ آماده و آزموده اضافه می‌شود.

ipconfig /all

Resolve-DnsName -Name app1.apps.ad.example.com -Type A -Server 192.168.50.10 -DnsOnly -NoHostsFile
Resolve-DnsName -Name 30.50.168.192.in-addr.arpa -Type PTR -Server 192.168.50.10 -DnsOnly -NoHostsFile
Resolve-DnsName -Name _ldap._tcp.dc._msdcs.ad.example.com -Type SRV -Server 192.168.50.10 -DnsOnly -NoHostsFile

پرسش اول باید A مربوط به .30، پرسش دوم نام کامل میزبان و پرسش سوم کنترلر دامین را برگرداند. DnsOnly از پاسخ‌گیری با LLMNR یا NetBIOS جلوگیری می‌کند و NoHostsFile فایل Hosts را کنار می‌گذارد. این‌ها معیارهای مورد انتظارند و خروجی عملی ثبت‌شده نیستند.

Resolve-DnsName -Name app1.apps.ad.example.com -Type A -DnsOnly -NoHostsFile

آزمون بدون Server مهم است: پاسخ صحیح از یک سرور مشخص هنوز ثابت نمی‌کند کلاینت در استفادهٔ عادی از همان مسیر پرسش می‌کند. اگر رکورد تازه عوض شده و پاسخ قدیمی می‌بینید، Cache و TTL را بررسی کنید؛ در صورت نیاز برای آزمون همان کلاینت، ipconfig /flushdns را اجرا و پرسش را تکرار کنید. این دستور رکورد سرور را اصلاح نمی‌کند.

در صورت تنظیم مسیر خروجی و Forwarder، حل یک نام عمومی معتبر را نیز جداگانه بررسی کنید. پس از موفقیت DNS، اتصال به سرویس واقعی app1 را با روش مخصوص همان برنامه آزمایش کنید؛ حل نام، آزمون پورت یا ورود به برنامه نیست.

Aging و Scavenging را صرفاً با یک عدد ثابت روی همهٔ ناحیه‌ها فعال نکنید. حذف رکوردهای قدیمی باید با روش ثبت و تمدید رکورد، مالکیت آن‌ها و Leaseهای DHCP هماهنگ باشد. Zone Transfer عمومی نیز لازمهٔ این سناریو نیست؛ انتقال ناحیه فقط در صورت نیاز و به سرورهای مجاز طراحی می‌شود.

برای تحویل، نام Zone، نوع و محدودهٔ همانندسازی، رکوردهای A و PTR، تنظیم Forwarder در صورت استفاده و نتیجهٔ پرسش مستقیم و عادی کلاینت را ثبت کنید. سرویس AD نیز باید همچنان رکوردهای SRV قابل استفاده داشته باشد. این مجموعه نشان می‌دهد کدام بخش بررسی شده و کدام بخش هنوز به آزمون برنامه نیاز دارد.

پیش از تغییر، مقادیر قبلی رکورد، Forwarder و DNS کلاینت را نگه دارید. اگر تغییر مشکل ساخت، همان مورد را برگردانید و پس از توجه به Cache دوباره آزمایش کنید؛ حذف ناحیهٔ اصلی دامین یا کل _msdcs روش برگشت این آموزش نیست. برای تغییر روی شبکهٔ موجود، خدمات اکتیودایرکتوری و DNS دامین می‌تواند با وابستگی کاربران و برنامه‌ها بررسی شود.