آموزش DNS Lookup؛ رکوردهای دامنه را درست بخوانید
DNS Lookup مشخص می‌کند یک دامنه چه اطلاعاتی در سامانه نام دامنه منتشر کرده و درخواست کاربران باید به کدام سرور برود. با ابزار DNS Lookup آسیاتکین می‌توانید رکوردهای وب‌سایت، ایمیل و نام‌سرورها را بدون نصب نرم‌افزار بررسی کنید. یک مرزبندی را از ابتدا روشن کنیم، چون بیشتر تفسیرهای اشتباه از همین‌جا شروع می‌شود: این آزمایش فقط وضعیت DNS را نشان می‌دهد. پاسخ درست DNS ثابت نمی‌کند وب‌سرور روشن است، پورت باز است یا گواهی TLS سالم است.

DNS Lookup چگونه کار می‌کند؟

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

این یک پرس‌وجو درباره داده‌های عمومی دامنه است، نه ورود به سرور یا اسکن امنیتی. Resolver پاسخ را مدتی نگه می‌دارد و سازوکار این cache در RFC 1034 درباره مفاهیم DNS تشریح شده است. از این رو دو Resolver مختلف ممکن است بعد از یک تغییر DNS پاسخ‌های متفاوتی بدهند.

کاربردهای DNS Lookup در عیب‌یابی واقعی

وقتی سایت پس از انتقال هاست بالا نمی‌آید، اولین کار دیدن این است که رکورد A یا CNAME هنوز به مقصد قدیمی اشاره می‌کند یا نه. برای زیردامنه‌ای مانند shop.example.com هم باید همان نام کامل را بررسی کنید؛ نتیجه دامنه اصلی الزاماً درباره زیردامنه صدق نمی‌کند.

در پشتیبانی شبکه مرتب با این الگو روبه‌رو می‌شویم که کاربر «قطع کامل اینترنت» گزارش می‌کند، اما ping به IP جواب می‌دهد و فقط نام سایت باز نمی‌شود. در این وضعیت مقایسه پاسخ A در دو Resolver مختلف، خیلی سریع‌تر از ریست‌کردن مودم نشان می‌دهد که مشکل از تبدیل نام است، از cache، یا از رکوردی که اشتباه ثبت شده. همین تفاوت DNS Lookup و ping است که تشخیص را جلو می‌اندازد: یکی نام را می‌سنجد و دیگری مسیر تا مقصد را.

در جابه‌جایی سرویس ایمیل هم بارها دیده‌ایم وب‌سایت بدون هیچ مشکلی کار می‌کند ولی پیام‌ها همچنان به سرور قبلی می‌روند. علت تقریباً همیشه MX قدیمی است، نه رکورد وب، و کسی که فقط سایت را چک کرده باشد این را نمی‌بیند.

پیش از مهاجرت، خروجی فعلی A، MX، NS و TXT را نگه دارید تا بعد از تغییر با پاسخ جدید مقایسه شود. برای IP سرور ایمیل هم جست‌وجوی PTR هماهنگی نام میزبان با هویت سرور را آشکار می‌کند؛ ناهماهنگی در این نقطه می‌تواند به اعتبار ایمیل‌های ارسالی آسیب بزند.

آموزش کار با ابزار DNS Lookup آسیاتکین

رابط ابزار سه ورودی اصلی دارد: نام دامنه یا IP، نوع رکورد، و Resolver.

  1. در کادر Domain / IP فقط نام دامنه، زیردامنه یا IP را وارد کنید. برای دامنه، https://، مسیر صفحه و اسلش انتهایی را حذف کنید؛ example.com ورودی درست‌تری از https://example.com/page/ است.

  2. از بخش Record رکورد مورد نظر را میان A، AAAA، MX، NS، TXT، CNAME و SOA انتخاب کنید. گزینه ALL برای دید کلی خوب است، اما وقتی دنبال یک مشکل مشخص هستید، انتخاب همان نوع رکورد خروجی خواناتری می‌دهد.

  3. در بخش Resolver یکی از Cloudflare، Google یا Quad9 را انتخاب کنید. پرس‌وجوی Cloudflare مستقیماً از مرورگر و از مسیر DoH انجام می‌شود، درحالی‌که درخواست‌های Google و Quad9 از سرور آسیاتکین فرستاده می‌شوند.

  4. دکمه جستجو را بزنید. خلاصه نتیجه شامل نوع درخواست، Resolver، منبع پاسخ و Status بالای جدول می‌آید و جدول ستون‌های نوع، نام، TTL و مقدار را نشان می‌دهد.

  5. برای فرستادن نتیجه به مدیر هاست، از دکمه کپی یا بخش خروجی خام استفاده کنید. اگر به‌جای دامنه یک IP وارد کنید، ابزار خودکار سراغ PTR یا Reverse DNS می‌رود.

روش DoH پرس‌وجوی DNS را داخل ارتباط HTTPS منتقل می‌کند. طبق مستندات DNS over HTTPS کلادفلر این کار درخواست را در مسیر محافظت می‌کند، اما با رمزنگاری محتوای وب‌سایت یکی نیست؛ امنیت خود سایت همچنان به HTTPS و گواهی TLS وابسته است.

هر رکورد چه چیزی را نشان می‌دهد؟

رکورد A نام را به یک IPv4 مانند 192.0.2.10 وصل می‌کند و AAAA همین کار را برای IPv6 انجام می‌دهد. خالی‌بودن AAAA لزوماً خطا نیست، چون بسیاری از سرویس‌ها هنوز فقط IPv4 منتشر می‌کنند. CNAME یک نام مستعار را به نام دیگری ارجاع می‌دهد و ممکن است برای رسیدن به IP نهایی چند مرحله دنبال شود.

