Whois یا RDAP به شما کمک می‌کند وضعیت دامنه، رجیسترار، تاریخ‌ها و گاهی اطلاعات تماس عمومی مالک را بررسی کنید.

سلام‌سرور این راهنما را با نگاه آموزشی و عیب‌یابی نوشته است؛ هدف مقاله فروش سرویس یا تبلیغ نیست، بلکه کمک به کاربری است که با یک مشکل واقعی در دامنه، DNS، هاست یا SSL روبه‌رو شده و می‌خواهد بداند دقیقاً از کجا شروع کند.

این مقاله دقیقاً چه مشکلی را حل می‌کند؟

این مقاله به کاربران یاد می‌دهد چطور از Whois برای عیب‌یابی دامنه، بررسی انتقال، انقضا، تعلیق و Nameserver استفاده کنند.

بسیاری از کاربران وقتی سایت باز نمی‌شود یا SSL خطا می‌دهد، هم‌زمان چند چیز را تغییر می‌دهند: Nameserver، رکورد A، افزونه وردپرس، کش، CDN و حتی تنظیمات هاست. این کار عیب‌یابی را سخت‌تر می‌کند. روش درست این است که هر لایه را جداگانه تست کنیم و فقط بعد از اثبات مشکل، همان بخش را تغییر بدهیم.

چک‌لیست سریع قبل از شروع

  • نام دامنه را دقیق و بدون غلط تایپی بررسی کنید؛ نسخه با www و بدون www را جداگانه تست کنید.
  • مشخص کنید DNS فعال دامنه کجاست: رجیسترار، cPanel، DirectAdmin، Cloudflare یا سرور اختصاصی.
  • اگر ایمیل دامنه فعال است، قبل از تغییر DNS از MX و TXTهای SPF/DKIM/DMARC یادداشت بگیرید.
  • اگر سایت فروشگاهی یا پرترافیک است، تغییرات را در زمان کم‌ترافیک انجام دهید و بکاپ داشته باشید.

مفاهیم پایه‌ای که باید بدانید

DNS دفترچه راهنمای اینترنت برای تبدیل نام دامنه به مقصد فنی است. وقتی کاربر example.com را وارد می‌کند، مرورگر باید بفهمد این نام به کدام IP یا کدام سرویس اشاره می‌کند. SSL هم لایه اعتماد و رمزنگاری روی این ارتباط است؛ بنابراین اگر DNS اشتباه باشد، SSL هم معمولاً نمی‌تواند درست صادر یا استفاده شود.

Nameserver مشخص می‌کند مدیریت DNS دامنه در کدام سرویس انجام می‌شود. رکوردهای DNS داخل همان سرویس نگهداری می‌شوند. رکورد A معمولاً دامنه را به IPv4 وصل می‌کند، AAAA به IPv6، CNAME یک نام را به نام دیگر، MX مسیر ایمیل، TXT اطلاعات متنی و تأییدیه‌ها، و NS محل مدیریت DNS را مشخص می‌کند.

مراحل پیشنهادی انجام کار

  1. نام دامنه را در ICANN Lookup یا ابزار whois بررسی کنید.
  2. به Registrar، Creation Date، Expiry Date، Domain Status و Nameserverها دقت کنید.
  3. اگر دامنه باز نمی‌شود، وضعیت‌هایی مثل clientHold یا serverHold را جدی بگیرید.
  4. برای IP یا ASN، RDAP و ابزارهای رجیستری منطقه‌ای اطلاعات دقیق‌تری می‌دهند.

دستورهای SSH و ترمینال برای بررسی دقیق

در دستورهای زیر به‌جای example.com دامنه خودتان را قرار دهید. اگر دسترسی SSH ندارید، بخش زیادی از همین تست‌ها را می‌توانید با ابزارهای آنلاین DNS یا ترمینال ویندوز انجام دهید؛ اما روی سرور لینوکس، dig و curl دقیق‌ترین تصویر را می‌دهند.

# نصب ابزارها
sudo apt update && sudo apt install -y whois dnsutils curl jq

# whois دامنه
whois example.com

# RDAP از سرویس عمومی ICANN با curl نمونه
curl -s https://rdap.org/domain/example.com | jq '.ldhName, .status, .nameservers'

# nameserver و تاریخ DNS را با dig جداگانه تست کنید
dig example.com NS +short
dig +trace example.com

چطور نتیجه دستورها را تفسیر کنیم؟

اگر dig برای دامنه IP برگرداند، یعنی حداقل بخشی از DNS کار می‌کند. اگر curl روی HTTP یا HTTPS خطای 301، 302، 403، 404، 500 یا timeout نشان دهد، دیگر فقط با DNS طرف نیستیم و باید وب‌سرور، فایروال، SSL یا برنامه سایت را بررسی کنیم. اگر openssl گواهی دامنه دیگری را نشان دهد، یعنی SNI یا virtual host اشتباه تنظیم شده است.

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

خطاها و چالش‌های رایج کاربران

  • اطلاعات مالک به‌دلیل Privacy Protection پنهان است و کاربر فکر می‌کند Whois خراب است.
  • دامنه منقضی شده اما هنوز در مرورگر از کش باز می‌شود.
  • وضعیت clientHold باعث قطع DNS شده اما کاربر دنبال مشکل در هاست می‌گردد.
  • Nameserver در Whois با چیزی که کاربر در cPanel تغییر داده هماهنگ نیست.

سناریوهای واقعی که معمولاً رخ می‌دهد

