چگونه DNS های دامنه خود را بیابیم؟

نیم‌سرور دامنه چیست و چه کاری می‌کند؟

وقتی دامنه‌ای را ثبت می‌کنید، در پایگاه داده رجیستری آن پسوند (برای نمونه IRNIC برای دامنه‌های ir. یا رجیستری com. برای دامنه‌های تجاری) یک رکورد به نام NS ذخیره می‌شود. این رکورد به دنیا اعلام می‌کند که «مرجع رسمی پاسخ‌گویی به پرسش‌های این دامنه، این سرورها هستند».

خود نیم‌سرور آدرس IP سایت را در رجیستری نگه نمی‌دارد؛ رجیستری فقط می‌داند سراغ چه کسی برود. رکوردهای واقعی — یعنی A و AAAA برای وب، MX برای ایمیل، TXT برای SPF و DKIM و تأییدیه‌ها، CNAME برای زیردامنه‌ها — همگی روی همان نیم‌سرورها و در فایل زون دامنه نگهداری می‌شوند. به همین دلیل شناختن نیم‌سرور فعلی، اولین قدم هر عیب‌یابی DNS است: تا ندانید زون دامنه کجا مدیریت می‌شود، تغییر دادن رکوردها در پنل اشتباه هیچ اثری نخواهد داشت.

روش اول: پنل کاربری ثبت‌کننده دامنه

معتبرترین منبع، همان جایی است که دامنه را ثبت یا تمدید کرده‌اید. در ناحیه کاربری، بخش مدیریت دامنه معمولاً گزینه‌ای با عنوان Nameservers یا «مدیریت DNS» دارد که مقادیر فعلی را نشان می‌دهد و امکان ویرایش آن‌ها را هم می‌دهد.

یک نکته مهم: مقداری که در این پنل می‌بینید همان چیزی است که قرار است اعمال شود، اما لزوماً همان چیزی نیست که همین لحظه در اینترنت منتشر شده است. اگر چند دقیقه پیش نیم‌سرور را عوض کرده‌اید، پنل مقدار جدید را نشان می‌دهد در حالی که بیشتر کاربران دنیا هنوز مقدار قدیمی را می‌بینند. برای دیدن وضعیت واقعی باید از روش‌های بعدی استفاده کنید.

روش دوم: خواندن whois دامنه

خروجی whois اطلاعات ثبتی دامنه را از خود رجیستری می‌گیرد و در آن فیلدهایی با نام Name Server یا nserver وجود دارد که نیم‌سرورهای ثبت‌شده را فهرست می‌کند. در لینوکس و مک کافی است بنویسید:

  • whois example.com برای دامنه‌های بین‌المللی
  • برای دامنه‌های ir. سرویس whois رسمی IRNIC روی نشانی whois.nic.ir پاسخ می‌دهد و همان فیلد nserver را برمی‌گرداند

مزیت whois این است که به شما می‌گوید در رجیستری چه چیزی ثبت شده؛ محدودیتش این است که چیزی درباره سلامت آن سرورها یا محتوای زون نمی‌گوید. ممکن است نیم‌سروری در whois ثبت شده باشد که اصلاً بالا نیست.

روش سوم: خط فرمان با nslookup و dig

این روش برخلاف whois، پاسخ را از خود سامانه DNS می‌گیرد؛ یعنی چیزی را نشان می‌دهد که مرورگرها و سرورهای ایمیل واقعاً می‌بینند.

در ویندوز

در Command Prompt یا PowerShell دستور nslookup -type=ns example.com را اجرا کنید. اگر می‌خواهید پاسخ از یک ریزالور مشخص گرفته شود، نام یا IP آن را در انتها اضافه کنید، مثلاً nslookup -type=ns example.com 8.8.8.8.

در لینوکس و مک

ابزار استاندارد dig دقیق‌تر و خواناتر است:

  • dig NS example.com +short — فقط فهرست نیم‌سرورها
  • host -t ns example.com — همان نتیجه با دستوری کوتاه‌تر
  • dig NS example.com +trace — مسیر کامل پرسش را از روت تا رجیستری پسوند و سپس نیم‌سرورهای دامنه نشان می‌دهد و برای پیدا کردن ناهماهنگی بسیار مفید است