رکورد MX سرورهای دریافت‌کننده ایمیل را با اولویتشان نشان می‌دهد و عدد کوچک‌تر اولویت بالاتری دارد. NS مشخص می‌کند کدام نام‌سرورها مرجع رسمی zone هستند. TXT برای داده‌های متنی عمومی مانند SPF، اشاره DKIM، تأیید مالکیت دامنه و سیاست‌های سرویس‌ها به کار می‌رود؛ وجود TXT به‌تنهایی درست‌بودن محتوایش را ثابت نمی‌کند و مقدارش باید با تنظیمات سامانه مقصد تطبیق داده شود.

رکورد SOA اطلاعات مدیریتی zone، شماره serial و زمان‌بندی‌های همگام‌سازی را برمی‌گرداند. PTR هم مسیر معکوس را می‌رود و از روی IP به نام میزبان می‌رسد. این یکی نکته‌ای دارد که زیاد از قلم می‌افتد: PTR را باید مالک IP در سمت ارائه‌دهنده تنظیم کند و ساختن یک رکورد A در پنل دامنه هیچ‌وقت Reverse DNS نمی‌سازد.

TTL، Status و Resolver را چگونه تفسیر کنیم؟

مقدار TTL برحسب ثانیه است. عدد ۳۰۰ یعنی Resolver می‌تواند پاسخ را تا ۵ دقیقه از لحظه دریافت نگه دارد. این زمان قطعی انتشار جهانی نیست، چون cacheها در لحظه‌های متفاوتی پر شده‌اند و تغییر NS لایه جداگانه خودش را دارد. نکته‌ای که خیلی‌ها دیر متوجهش می‌شوند این است که کم‌کردن TTL پس از تغییر، نسخه‌ای را که قبلاً با مقدار بالاتر cache شده فوراً پاک نمی‌کند.

وضعیت OK یعنی پاسخ معتبری برای درخواست رسیده است. Empty معمولاً یعنی دامنه وجود دارد ولی رکورد انتخاب‌شده برایش منتشر نشده؛ نمونه رایجش جست‌وجوی AAAA برای دامنه‌ای است که IPv6 ندارد. NXDOMAIN اما می‌گوید نام مورد پرسش اصلاً در DNS وجود ندارد، و غلط املایی، حذف زیردامنه، انقضای دامنه، اشکال delegation یا ماندن یک پاسخ منفی در cache می‌تواند به آن ختم شود.

اختلاف پاسخ میان سه Resolver به‌خودی‌خود نشانه خرابی نیست؛ هرکدام cache مستقل و گاهی سیاست پاسخ‌دهی متفاوت دارند. سرویس 9.9.9.9 در مستندات رسمی Quad9 یک Resolver دارای مسدودسازی تهدید معرفی شده، پس دامنه‌ای که خطرناک تشخیص داده شود ممکن است رفتاری متفاوت از یک Resolver بدون فیلتر نشان دهد. برای سنجش انتشار یک تغییر، مقدار رکورد و TTL را با هم مقایسه کنید، نه فقط برچسب OK را.

چرا نتیجه DNS درست است اما سایت باز نمی‌شود؟

وب‌سرور می‌تواند خاموش باشد، پورت ۸۰ یا ۴۴۳ بسته باشد، گواهی TLS با نام دامنه نخواند یا Virtual Host اشتباه تنظیم شده باشد. در سرویس‌های CDN هم IP نمایش‌داده‌شده معمولاً متعلق به شبکه توزیع محتواست نه سرور اصلی، و این کاملاً طبیعی است. اگر همه رکوردها درست‌اند و سایت با خطای امنیتی بالا می‌آید، مرحله بعدی بررسی گواهی HTTPS پس از تغییر DNS است.

از طرف دیگر، cache سیستم‌عامل، فایل hosts، DNS داخلی شرکت، VPN یا Secure DNS مرورگر می‌تواند نتیجه‌ای را که کاربر می‌بیند عوض کند. این ابزار رکورد عمومی را از Resolver انتخابی می‌پرسد و به zone خصوصی شبکه سازمانی دسترسی ندارد، پس پاسخ درست آن تضمین نمی‌کند DNS داخلی شرکت هم همان را برمی‌گرداند.

یک تفکیک دیگر هم لازم است: گزینه ALL همه زیردامنه‌های یک دامنه را کشف نمی‌کند و فقط انواع رایج رکورد را برای همان نامی که وارد کرده‌اید می‌پرسد. برای فهرست زیردامنه‌ها باید سراغ ابزار دیگری رفت.

آیا DNS Lookup سرعت اینترنت را افزایش می‌دهد؟

DNS فقط مرحله یافتن مقصد را انجام می‌دهد و هیچ نقشی در ظرفیت خط ندارد. یک Resolver سریع‌تر یا سالم‌تر می‌تواند تأخیر آغاز اتصال و خطاهای نام‌گشایی را کم کند، اما پهنای باند، نرخ همگام‌سازی ADSL، کیفیت سیگنال TD-LTE و ازدحام مسیر را تغییر نمی‌دهد.

برای مشترکان سرویس‌های آسیاتک، ارزش عملی این ابزار همین مرزبندی است. اگر چند Resolver پاسخ درست می‌دهند ولی همه سایت‌ها کند بالا می‌آیند، صورت‌مسئله اصلاً DNS نیست و باید سراغ عیب‌یابی کامل اتصال پس از اطمینان از DNS رفت: کیفیت خط، packet loss و سرعت واقعی.

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

منابع