سناریوی اول این است که کاربر تازه دامنه را به هاست یا سرور وصل کرده و انتظار دارد همان لحظه همه‌چیز برای همه کاربران باز شود. در موضوع «Whois چیست»، همیشه باید تفاوت بین تغییر واقعی در authoritative DNS و دیده شدن آن تغییر در کش کاربران را در نظر گرفت. اگر پاسخ authoritative درست باشد اما بخشی از کاربران هنوز خطا می‌بینند، نباید تنظیمات را چند بار پشت‌سرهم عوض کرد؛ این کار فقط زمان عیب‌یابی را طولانی‌تر می‌کند.

سناریوی دوم مربوط به جابه‌جایی سایت است. مدیر سایت IP یا Nameserver را تغییر می‌دهد اما رکوردهای ایمیل، زیر دامنه، CDN یا SSL را منتقل نمی‌کند. نتیجه این می‌شود که صفحه اصلی باز می‌شود ولی ایمیل قطع است، www خطا می‌دهد یا پنل مدیریت از آدرس قدیمی لود می‌شود. قبل از هر مهاجرت، باید یک فهرست از رکوردهای DNS و سرویس‌های وابسته تهیه شود.

سناریوی سوم زمانی اتفاق می‌افتد که مشکل در مرورگر دیده می‌شود اما ریشه آن در DNS یا SSL نیست. مثلاً کش افزونه وردپرس، کش LiteSpeed، تنظیمات Cloudflare، ریدایرکت قدیمی 301 یا حتی DNS مودم می‌تواند نتیجه تست را گمراه کند. برای همین در مقاله‌های فنی همیشه توصیه می‌شود تست نهایی با ابزارهایی مثل dig، curl و openssl انجام شود، نه فقط با یک مرورگر روی یک اینترنت.

سناریوی چهارم برای کاربران هاست اشتراکی است. این کاربران معمولاً دسترسی root ندارند و نمی‌توانند سرویس DNS یا وب‌سرور را reload کنند؛ اما باز هم می‌توانند با تست‌های ساده بفهمند مشکل از تنظیمات خودشان است یا باید از پشتیبانی هاست بخواهند رکورد، SSL، Feature Manager، AutoSSL، لاگ وب‌سرور یا محدودیت فایروال را بررسی کند.

برای کاربر هاست اشتراکی و مدیر سرور چه فرقی دارد؟

اگر فقط کاربر هاست اشتراکی هستید، معمولاً باید از پنل‌هایی مثل cPanel یا DirectAdmin تغییر را انجام دهید و خروجی تست‌ها را برای پشتیبانی ارسال کنید. در این حالت، دستورهای SSH بیشتر برای فهمیدن مسئله و مکاتبه دقیق‌تر با پشتیبانی مفید است. اما اگر مدیر سرور هستید، علاوه بر DNS باید سرویس‌هایی مثل named، PowerDNS، Nginx، Apache، فایروال، cron تمدید SSL و لاگ‌های سیستم را هم بررسی کنید.

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

روش عیب‌یابی مرحله‌به‌مرحله

  1. اول DNS را جدا تست کنید؛ اگر دامنه IP نمی‌دهد، هنوز سراغ SSL یا وردپرس نروید.
  2. بعد اتصال به سرور را تست کنید؛ اگر IP درست است اما سایت باز نمی‌شود، فایروال، وب‌سرور و virtual host را بررسی کنید.
  3. بعد SSL را تست کنید؛ اگر گواهی نامعتبر است، دامنه‌های داخل گواهی، تاریخ انقضا و زنجیره را ببینید.
  4. در پایان کش‌ها را پاک کنید؛ کش مرورگر، کش DNS سیستم، کش افزونه وردپرس، کش LiteSpeed یا CDN ممکن است نتیجه تست را اشتباه نشان دهد.

نکات امنیتی و عملی مهم

قبل از هر تغییر مهم، از تنظیمات فعلی خود یادداشت بگیرید یا اسکرین‌شات بگیرید. در DNS و SSL، یک تغییر کوچک مثل حذف رکورد MX یا فعال‌سازی ریدایرکت در دو جای مختلف می‌تواند باعث قطع سایت، ایمیل یا ایجاد خطاهای مرورگر شود.

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

چک‌لیست نهایی بعد از انجام کار

  • دامنه اصلی و www هر دو تست شده‌اند.
  • رکوردهای ایمیل مثل MX و TXT حذف یا خراب نشده‌اند.
  • HTTP به HTTPS فقط از یک مسیر اصلی ریدایرکت می‌شود و loop وجود ندارد.
  • گواهی SSL برای همه نام‌های لازم صادر شده و منقضی نیست.
  • سایت از اینترنت دیگر یا DNS عمومی هم درست باز می‌شود.

سوالات متداول

WHOIS و RDAP چه تفاوتی دارند؟

WHOIS قدیمی‌تر و متنی است، RDAP ساختارمندتر و مناسب‌تر برای پردازش ماشینی است.

آیا Whois اطلاعات کامل مالک را نشان می‌دهد؟

در بسیاری از دامنه‌ها نه؛ به‌خاطر حریم خصوصی، اطلاعات شخصی مخفی می‌شود.

کدام بخش Whois برای عیب‌یابی مهم‌تر است؟

Registrar، Expiration Date، Domain Status و Nameserverها معمولاً مهم‌ترین بخش‌ها هستند.

جمع‌بندی

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