اگر می‌خواهید پاسخ را مستقیم از خود نیم‌سرور دامنه بگیرید و کش میانی را دور بزنید، از الگوی dig NS example.com @ns1.example-dns.com استفاده کنید.

روش چهارم: ابزارهای آنلاین

اگر به خط فرمان دسترسی ندارید، سرویس‌های وب‌محور whois و DNS lookup همین کار را انجام می‌دهند. سرویس رسمی ICANN روی نشانی lookup.icann.org داده ثبتی دامنه‌های بین‌المللی را نشان می‌دهد، whois.domaintools.com خروجی whois را در قالبی خوانا ارائه می‌کند و mxtoolbox.com رکوردهای NS و MX را مستقیم از سامانه DNS پرس‌وجو می‌کند. برای دامنه‌های ir. هم مرجع رسمی همان whois.nic.ir است.

حواستان به یک محدودیت باشد: این ابزارها وضعیت کش DNS شبکه شما را گزارش نمی‌کنند. آن‌ها از دید سرورهای خودشان پرسش می‌کنند، نه از دید ریزالوری که کامپیوتر یا سرور شما واقعاً از آن استفاده می‌کند. پس اگر ابزار آنلاین نیم‌سرور جدید را نشان می‌دهد ولی سایت برای شما هنوز به سرور قبلی می‌رود، لزوماً خطایی رخ نداده است.

چرا گاهی دو ابزار، دو پاسخ متفاوت می‌دهند؟

سه لایه متفاوت وجود دارد و هر ابزار یکی از آن‌ها را می‌خواند. لایه اول، داده ثبت‌شده در رجیستری است که whois آن را نشان می‌دهد. لایه دوم، پاسخ خود نیم‌سرورهای معتبر دامنه است که با dig مستقیم به دست می‌آید. لایه سوم، کش ریزالورهایی است که کاربران به آن‌ها وصل هستند.

عامل اصلی اختلاف، TTL است؛ عددی بر حسب ثانیه که تعیین می‌کند هر پاسخ چقدر در کش باقی بماند. رکورد NS معمولاً TTL بلندی دارد؛ به همین دلیل تا زمانی که TTL پاسخ قبلی در کش ریزالورها منقضی نشود، بخشی از کاربران همچنان نیم‌سرور قدیمی را می‌بینند. طول این ناهماهنگی چیز دیگری جز همان TTL تنظیم‌شده روی زون نیست. اگر از قبل می‌دانید قرار است نیم‌سرور را عوض کنید، کم کردن TTL پیش از جابه‌جایی، این بازه را کوتاه می‌کند.

تغییر نیم‌سرور دقیقاً چه چیزی را جابه‌جا می‌کند؟

تغییر NS یعنی انتقال کل مسئولیت پاسخ‌گویی دامنه به مجموعه‌ای دیگر. سایت، ایمیل، زیردامنه‌ها، رکوردهای تأیید مالکیت و هر چیز دیگری که به DNS وابسته است، از آن لحظه از زون جدید خوانده می‌شود. اگر زون جدید را از قبل کامل نساخته باشید، رکوردهایی که فراموش شده‌اند به‌سادگی ناپدید می‌شوند — و شایع‌ترین قربانی این ماجرا رکوردهای MX است که قطع ایمیل را به دنبال دارد.

روال درست این است: ابتدا زون کامل را روی سرویس میزبانی DNS جدید بسازید و تک‌تک رکوردها را با زون فعلی مقایسه کنید، سپس نیم‌سرور را در پنل دامنه تغییر دهید و تا پایان دوره انتشار، زون قدیمی را حذف نکنید. اگر مخاطبان شما در چند کشور پراکنده‌اند یا به پایداری بیشتری نیاز دارید، شبکه‌های Geo DNS و AnyCast پاسخ را از نزدیک‌ترین نقطه به کاربر برمی‌گردانند و وابستگی به یک مکان واحد را کم می‌کنند.

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