رکوردهای DNS هرکدام وظیفه متفاوتی دارند؛ اشتباه گرفتن A، CNAME، MX یا TXT می‌تواند باعث قطع سایت، ایمیل یا SSL شود.

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

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

این مقاله نقش هر رکورد DNS را با مثال واقعی هاست، ایمیل، SSL، CDN و سرویس‌های جانبی توضیح می‌دهد و نشان می‌دهد چطور هر رکورد را تست کنیم.

بسیاری از کاربران وقتی سایت باز نمی‌شود یا 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. برای اتصال دامنه به IP از A یا AAAA استفاده کنید.
  2. برای اشاره یک نام به نام دیگر از CNAME استفاده کنید، نه برای دامنه اصلی در همه پنل‌ها.
  3. برای ایمیل، MX را با SPF/DKIM/DMARC در TXT کامل کنید.
  4. برای سرویس‌هایی مثل SIP، Minecraft یا بعضی سیستم‌های پیام‌رسان از SRV استفاده می‌شود.

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

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

# مشاهده رکوردهای اصلی
dig example.com A +short
dig example.com AAAA +short
dig www.example.com CNAME +short
dig example.com MX +short
dig example.com TXT +short
dig example.com NS +short

# رکورد SRV نمونه
dig _sip._tcp.example.com SRV

# تست از DNS مشخص
dig @1.1.1.1 example.com TXT

# تست کامل با پاسخ و TTL
dig example.com A +noall +answer

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

اگر 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 است، نه الزاماً خراب بودن تنظیم جدید.

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

  • قرار دادن CNAME برای ریشه دامنه در پنلی که از آن پشتیبانی نمی‌کند.
  • ساخت MX بدون رکورد A برای mail.example.com.
  • حذف TXTهای SPF یا DKIM هنگام تنظیم SSL یا سرویس ایمیل.
  • اشتباه گرفتن NS دامنه با NS داخلی یک DNS zone.

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

سناریوی اول این است که کاربر تازه دامنه را به هاست یا سرور وصل کرده و انتظار دارد همان لحظه همه‌چیز برای همه کاربران باز شود. در موضوع «رکوردهای DNS»، همیشه باید تفاوت بین تغییر واقعی در 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 عمومی هم درست باز می‌شود.

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

آیا یک دامنه می‌تواند چند رکورد A داشته باشد؟

بله، اما باید بدانید این کار load balancing ساده ایجاد می‌کند و اگر یکی از IPها خراب باشد بعضی کاربران خطا می‌بینند.

آیا TXT فقط برای ایمیل است؟

نه. TXT برای SPF، DKIM، DMARC، تأیید مالکیت دامنه، DNS-01 SSL و سرویس‌های مختلف استفاده می‌شود.

آیا MX به IP اشاره می‌کند؟

خیر. MX باید به یک نام هاست اشاره کند و آن نام هاست باید رکورد A یا AAAA معتبر داشته باشد.

جمع‌بندی

موضوع «آموزش کامل رکوردهای DNS؛ تفاوت A، AAAA، CNAME، MX، TXT، NS و SRV» زمانی واقعاً درست حل می‌شود که آن را به چند لایه جدا تقسیم کنیم: دامنه، Nameserver، رکوردهای DNS، پاسخ سرور، SSL، ریدایرکت و کش. اگر این ترتیب را رعایت کنید، به‌جای آزمون‌وخطای خطرناک، با چند تست ساده می‌توانید محل دقیق مشکل را پیدا کنید و فقط همان بخش را اصلاح کنید.