مدیریت وب‌سایت تنها به آپلود فایل روی هاست و طراحی فرانت‌اند خلاصه نمی‌شود. بسیاری از خطاهای مرموز مثل قطعی ناگهانی سایت، اسپم شدن ایمیل‌های تراکنشی، افت رتبه سئو به دلیل دان‌تایم مکرر، یا حتی حملات خطرناک DNS Hijacking و Subdomain Takeover، مستقیماً از عدم شناخت و پیکربندی اشتباه رکوردهای DNS سرچشمه می‌گیرند.
سامانه نام دامنه (DNS) دفترچه تلفن اینترنت است؛ اما برای یک مدیر فنی، DNS یک لایه توزیع‌شده از امنیت، مسیریابی و کنترل ترافیک به حساب می‌آید. در این راهنما، فراتر از تعاریف تکراری کتابخانه‌ای رفته و ۸ رکورد حیاتی سامانه نام دامنه را همراه با سناریوهای فنی، دستورات خط فرمان لینوکس جهت عیب‌یابی و دام‌های خطرناک در هاست‌های اشتراکی بررسی می‌کنیم.
۱. رکورد A (Address Record): ستون فقرات اتصال به سرور
رکورد A یک رکورد DNS است که وظیفه دارد یک نام دامنه یا زیردامنه را به یک آدرس عددی IPv4 (۳۲ بیتی) نگاشت کند. وقتی کاربر آدرس سایت شما را تایپ می‌کند، مرورگر ابتدا به دنبال این رکورد می‌گردد تا بداند پکت‌های HTTP/HTTPS را به کدام آی‌پی سرور تحویل دهد.
فرمت استاندارد (BIND):
example.com. 300 IN A 192.0.2.1 blog 300 IN A 192.0.2.2
نکته کاربردی و سناریوی خطر
بسیاری از مدیران هنگام انتقال هاست یا سرور (Migration)، با مشکل طولانی بودن زمان انتشار یا اصطلاحاً کش ماندن آی‌پی قدیمی مواجه می‌شوند.
- راهکار حرفه‌ای: ۲۴ تا ۴۸ ساعت قبل از جابه‌جایی سرور، مقدار TTL (Time to Live) رکورد A را از ۸۶۴۰۰ ثانیه (۲۴ ساعت) یا ۱۴۴۰۰ ثانیه به ۳۰۰ ثانیه (۵ دقیقه) کاهش دهید. پس از اطمینان از استقرار موفق در سرور جدید، TTL را مجدداً به مقدار استاندارد بازگردانید تا فشار کوئری به NameServerها کاهش یابد.
۲. رکورد AAAA (Quad-A Record): آماده‌سازی برای دنیای IPv6
مشابه رکورد A است، با این تفاوت که دامنه را به یک آدرس IPv6 (۱۲۸ بیتی) متصل می‌کند. با اتمام منابع IPv4 جهانی و مهاجرت سریع اپراتورهای موبایل و ارائه‌دهندگان اینترنت به شبکه‌های Dual-Stack، اهمیت این رکورد دوچندان شده است.
فرمت استاندارد:
example.com. 300 IN AAAA 2001:0db8:85a3:0000:0000:8a2e:0370:7334
هشدار سناریوی Dual-Stack Brokenness
اگر در پنل دامنه خود رکورد AAAA ثبت کنید(یک نوع رکورد DNS) در حالی که وب‌سرور شما (مانند Nginx یا Apache) به پورت IPv6 گوش نمی‌دهد (listen [::]:443 ssl)، کاربرانی که اتصال IPv6 فعال دارند با خطای Connection Timed Out یا افت محسوس سرعت بارگذاری اولیه (Happy Eyeballs Delay) روبه‌رو می‌شوند که ضربه سنگینی به نمره سئو فنی و Core Web Vitals می‌زند.
۳. رکورد CNAME (Canonical Name): نام مستعار با محدودیت رأس دامنه
رکورد CNAME یک نام دامنه را به نام دامنه دیگری (و نه آدرس IP) ارجاع می‌دهد. کاربرد رایج آن اتصال دامنه‌های سرویس‌دهنده شخص ثالث (مثل سطل‌های ذخیره‌سازی ابری S3، دیسک‌های دانلود یا پلتفرم‌های لندینگ‌پیج) است.
فرمت استاندارد:
static.example.com. 14400 IN CNAME cdn.arvancloud.ir. www 14400 IN CNAME example.com.
قانون حیاتی CNAME At Apex و خطر ایمیل‌ها
بر اساس استانداردهای RFC 1034 و RFC 1912، هیچ رکوردی نمی‌تواند در ریشه دامنه (Zone Apex یا Root Domain مثل example.com) هم‌زمان با یک CNAME تعریف شود.
اگر سعی کنید روی ریشه دامنه خود یک CNAME بگذارید، رکوردهای MX و SOA و NS نادیده گرفته شده و ارسال و دریافت کلیه ایمیل‌های سازمانی شما قطع می‌شود.
- راهکار: اگر نیاز دارید ریشه دامنه را به یک CDN متصل کنید، از راهکارهای جدید ارائه‌دهندگان مدرن DNS تحت عناوینی نظیر ANAME، ALIAS یا CNAME Flattening (مانند کلودفلر) استفاده کنید که CNAME را در لایه سرور نام به رکورد A حل و فصل می‌کنند.
۴. رکورد MX (Mail Exchanger): شاه‌راه دریافت ایمیل‌ها
این رکورد به سرورهای ایمیل جهانی اعلام می‌کند نامه‌های ارسالی به صندوق‌های کاربری سایت شما (info@example.com) باید به کدام سرورهای پستی تحویل داده شوند. رکورد MX دارای پارامتری به نام Priority (اولویت) است؛ عدد کمتر نشان‌دهنده اولویت بالاتر است.
فرمت استاندارد:
example.com. 14400 IN MX 10 mail1.example.com. example.com. 14400 IN MX 20 mail2.example.com.
تله خطرناک در هاست‌های اشتراکی (Local Mail Exchanger)
اگر هاست خود را از یک شرکت خریداری کرده‌اید اما ایمیل‌های سازمانی‌تان را روی Google Workspace یا Microsoft 365 ست کرده‌اید، حتماً وارد پنل هاست (مثلاً cPanel) شوید و در بخش Email Routing گزینه را از Local Mail Exchanger به Remote Mail Exchanger تغییر دهید. در غیر این صورت، فرم‌های تماسی که با وب‌سایت (وردپرس یا جوملا) ارسال می‌شوند فکر می‌کنند گیرنده در همان سرور محلی قرار دارد و ایمیل‌ها هرگز به اینباکس جیمیل یا اوت‌لوک شما تحویل نمی‌شوند.
در زمان قطعی اینترنت مبحث اهمیت رکورد DNS خیلی پررنگ می شود. در این شرایط تکنولوژی GeoDNS را پیشنهاد می دهیم.
۵. رکورد TXT (Text Record): شناسنامه امنیتی و تایید هویت
یک رکورد DNS با نام رکورد TXT به صاحبان دامنه اجازه می‌دهد متن‌های دلخواه متنی را در ساختار DNS ذخیره کنند. کاربرد اصلی آن اعتبارسنجی مالکیت دامنه (Google Search Console، ابزارهای مارکتینگ) و پیاده‌سازی مکانیزم‌های حیاتی ضدجعل ایمیل است.
سه کاربرد فوق‌العاده حیاتی این رکورد عبارتند از:
الف) SPF (Sender Policy Framework)
مشخص می‌کند چه آی‌پی‌ها یا سرویس‌هایی مجاز به ارسال ایمیل با نام دامنه شما هستند.
v=spf1 ip4:192.0.2.1 include:_spf.google.com ~all
هشدار: ثبت بیش از یک رکورد SPF برای یک دامنه نقض استاندارد است و باعث خطای PermError و رفتن ایمیل‌ها به پوشه Spam می‌شود. تمام مجورها باید در قالب یک خط ادغام شوند. همچنین تعداد جستجوهای دامنه‌ای (DNS Lookups) نباید از ۱۰ تجاوز کند.
ب) DKIM (DomainKeys Identified Mail)
رکورد DKIM یک رکورد DNS است که امضای رمزنگاری‌شده نامتقارن به هدر ایمیل‌ها اضافه می‌کند تا نشان دهد محتوای ایمیل در مسیر دستکاری نشده است. معمولاً به صورت یک زیردامنه مانند default._domainkey.example.com تعریف می‌شود.
ج) DMARC (Domain-based Message Authentication, Reporting, and Conformance)
سیاست نهایی را برای گیرنده‌ها تعیین می‌کند که اگر ایمیلی تست‌های SPF یا DKIM را پاس نکرد، چه سرنوشتی داشته باشد (رد کامل یا هدایت به هرزنامه).
- نمونه در دامنه pahnanet-az.ir
۶. رکورد NS (Name Server): مدیران سلسله‌مراتب دامنه
رکوردهای NS تعیین می‌کنند چه سرورهایی مرجع نهایی و دارای اختیار (Authoritative) پاسخگویی به استعلام‌های دامنه شما هستند. تغییر این رکوردها کل مسیر مسیریابی سایت و هاست را دستخوش تغییر می‌کند.
فرمت استاندارد:
example.com. 86400 IN NS ns1.hostingprovider.com. example.com. 86400 IN NS ns2.hostingprovider.com.
ریسک Lame Delegation
اگر در رجیسترار دامنه، NSهایی تعریف کرده باشید که در آن سرورها دیگر هیچ Zone دانشی برای دامنه شما وجود ندارد (مثلاً سرویس هاستینگ خود را لغو کرده‌اید ولی NSها را در پنل دامنه تغییر نداده‌اید)، دامنه شما در وضعیت معلق قرار می‌گیرد. مهاجمان در برخی سناریوها می‌توانند با ایجاد اکانت در همان ارائه‌دهنده با نام دامنه شما، کنترل ترافیک DNS را در دست بگیرند (Zone Hijacking).
۷. رکورد PTR (Pointer Record): اصالت‌سنجی معکوس (Reverse DNS)
یک رکورد DNS دیگر که برخلاف رکورد A که نام را به آی‌پی تبدیل می‌کند، رکورد PTR جهت اجرای Reverse DNS (rDNS) استفاده می‌شود و یک آدرس IP را به نام دامنه (FQDN) برمی‌گرداند.
1.2.0.192.in-addr.arpa. 86400 IN PTR mail.example.com.
کجا و چگونه باید آن را تنظیم کرد؟
شما نمی‌توانید رکورد PTR را در کنترل‌پنل دامنه یا کلودفلر ثبت کنید! این رکورد متعلق به مالک بازه آی‌پی است.
- اگر سرور اختصاصی یا VPS دارید، باید از طریق تیکت به دیتاسنتر یا پنل مدیریت شبکه سرور (مانند هرتزنر، OVH یا دیتاسنترهای داخلی) درخواست دهید که آی‌پی سرور شما به دامنه سرور پستی‌تان (rDNS) اشاره کند.
- اکثر سرویس‌دهندگان ایمیل مثل یاهو، جیمیل و مایکروسافت، اگر آی‌پی فرستنده دارای PTR معتبر متناظر با هدر HELO/EHLO سرور نباشد، ایمیل را بلافاصله Drop کرده یا با خطای
550 PTR record missingمسدود می‌کنند.
- اکثر سرویس‌دهندگان ایمیل مثل یاهو، جیمیل و مایکروسافت، اگر آی‌پی فرستنده دارای PTR معتبر متناظر با هدر HELO/EHLO سرور نباشد، ایمیل را بلافاصله Drop کرده یا با خطای
۸. رکورد CAA (Certification Authority Authorization): بیمه سرقت گواهینامه SSL
رکورد CAA یکی از ناشناخته‌ترین اما کلیدی‌ترین رکوردهای امنیتی است. این رکورد به مراکز صدور گواهینامه SSL/TLS (مثل Let’s Encrypt, Sectigo, DigiCert) دستور می‌دهد که تنها چه مراجعی حق دارند برای دامنه شما گواهی SSL صادر کنند.
فرمت استاندارد:
example.com. 3600 IN CAA 0 issue “letsencrypt.org” example.com. 3600 IN CAA 0 issuewild “;” example.com. 3600 IN CAA 0 iodef “mailto:security@example.com”
(توضیح: در مثال فوق، تنها لِتس‌انکریپت مجاز به صدور است، صدور گواهی وایلدکارد مسدود شده، و هرگونه تلاش مشکوک برای صدور به ایمیل امنیتی گزارش می‌شود)
چرا این رکورد حیاتی است؟
اگر مهاجمی بتواند موقتاً ترافیک BGP یا DNS شما را دور بزند یا رکوردهای اعتبارسنجی را جعل کند، نمی‌تواند از یک مرجع صدور متفرقه برای سایت شما گواهینامه امنیتی معتبر تهیه کرده و حمله Man-In-The-Middle (MITM) ترتیب دهد، زیرا آن مرجع موظف است قبل از صدور، رکورد CAA شما را چک کرده و درخواست را رد کند.
چک‌لیست عیب‌یابی DNS با ابزارهای خط فرمان (Linux CLI)
به‌عنوان یک متخصص و مدیر هاستینگ، نباید تنها به ابزارهای آنلاین وابسته باشید. دستورات بومی زیر سریع‌ترین راه برای عیب‌یابی رکوردهای DNS بدون تاثیرپذیری از کش سیستم هستند:
بررسی سریع یک رکورد خاص (مثلاً MX):
dig +short MX example.com
استعلام مستقیم از نیم‌سرور مبدأ (دور زدن کش اپراتور اینترنت):
dig @ns1.hostingprovider.com example.com A
بررسی رکورد معکوس (PTR) یک آی‌پی:
dig -x 192.0.2.1 +short
تست سلامت DMARC با ابزار nslookup:
nslookup -type=TXT _dmarc.example.com
جمع‌بندی: جدول مقایسه سریع رکوردهای DNS
| نام رکورد | مقصد / مقدار ورودی | اولویت امنیتی | مهم‌ترین کاربرد |
|---|---|---|---|
| A | آدرس IPv4 عددی | بحرانی | اتصال دامنه به وب‌سرور |
| AAAA | آدرس IPv6 هگزادسیمال | مهم | آمادگی برای شبکه نوین اینترنت |
| CNAME | نام دامنه دیگر (FQDN) | متوسط | ارجاع ساب‌دامین به سرویس‌های ابری |
| MX | نام سرور پستی + اولویت عددی | بحرانی | مدیریت دریافت نامه‌های سازمانی |
| TXT | رشته متنی (SPF, DKIM, DMARC) | بسیار بالا | هویت‌سنجی مالکیت و ضدجعل ایمیل |
| NS | آدرس نیم‌سرورهای مرجع | بحرانی | تفویض اختیار اختیارات دامنه |
| PTR | نام سرور متناظر با آی‌پی | بالا (برای ایمیل) | جلوگیری از اسپم شدن خروجی ایمیل سرور |
| CAA | نام CAهای مجاز صدور گواهی | بالا | پیشگیری از صدور گواهینامه SSL جعلی |
پیکربندی دقیق این ۸ رکورد، نه تنها در دسترس بودن بی‌وقفه سرویس‌های شما را تضمین می‌کند، بلکه لایه‌ای نفوذناپذیر در برابر خطاهای جعل ایمیل، ربودن ساب‌دامین‌ها و اختلال در تحویل ترافیک ایجاد خواهد کرد.