آموزش رکوردهای DNS به زبان ساده — از A تا CAA

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

هر رکورد DNS از چه اجزایی ساخته شده است؟

هر رکورد در فایل زون (Zone) چهار جزء دارد: نام، TTL، نوع و مقدار. پنل‌های مدیریت DNS همین چهار ستون را نشان می‌دهند، اما زیر پوستشان چیزی شبیه این ذخیره می‌شود:

; name              TTL    class type  value
example.ir.         3600   IN    A     203.0.113.10
www.example.ir.     3600   IN    CNAME example.ir.
example.ir.         3600   IN    MX    10 mail.example.ir.
example.ir.         3600   IN    TXT   "v=spf1 mx ~all"

ستون class عملاً همیشه IN است و در هیچ پنلی از شما پرسیده نمی‌شود. دو نکته: نام رکورد در فایل زون کامل و با نقطه‌ی انتهایی نوشته می‌شود؛ در پنل‌ها معمولاً فقط بخش نسبی را وارد می‌کنید — www یا @ برای خود دامنه. دوم اینکه ترکیب «نام + نوع» می‌تواند چند مقدار داشته باشد؛ به آن RRset می‌گویند و دلیل این است که دو رکورد MX یا سه رکورد A روی یک نام کاملاً قانونی‌اند.

رکوردها روی «نِیم‌سرورهای معتبر» دامنه نگهداری می‌شوند، اما کاربر نهایی مستقیم با آن‌ها حرف نمی‌زند؛ مرورگر از یک ریزالور (سرور DNS اپراتور یا سرویس عمومی) می‌پرسد و آن پاسخ را مدتی کش می‌کند. تقریباً همه‌ی سردرگمی‌های «چرا تغییرم اعمال نشد؟» از همین فاصله می‌آید.

رکورد A و AAAA — قلب ماجرا

رکورد A می‌گوید «این نام، این آی‌پی نسخه‌ی ۴ است»؛ AAAA همین کار را برای IPv6 می‌کند.

example.ir.       A      203.0.113.10
www.example.ir.   A      203.0.113.10

برای وصل‌کردن دامنه به سرور ابری معمولاً همین دو خط کافی است: یکی برای دامنه‌ی اصلی، یکی برای www. روی ریشه‌ی دامنه هم A و هم AAAA مجازند؛ آنچه استاندارد ممنوع کرده، CNAME روی ریشه است.

می‌توانید برای یک نام چند رکورد A تعریف کنید؛ نِیم‌سرور همه را برمی‌گرداند و ترتیبشان را بین درخواست‌ها می‌چرخاند (round-robin). اما یک سوءتفاهم پرهزینه اینجاست: round-robin ساده هیچ اطلاعی از سلامت سرورها ندارد؛ اگر یکی از آی‌پی‌ها از کار بیفتد، DNS همچنان آن را به سهم خودش تحویل می‌دهد و بخشی از بازدیدکننده‌ها به سرور مرده می‌روند.

درباره‌ی AAAA یک قاعده را رعایت کنید: فقط وقتی AAAA بسازید که سرور واقعاً روی همان آدرس IPv6 سرویس می‌دهد. مرورگرها اگر AAAA ببینند اول IPv6 را امتحان می‌کنند، اما با الگوریتم Happy Eyeballs (RFC 8305) حدود ۲۵۰ میلی‌ثانیه بعد IPv4 را هم موازی امتحان می‌کنند؛ پس اتصال قطع نمی‌شود، ولی همان ربع‌ثانیه به هر بار باز شدن سایت اضافه می‌شود — کندی‌ای که برای خود شما، اگر شبکه‌تان IPv6 نداشته باشد، اصلاً دیده نمی‌شود.

CNAME — نام مستعار و قاعده‌هایی که شکستنی نیستند

CNAME یک نام را به نام دیگری حواله می‌دهد (نه به آی‌پی):

blog.example.ir.  CNAME  example.ir.

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

نتیجه‌ی عملی را زیاد می‌بینید: سرویسی می‌خواهد example.ir را با CNAME به نام میزبان او وصل کنید و پنل خطا می‌دهد. راه‌حل استاندارد، رکورد A روی ریشه است و یک CNAME از www به ریشه.

MX — ایمیل دامنه به کجا تحویل داده می‌شود؟

MX مشخص می‌کند ایمیل‌های you@example.ir به کدام سرور تحویل شوند. عددِ کنارش «اولویت» است — کوچک‌تر یعنی مقدم‌تر:

example.ir.  MX  10 mail.example.ir.
example.ir.  MX  20 mail2.example.ir.

سرور فرستنده اول سراغ اولویت ۱۰ می‌رود و تنها اگر پاسخی نگیرد به ۲۰ رجوع می‌کند؛ دو MX با عدد یکسان یعنی پخش بار بین آن دو.

سه محدودیت را جدی بگیرید. مقدار MX باید یک نام میزبان باشد که خودش رکورد A یا AAAA دارد — نه آی‌پی خام و نه نام مستعار CNAME. MX روی ریشه فقط نشانی‌های @example.ir را پوشش می‌دهد؛ ایمیل روی یک زیردامنه به MX جداگانه نیاز دارد. و مهم‌تر از همه: پیش از افزودن MX جدید، MXهای قدیمی را حذف کنید؛ باقی‌ماندن رکوردی با اولویت کمتر یعنی بخشی از نامه‌ها بی‌سروصدا به مقصد اشتباه می‌رود.

مقادیر MX سرویس‌های ایمیل تغییر می‌کنند، پس دقیقاً از مستندات همان سرویس کپی کنید. برای نمونه مستندات فعلی Google Workspace برای راه‌اندازی‌های تازه، به‌جای پنج رکورد قدیمی یک رکورد را کافی می‌داند:

example.ir.  MX  1 smtp.google.com.

و نکته‌ای که بیشترین سوءتفاهم را می‌سازد: MX فقط درباره‌ی دریافت است. اینکه ایمیل ارسالی به اینباکس برسد یا به اسپم، به رکوردهای TXT بخش بعد بستگی دارد — حتی روی هاست اشتراکی خودتان.

TXT — متن آزاد، اما حیاتی

TXT ظاهراً فقط متن آزاد است، اما سه کار کلیدی روی دوش آن است:

• SPF — می‌گوید چه سرورهایی حق دارند از طرف دامنه‌ی شما ایمیل بفرستند:

  example.ir.  TXT  "v=spf1 mx ~all"

• DKIM/DMARC — امضای دیجیتال و سیاست برخورد با ایمیل‌های جعلی؛ بدون این‌ها ایمیل‌هایتان راهی اسپم می‌شوند — ساخت درست هر سه رکورد را در راهنمای رفع اسپم‌شدن ایمیل آورده‌ایم.
• تأیید مالکیت — گوگل سرچ‌کنسول، مایکروسافت ۳۶۵ و بسیاری سرویس‌های دیگر برای احراز دامنه یک TXT مشخص از شما می‌خواهند. اینماد استثناست: احراز مالکیت آنجا با آپلود یک فایل متنی خالی با نام اعلام‌شده در پنل، داخل پوشه‌ی public_html انجام می‌شود — نه با رکورد DNS.

سه محدودیت مستند هست که نادیده‌گرفتنشان گران تمام می‌شود. اول، یک دامنه فقط یک رکورد SPF دارد؛ دو رکوردی که با v=spf1 شروع شوند نتیجه‌شان خطای permerror است و عملاً هیچ SPFای ندارید — سرویس‌های مختلف را باید با include: در یک رکورد جمع کنید. دوم، طبق بند 4.6.4 از RFC 7208 ارزیابی SPF حداکثر ۱۰ جست‌وجوی DNS اجازه دارد و هر include، a، mx، ptr و exists و نیز redirect یکی از آن ده تا را مصرف می‌کند؛ در مقابل all، ip4 و ip6 هیچ جست‌وجویی نمی‌سازند. سوم، هر رشته‌ی متنی داخل TXT حداکثر ۲۵۵ بایت است؛ کلیدهای بلند DKIM به همین دلیل به چند رشته‌ی داخل گیومه تقسیم می‌شوند.

محل این رکوردها هم ثابت است و اشتباه‌کردنش یعنی رکورد بی‌اثر: SPF روی خود دامنه، DKIM روی selector._domainkey.example.ir که «selector» را سرویس ایمیل می‌دهد، و DMARC روی _dmarc.example.ir. در DMARC فقط v=DMARC1 باید اولین برچسب باشد و ترتیب بقیه آزاد است؛ مقدار p یکی از none، quarantine یا reject است و اگر ننویسیدش رکورد مثل p=none رفتار می‌کند — با این حال نوشتن صریحش توصیه می‌شود. مرجع فعلی RFC 9989 است که از اردیبهشت ۱۴۰۵ جای RFC 7489 را گرفته و برچسب pct را حذف کرده است:

_dmarc.example.ir.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.ir"

NS — چه کسی پاسخ‌گوی دامنه است؟

NS اعلام می‌کند رکوردهای دامنه روی کدام نِیم‌سرورها نگهداری می‌شود. وقتی مدیریت DNS دامنه را به سرویسی مثل DNS مهران هاست می‌سپارید، در پنل ثبت دامنه (ایرنیک یا ثبت‌کننده‌ی بین‌المللی) NSها را به نِیم‌سرورهای اعلام‌شده تغییر می‌دهید.

نکته‌ی کمتر گفته‌شده این است که NS در دو جا ثبت می‌شود: نزد ثبت‌کننده‌ی دامنه که به دامنه‌ی بالادستی (مثلاً .ir) اعلام می‌کند کجا را بپرسد، و داخل خود زون. آنچه دنیای بیرون از آن پیروی می‌کند نسخه‌ی سمت ثبت‌کننده است؛ ویرایش NS داخل پنل DNS بدون تغییر آن در پنل ثبت دامنه، هیچ اتفاقی نمی‌اندازد.

تغییر نِیم‌سرور از تغییر بقیه‌ی رکوردها کندتر است، چون TTL ارجاع در دامنه‌ی بالادستی معمولاً ۲۴ تا ۴۸ ساعت است و کنترلی روی آن ندارید. پس ترتیب کار اهمیت دارد: اول همه‌ی رکوردها را در سرویس جدید بسازید و بررسی کنید، بعد NS را جابه‌جا کنید و زون قدیمی را دست‌کم یک هفته دست‌نخورده بگذارید. اگر این بخشی از یک جابه‌جایی کامل است، ترتیب مراحل را در راهنمای انتقال سایت به هاست جدید آورده‌ایم.

SRV و CAA — دو رکورد تخصصی‌تر

SRV آدرس و پورت یک «سرویس» خاص را معرفی می‌کند (VoIP، بازی‌ها، برخی چت‌سرورها). نام رکورد در SRV قالب ثابتی دارد که با زیرخط شروع می‌شود — _service._proto.name — و مقدارش چهار بخش است: اولویت، وزن، پورت و نام میزبان مقصد:

_sip._tcp.example.ir.  SRV  10 60 5060 sip1.example.ir.
_sip._tcp.example.ir.  SRV  10 40 5060 sip2.example.ir.

اولویت مثل MX عمل می‌کند و «وزن» فقط بین رکوردهای هم‌اولویت معنا دارد: در مثال بالا حدود ۶۰ درصد اتصال‌ها به سرور اول می‌رود.

CAA تعیین می‌کند فقط کدام مرجع صدور گواهی اجازه دارد برای دامنه‌ی شما SSL صادر کند:

example.ir.  CAA  0 issue "letsencrypt.org"

سه بخش مقدار به‌ترتیب «پرچم»، «برچسب» و «مقدار» است و برچسب‌هایی که به گواهی TLS مربوط می‌شوند سه‌تاست: issue برای صدور معمولی، issuewild که فقط گواهی‌های وایلدکارت را پوشش می‌دهد و برای آن‌ها جایگزین issue می‌شود، و iodef که نشانی گزارش تخلف را اعلام می‌کند. برچسب‌های دیگری مثل issuemail هم ثبت شده‌اند که به گواهی ایمیل مربوط‌اند، نه SSL سایت. شناسه‌ی هر مرجع را از مستندات خودش بردارید؛ Let's Encrypt دقیقاً letsencrypt.org را می‌پذیرد.

دو نکته‌ی عملی: نبودِ هیچ رکورد CAA یعنی «همه مجازند»، پس CAA فقط وقتی سودمند است که بسازیدش. و طبق مصوبه‌ی CA/Browser Forum نتیجه‌ی بررسی تا TTL همان رکورد یا ۸ ساعت — هرکدام بیشتر — معتبر می‌ماند؛ پس بعد از اصلاح CAA کمی صبر کنید. مراحل گرفتن گواهی رایگان در آموزش نصب SSL رایگان با Certbot آمده است.

TTL چقدر باشد؟ حافظه‌ی جهان از رکورد شما

هر رکورد یک TTL دارد: مدتی که DNSسرورهای دنیا اجازه دارند پاسخ را کش کنند. TTL بالا (مثلاً ۱ روز) یعنی بار کمتر ولی انتشار کُند تغییرات؛ TTL پایین (۵ دقیقه) یعنی تغییر سریع. ترفند حرفه‌ای‌ها: یک روز پیش از جابه‌جایی سرور، TTL را کم کنید. این توصیه سلیقه‌ای نیست — RFC 1912 همین ترتیب را پیشنهاد می‌کند (آنجا درباره‌ی فیلد minimum در SOA که آن زمان نقش TTL پیش‌فرض زون را داشت): کم کنید، به‌اندازه‌ی TTL قبلی صبر کنید، تغییر را اعمال و بررسی کنید، دوباره بالا ببرید.

یک TTL دوم هم هست: TTL منفی. وقتی نامی وجود نداشته باشد، ریزالور همین «نبودن» را هم کش می‌کند و مدتش از رکورد SOA زون می‌آید. یعنی اگر زیردامنه‌ای را پیش از ساختنش تست کرده باشید، پاسخ منفی ساعتی در کش می‌ماند و رکورد درستِ جدید تا انقضای آن دیده نمی‌شود. RFC 2308 بازه‌ی یک تا سه ساعت را برای این مقدار منطقی می‌داند.

و یک اصطلاح گمراه‌کننده را کنار بگذاریم: «انتشار DNS» وجود ندارد؛ چیزی از سرور شما به دنیا «پخش» نمی‌شود. نِیم‌سرور معتبر از همان ثانیه پاسخ جدید را می‌دهد و تنها چیزی که طول می‌کشد، منقضی‌شدن نسخه‌های قدیمی در کش است. پس «تا ۷۲ ساعت صبر کنید» یک حاشیه‌ی امن است، نه عدد فنی: با TTL سیصدثانیه‌ای، سقف انتظار واقعی هم در همان حدود است.

جدول مرور سریع رکوردهای DNS

عیب‌یابی رکوردهای DNS با dig و nslookup

پیش از هر حدسی، یک بار بپرسید. روی لینوکس و مک، دستور dig کوتاه‌ترین راه است — اگر نصب نبود، در اوبونتو و دبیان با sudo apt install bind9-dnsutils و در راکی و آلما با sudo dnf install bind-utils نصبش کنید:

dig +short example.ir A
203.0.113.10

dig +short example.ir MX
10 mail.example.ir.

dig +short _dmarc.example.ir TXT
"v=DMARC1; p=none; rua=mailto:dmarc@example.ir"

ترفند اصلی: یک بار از نِیم‌سرور معتبر و یک بار از ریزالور عمومی بپرسید. اگر پاسخ‌ها فرق داشت، رکورد درست ذخیره شده و فقط با کش طرفید؛ اگر نِیم‌سرور معتبر هم قدیمی جواب می‌دهد، مشکل از خود رکورد است:

dig @ns1.example-dns.ir example.ir A +noall +answer
example.ir.  3600  IN  A  203.0.113.10

dig @8.8.8.8 example.ir A +noall +answer
example.ir.  1784  IN  A  198.51.100.20

عدد دوم در پاسخ ریزالور عمومی، TTL باقی‌مانده‌ی نسخه‌ی کش‌شده است: این پاسخ قدیمی حدود نیم‌ساعت دیگر منقضی می‌شود. TTL منفی زون هم کمترینِ این دو عدد است: آخرین فیلد رکورد SOA (همان minimum) و TTL خود رکورد SOA — طبق RFC 2308. در نمونه‌ی زیر هر دو ۳۶۰۰ ثانیه‌اند:

dig +noall +answer example.ir SOA
example.ir.  3600  IN  SOA  ns1.example-dns.ir. hostmaster.example.ir. 2026090701 10800 3600 604800 3600

روی ویندوز معادل تقریبی همین کار با nslookup -type=MX example.ir 8.8.8.8 انجام می‌شود. جدول زیر رایج‌ترین نشانه‌ها را به علت و راه‌حلشان وصل می‌کند:

اشتباه‌های رایج در تنظیم رکوردها

1. فراموش‌کردن www — دامنه باز می‌شود اما www نه (یا برعکس). هر دو را تعریف کنید.
2. کپی‌نکردن نقطه‌ی انتهایی در مقادیر CNAME/MX — نتیجه‌اش رکوردی مثل mail.example.ir.example.ir می‌شود؛ پیش از ذخیره مقدار نهایی را یک بار بخوانید.
3. ساختن رکورد روی زون اشتباه — اگر NS دامنه هنوز به ارائه‌دهنده‌ی قبلی اشاره کند، رکورد تازه هیچ اثری ندارد؛ با dig +short example.ir NS مطمئن شوید کدام زون پاسخ‌گوست.
4. TTL شصت‌ثانیه‌ای دائمی — TTL پایین ابزار دوره‌ی جابه‌جایی است، نه تنظیم همیشگی؛ نگه‌داشتنش یعنی هر بازدیدکننده تقریباً همیشه یک جست‌وجوی کامل DNS را از نو انجام می‌دهد.

مدیریت رکوردهای DNS در پنل مهران هاست

سرویس مدیریت DNS مهران هاست همین هشت نوع رکورد را پوشش می‌دهد: A، AAAA، CNAME، MX، TXT، NS، SRV و CAA. کمترین TTL قابل‌انتخاب ۶۰ ثانیه و پیش‌فرض ۳۶۰۰ ثانیه است. اولویت MX و SRV فیلد جداگانه دارد، نام میزبان‌ها با نقطه‌ی انتهایی نرمال‌سازی می‌شوند و TXT بدون گیومه خودکار گیومه‌گذاری می‌شود؛ یعنی چند تله‌ی بالا پیش از ذخیره گرفته می‌شوند.

دو قابلیت هم روی رکوردهای A هست. اول بالانسینگ هوشمند: دست‌کم دو آی‌پی زیر یک نام، با انتخاب بر پایه‌ی «نزدیک‌ترین موقعیت جغرافیایی» یا «تصادفی»، و به‌دلخواه یک بررسی سلامت که روی همه‌ی آن آی‌پی‌ها اجرا می‌شود — یک آدرس HTTP/HTTPS یا باز بودن یک پورت TCP. این همان چیزی است که round-robin ساده ندارد: آی‌پی مردود از چرخه‌ی پاسخ کنار می‌رود. دوم، کنار هر رکورد A یک کلید CDN هست؛ با روشن‌کردنش آی‌پی مبدأ پنهان می‌شود و پاسخ عمومی به نزدیک‌ترین نود لبه تغییر می‌کند، بدون هزینه‌ی جداگانه روی دامنه‌ای که DNS آن اینجا مدیریت می‌شود. اینکه چه چیزی روی نود کش می‌شود و چه چیزی نه، در راهنمای CDN چیست آمده است.

با همین چند رکورد، بخش بزرگی از کارهای روزمره‌ی DNS پوشش داده می‌شود — همه‌شان از یک پنل فارسی و بدون ویرایش دستی فایل زون. قدم بعدی: دامنه را به سرور وصل و سایت را با HTTPS بالا بیاورید.

سؤالات پرتکرار

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

رکوردهای DNS خط‌هایی در فایل زون دامنه هستند که هر نام را به یک مقصد یا مقدار متنی وصل می‌کنند. پرکاربردترین‌ها هشت نوع‌اند: A و AAAA نام را به آی‌پی نسخه ۴ و ۶ می‌رسانند، CNAME نام را به نام دیگری حواله می‌دهد، MX مقصد دریافت ایمیل را تعیین می‌کند، TXT بار SPF و DKIM و DMARC و تأیید مالکیت را می‌برد، NS نِیم‌سرورهای معتبر را اعلام می‌کند و SRV و CAA به‌ترتیب آدرس یک سرویس و مرجع مجاز صدور SSL را می‌گویند.

تفاوت رکورد A و CNAME چیست و کدام را انتخاب کنم؟

رکورد A مستقیماً به یک آدرس آی‌پی اشاره می‌کند و CNAME به نام دیگری حواله می‌دهد که خودش باید در نهایت به آی‌پی برسد. برای ریشه‌ی دامنه باید از A (یا AAAA اگر IPv6 دارید) استفاده کنید، چون استاندارد اجازه نمی‌دهد CNAME کنار رکوردهای اجباری ریشه بنشیند. برای زیردامنه‌ها اگر مقصد سرویسی بیرونی است که ممکن است آی‌پی‌اش عوض شود CNAME بهتر است؛ اگر سرور خودتان است، A ساده‌تر و یک مرحله سریع‌تر است.

تغییر رکورد DNS چقدر طول می‌کشد تا اعمال شود؟

نِیم‌سرور معتبر بلافاصله پاسخ جدید را می‌دهد؛ آنچه زمان می‌برد منقضی‌شدن نسخه‌ی قدیمی در کش ریزالورهاست و سقفش تقریباً برابر TTL همان رکورد پیش از تغییر است. برای رکوردی با TTL پنج‌دقیقه‌ای، چند دقیقه؛ برای TTL یک‌روزه، تا یک شبانه‌روز. تغییر نِیم‌سرور استثناست و می‌تواند ۲۴ تا ۴۸ ساعت طول بکشد، چون TTL ارجاع در دامنه‌ی بالادستی دست شما نیست.

چرا نمی‌توانم روی دامنه‌ی اصلی رکورد CNAME بسازم؟

چون استاندارد DNS اجازه نمی‌دهد یک نام هم‌زمان CNAME و رکورد دیگری داشته باشد، و ریشه‌ی دامنه همیشه رکوردهای SOA و NS دارد؛ پس هرگز خالی نیست. راه‌حل استاندارد این است که ریشه را با رکورد A به آی‌پی مقصد وصل کنید و برای زیردامنه‌هایی مثل www از CNAME استفاده کنید. بعضی ارائه‌دهنده‌ها قابلیت غیراستانداردی به نام ALIAS دارند، اما این یک افزونه است و همه‌جا در دسترس نیست.

چطور مطمئن شوم رکورد DNS من درست ثبت شده است؟

با دستور dig یک بار از نِیم‌سرور معتبر دامنه و یک بار از یک ریزالور عمومی بپرسید و دو پاسخ را مقایسه کنید. اگر نِیم‌سرور معتبر مقدار درست را برمی‌گرداند ولی ریزالور عمومی نه، رکورد سالم است و فقط باید تا انقضای TTL صبر کنید. اگر نِیم‌سرور معتبر هم مقدار قدیمی می‌دهد، رکورد ذخیره نشده یا روی زونی ساخته شده که پاسخ‌گوی دامنه نیست.