محتوای آموزشی وبلاگ نت‌آرام
کاربران یا برنامه‌های متصل به سرور مجازی ایران بعضی نام‌ها را دیر پیدا می‌کنند یا خطای DNS timeout می‌گیرند. ممکن است DNS Server ویندوز برای نامی که خودش پاسخ آن را ندارد، پرسش را به یک forwarder بفرستد و پاسخ به‌موقع نرسد. اما هر مشکل DNS از forwarder نیست: zone محلی، conditional forwarder، شبکه، فایروال و حتی پاسخ معتبر
NXDOMAIN هم مسیرهای متفاوتی دارند.در این راهنما ابتدا DNS داخلی و سرور بالادستی را جدا آزمایش می‌کنیم. بعد فقط آدرس یا تنظیمی را تغییر می‌دهیم که شواهد به آن اشاره می‌کند. اگر DNS سرور بخشی از Active Directory است، تغییر اشتباه می‌تواند ورود دامنه و سرویس‌های دیگر را مختل کند؛ فهرست آدرس‌ها و تنظیم قبلی را قبل از هر تغییر ثبت کنید.
۱. نامی که شکست می‌خورد و محل آزمایش را مشخص کنید
روی خود Windows DNS Server با PowerShell مدیر شروع کنید. از نام واقعی و مجاز محیط خود به‌جای مثال استفاده کنید:
کد / دستورGet-Service DNS
Get-DnsServerForwarder
Get-DnsServerRecursion
Get-DnsServerZone | Where-Object ZoneType -eq 'Forwarder' | Select-Object ZoneName, MasterServers, ForwarderTimeout
اولی وضعیت سرویس DNS، دومی فورواردهای سطح سرور، سومی تنظیم recursion و آخری zoneهای conditional forwarder را نشان می‌دهد. به نسخه Windows Server، نصب ابزار مدیریتی DNS و مجوز حساب توجه کنید؛ اگر cmdlet موجود نیست، ابزار نقش DNS یا DNS Manager همان نسخه را به کار ببرید. فایل خروجی ممکن است نشانی‌های خصوصی داشته باشد.
اگر فقط نام یک دامنه داخلی مشکل دارد، ممکن است conditional forwarder یا zone محلی همان نام مسیر را تعیین کند و فهرست عمومی forwarder اصلاً استفاده نشود. آدرس DNS عمومی را جایگزین DNS دامنه در کلاینت‌های عضو Active Directory نکنید؛ آن سرورها باید رکوردهای داخلی دامنه را از منبع مناسب بگیرند.
۲. همان پرسش را از DNS داخلی و upstream بپرسید
فرض کنید DNS داخلی روی همین ماشین به
کد / دستور127.0.0.1 پاسخ می‌دهد و forwarder مجاز شما 192.0.2.53 است. این IP مستندسازی است؛ با IP واقعی forwarder جایگزین کنید. نام نمونه را نیز با نامی که اجازه آزمایش آن را دارید عوض کنید:Resolve-DnsName example.com -Server 127.0.0.1 -DnsOnly
Resolve-DnsName example.com -Server 192.0.2.53 -DnsOnly
Resolve-DnsName example.com -Server 192.0.2.53 -DnsOnly -TcpOnly
اولی پاسخ DNS محلی، دومی پاسخ مستقیم سرور بالادستی با روش معمول و سومی پاسخ مستقیم از TCP را می‌سنجد. اگر پرسش مستقیم به forwarder هم timeout شود، مسیر یا خود forwarder محتمل است. اگر مستقیم جواب بدهد اما از DNS داخلی پاسخ نگیرید، zoneها، conditional forwarder، recursion و کش همان DNS را بررسی کنید. پاسخ از کش می‌تواند باعث شود یک آزمایش موقتاً موفق به نظر برسد؛ نام و زمان و TTL را در تفسیر در نظر بگیرید.
NXDOMAIN پاسخ معتبرِ نبود نام است، نه timeout. REFUSED می‌تواند نشان دهد سرور مقصد مجوز پاسخ به آن مبدأ یا نوع پرسش را نمی‌دهد. SERVFAIL یعنی پردازش کامل نشده و خود می‌تواند علت‌های مختلف داشته باشد. متن دقیق را ثبت کنید؛ همه را به «پورت بسته» نسبت ندهید.۳. ارتباط UDP و TCP را از مسیر واقعی بررسی کنید
کد / دستورTest-NetConnection 192.0.2.53 -Port 53
IP را با forwarder واقعی عوض کنید. این دستور فقط TCP پورت ۵۳ را می‌سنجد و بازبودن UDP را ثابت نمی‌کند. پرسش مستقیم DNS بالا برای آزمون کاربردی UDP مفید است؛ بسته به شرایط ممکن است پاسخ از TCP یا مسیر دیگری نیز استفاده شود. برای تفکیک دقیق، لاگ فایروال یا capture محدود را با مسئول شبکه و مجوز لازم بررسی کنید. هر دو جهت ارتباط و مسیر برگشت، نه فقط خروج سرور، مهم‌اند.
اگر UDP پاسخ می‌دهد ولی پاسخ بزرگ یا TCP شکست می‌خورد، مشکل فایروال یا مسیر TCP می‌تواند پاسخ بعضی نام‌ها را مختل کند. راهنمای تفاوت UDP و TCP در پاسخ DNS به این سناریو می‌پردازد. بازکردن پورت DNS برای تمام اینترنت ضروری نیست؛ دسترسی را فقط بین مبدأ و مقصدهای مجاز تنظیم کنید.
۴. تنظیم forwarder را متناسب با علت اصلاح کنید
اگر IP سرور بالادستی تغییر کرده یا از مبدأ شما دیگر پاسخ نمی‌دهد، ابتدا آدرس سالم و مجاز را از مدیر DNS بگیرید و مستقیم با همان پرسش آزمایش کنید. سپس در DNS Manager روی نام سرور، Properties و تب Forwarders فهرست فعلی را ثبت و فقط عضو اشتباه را با آدرس تأییدشده جایگزین کنید. در conditional forwarder، zone مربوط به همان دامنه را جداگانه باز و آدرس master را اصلاح کنید. در zoneهای یکپارچه با Active Directory، دامنه تکثیر و اثر تغییر روی DNSهای دیگر را نیز بررسی کنید.
اگر forwarder مستقیم پاسخ درست می‌دهد ولی DNS داخلی همچنان نام را نمی‌یابد، ببینید آیا سرور برای آن نام zone محلی یا delegation دارد. تنظیم یک forwarder جدید همیشه zone محلی اشتباه را دور نمی‌زند. پاسخ منفی معتبر upstream نیز معمولاً باعث رفتن خودکار به forwarder بعدی نمی‌شود. توضیح Microsoft درباره ترتیب forwarding و fallback این تفاوت را شرح می‌دهد.
۵. timeout و مسیر جایگزین را با احتیاط تنظیم کنید
اگر مسیر سالم ولی ذاتاً کند است، زمان پاسخ واقعی و timeoutهای recursion و forwarding را با مدیر DNS مقایسه کنید. صرف اضافه‌کردن ده forwarder تضمین نمی‌کند همه آن‌ها پیش از تمام‌شدن زمان کلی امتحان شوند. افزایش timeout ممکن است انتظار کاربر را طولانی‌تر کند و مشکل بسته‌شدن مسیر را حل نکند. رفتار ترتیب سرورها بین نسخه‌ها متفاوت است؛ تنظیم را طبق نسخه و مستند Microsoft، با مقدار قبلی ثبت‌شده و در محیط آزمایشی بسنجید.
استفاده از root hints به سیاست شبکه و تنظیم recursion بستگی دارد؛ برای نام‌های خصوصی، فرستادن پرسش به DNS عمومی ممکن است پاسخ درست ندهد یا اطلاعات نام داخلی را افشا کند. اگر تغییر کمک نکرد، فهرست و گزینه‌های ثبت‌شده قبلی را در همان پنل برگردانید.
۶. نتیجه را از سمت کاربر هم تأیید کنید
از خود DNS Server دوباره پرسش مستقیم و از کلاینتی که قبلاً مشکل داشت پرسش به DNS داخلی را اجرا کنید. نام داخلی و عمومی مرتبط را جدا امتحان کنید و زمان پاسخ، نوع پاسخ و سرویس واقعی مانند ورود دامنه یا اتصال برنامه را بسنجید. تنها بازشدن پورت ۵۳ نشان‌دهنده سلامت زنجیره حل نام نیست.
اگر خطا ادامه دارد، نام آزمایشی، زمان، IPهای بدون اطلاعات محرمانه، نتیجه UDP و TCP، zone مؤثر و متن دقیق پاسخ را برای بررسی نگه دارید. راهنمای Microsoft برای خطاهای forwarder سناریوهای مسیر و مجوز را با جزئیات بیشتری توضیح می‌دهد.
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام