رکورد DNS چیست؟ راهنمای کاربردی A، CNAME، MX و TXT

هر درخواستی که به سایت شما می‌رسد، پیش از هر چیز از یک کوئری DNS عبور می‌کند. اگر این لایه اشتباه تنظیم شده باشد، سریع‌ترین سرور و بهترین CDN هم کاری از پیش نمی‌برد. بخش بزرگی از خرابی‌هایی که با جمله «سایت بالا نمی‌آید» گزارش می‌شوند، در عمل یک رکورد اشتباه یا یک TTL بد است.

DNS واقعاً چطور کار می‌کند؟

وقتی مرورگر می‌خواهد example.ir را باز کند، خودش چیزی نمی‌داند. سؤال را به یک resolver بازگشتی می‌دهد — همان سرویس DNS که روی سیستم یا مودم ست شده است. از اینجا زنجیره‌ای سه‌مرحله‌ای شروع می‌شود:

• Root — resolver می‌پرسد «مسئول دامنه‌های ir. کیست؟» و آدرس سرورهای TLD را می‌گیرد.
• TLD — از سرورهای ir. می‌پرسد «نیم‌سرورهای معتبر example.ir کدام‌اند؟». به این پاسخ delegation می‌گویند.
• Authoritative — از همان نیم‌سرورها مقدار نهایی رکورد را می‌گیرد و به مرورگر برمی‌گرداند.

این زنجیره فقط بار اول اجرا می‌شود؛ بعد از آن resolver پاسخ را تا پایان TTL در کش نگه می‌دارد.

مرزی که کنترل شما آنجا تمام می‌شود

شما فقط روی سرور authoritative کنترل دارید؛ تغییر آنجا در همان لحظه معتبر است. اما هزاران resolver هنوز نسخه قدیمی را در کش دارند و راهی برای پاک کردن کش آن‌ها نیست. تمام سوءتفاهم درباره «زمان اعمال تغییرات DNS» از همین‌جاست. nsin میزبانی کامل DNS ابری ارائه می‌دهد؛ نیم‌سرورهای معتبر و همه رکوردهای دامنه در یک پنل.

رکوردهایی که در عمل به آن‌ها نیاز دارید

فهرست انواع رکورد DNS طولانی است، اما در کار روزمره با همین هفت مورد سروکار دارید:

رکورد	کاربرد	نمونه مقدار
A	نگاشت نام به آدرس IPv4	example.ir → 203.0.113.10
AAAA	نگاشت نام به آدرس IPv6	example.ir → 2001:db8::10
CNAME	نام مستعار؛ ارجاع یک نام به نام دیگر	www.example.ir → example.ir
MX	مقصد ایمیل دامنه، همراه با اولویت	10 mail.example.ir
TXT	متن آزاد؛ تأیید مالکیت، SPF، DKIM	"v=spf1 include:_spf.example.ir -all"
NS	نیم‌سرورهای معتبر دامنه یا زیردامنه	ns1.example-dns.ir
CAA	تعیین اینکه کدام CA حق صدور گواهی دارد	0 issue "letsencrypt.org"

A و AAAA

ساده‌ترین رکوردها: یک نام را به یک IP وصل می‌کنند. می‌توانید چند رکورد A برای یک نام تعریف کنید، اما این توزیع بار نیست و health check ندارد؛ اگر یکی از آن IPها از دسترس خارج شود مرورگر بعد از شکست اتصال سراغ IP بعدی می‌رود، ولی هر بار چند ثانیه معطلی به کاربر تحمیل می‌شود و خیلی از کلاینت‌های غیرمرورگری این تلاش دوباره را اصلاً انجام نمی‌دهند. failover واقعی به لایه‌ای بالاتر از DNS نیاز دارد، مثل multi-origin failover در لبه.

CNAME

CNAME می‌گوید «جواب این نام را از نام دیگری بگیر». مزیتش این است که با تغییر IP مقصد، لازم نیست چیزی را در زون خودتان به‌روزرسانی کنید. محدودیت مهمش این است که نامی که CNAME دارد نمی‌تواند هیچ رکورد دیگری داشته باشد؛ روی www نمی‌توانید هم‌زمان CNAME و TXT بگذارید.

MX، NS و CAA

MX مشخص می‌کند ایمیل‌های دامنه به کدام سرور تحویل داده شود؛ عدد ابتدای مقدار اولویت است و مقدارش باید یک نام باشد، نه IP. رکوردهای NS در زون شما باید دقیقاً با delegation ثبت‌شده در ثبت‌کننده دامنه یکی باشند — ناهماهنگی این دو، منبع خطاهایی است که فقط برای بعضی کاربران رخ می‌دهد. CAA هم تعیین می‌کند فقط CAهای مشخصی حق صدور گواهی داشته باشند؛ اگر از گواهی رایگان و تمدیدشونده روی لبه استفاده می‌کنید، CAA باید صادرکننده آن را مجاز کرده باشد وگرنه صدور خودکار شکست می‌خورد. جزئیات را در راهنمای گواهی SSL رایگان آورده‌ایم.

مشکل CNAME روی ریشه دامنه

ریشه دامنه (apex، یعنی example.ir بدون زیردامنه) اجباراً رکوردهای SOA و NS دارد. چون CNAME نمی‌تواند کنار رکورد دیگری بنشیند، گذاشتن CNAME روی apex مجاز نیست. دقیقاً همین‌جاست که کاربران CDN گیر می‌کنند: سرویس یک نام می‌دهد، ولی ریشه دامنه را نمی‌شود به آن نام CNAME کرد. سه راه‌حل عملی وجود دارد:

• ALIAS / ANAME / CNAME flattening — سرور authoritative خودش نام مقصد را resolve می‌کند و رکورد A برمی‌گرداند؛ از بیرون یک A معمولی دیده می‌شود.
• رکورد A مستقیم به آدرس لبه — وقتی سرویس آدرس ثابتی در اختیارتان می‌گذارد، ساده‌ترین گزینه است.
• ریدایرکت از apex به www — کم‌هزینه است ولی یک پرش اضافه به مسیر کاربر تحمیل می‌کند.

وقتی DNS و لبه در یک سرویس باشند، این مسئله عملاً از بین می‌رود.

TTL دقیقاً چه چیزی را کنترل می‌کند؟

TTL یعنی «این پاسخ چند ثانیه قابل کش شدن است». شمارش از لحظه‌ای شروع می‌شود که resolver پاسخ را گرفته، نه از لحظه‌ای که شما رکورد را ویرایش کرده‌اید. با TTL=3600، یک resolver که ۵ دقیقه پیش پاسخ گرفته، تا ۵۵ دقیقه دیگر مقدار قدیمی را تحویل می‌دهد. دو نکته معمولاً از قلم می‌افتد:

• کش منفی هم وجود دارد. پاسخ NXDOMAIN هم کش می‌شود و طول آن را فیلد minimum در رکورد SOA تعیین می‌کند؛ یعنی رکورد جاافتاده را بعد از اضافه کردن هم باید منتظر بمانید.
• TTL یک درخواست است، نه دستور. بعضی resolverها کف یا سقف خودشان را اعمال می‌کنند.

منطقش همان منطق کش لبه است، با یک تفاوت مهم: کش لبه را می‌شود purge کرد، کش resolverهای دنیا را نه.

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

چرا «پروپاگیشن» اسم اشتباهی است

جمله رایج «تغییرات DNS تا ۲۴ ساعت طول می‌کشد» این تصور را می‌سازد که داده‌ای بین سرورها پخش می‌شود. چنین چیزی وجود ندارد؛ آن ۲۴ ساعت فقط حداکثر عمر کش‌های قدیمی است — برای همین تغییر برای یک کاربر فوری اعمال می‌شود و برای کاربر بغل‌دستی‌اش نه. به‌جای سایت‌های «بررسی propagation»، مستقیم از سرور معتبر بپرسید:

dig +trace example.ir
dig @ns1.example-dns.ir example.ir A

اگر سرور معتبر مقدار درست را می‌دهد ولی resolver عمومی نه، کار شما تمام است و فقط باید صبر کنید.

نقشه تغییر نیم‌سرور بدون قطعی

خطرناک‌ترین لحظه، تغییر delegation در ثبت‌کننده دامنه است؛ TTL آن را سرورهای TLD تعیین می‌کنند، در کنترل شما نیست و کوتاه هم نیست. پس ترتیب کار اهمیت دارد:

مرحله	زمان	کار
۱	چند روز قبل	TTL همه رکوردهای مهم را روی TTL=300 بیاورید
۲	یک روز قبل	زون کامل را در سرویس جدید بسازید؛ تک‌تک رکوردها
۳	قبل از سوئیچ	با dig @ از نیم‌سرورهای جدید بپرسید و با زون قدیم مقایسه کنید
۴	روز سوئیچ	NS را در ثبت‌کننده دامنه عوض کنید و زون قدیم را دست‌نخورده بگذارید
۵	چند روز بعد	زون قدیم را حذف نکنید؛ لاگ و ترافیک را رصد کنید
۶	بعد از پایداری	TTLها را به مقدار عادی مثل TTL=3600 برگردانید

مرحله دوم بیشترین قربانی را می‌گیرد: مهاجرت‌های ناموفق تقریباً همیشه به این دلیل‌اند که فقط رکورد A منتقل شده و MX، TXT مربوط به SPF، رکورد DKIM یا یک زیردامنه فراموش‌شده جا مانده است. مراحل عملی اتصال به لبه بدون قطعی را هم در راه‌اندازی CDN بدون داون‌تایم نوشته‌ایم. در پنجره مهاجرت، خزنده گوگل هم مثل کاربر عادی به کش resolver وابسته است و حذف زودهنگام زون قدیم می‌تواند به ایندکس آسیب بزند؛ این موضوع را در دسترسی Googlebot از ایران بررسی کرده‌ایم.

TXT برای تأیید مالکیت و ایمیل

رکورد TXT نقشی در مسیریابی ترافیک ندارد، اما سه کاربرد حیاتی دارد:

• تأیید مالکیت دامنه — سرویس‌هایی مثل Search Console یک رشته یکتا می‌دهند تا روی apex بگذارید. بعد از تأیید پاکش نکنید؛ بعضی سرویس‌ها دوره‌ای دوباره آن را می‌خوانند.
• SPF — مشخص می‌کند چه سرورهایی حق ارسال ایمیل با دامنه شما را دارند. برای هر دامنه فقط یک رکورد SPF مجاز است؛ دو رکورد v=spf1 یعنی SPF خراب. کل رشته هم نباید بیش از ۱۰ بار جست‌وجوی DNS ایجاب کند.
• DKIM — کلید عمومی امضای ایمیل روی نامی مثل selector._domainkey.example.ir؛ اگر پنل DNS مقدار بلند آن را درست به چند رشته نشکند، امضاها اعتبارسنجی نمی‌شوند.

مرجع کامل تعریف هر کدام از این رکوردها در مستندات فنی آمده است.

پرسش‌های متداول

فرق رکورد A و CNAME چیست؟

رکورد A مستقیماً یک IP می‌دهد و CNAME نام را به نام دیگری ارجاع می‌دهد. A یک مرحله سریع‌تر است ولی با هر تغییر IP باید دستی عوض شود؛ CNAME انعطاف‌پذیرتر است اما روی ریشه دامنه کار نمی‌کند.

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

روی سرور معتبر، بی‌درنگ. چیزی که طول می‌کشد انقضای کش resolverهاست و حداکثر به اندازه TTL قبلی همان رکورد است. اگر از قبل TTL را پایین آورده باشید، به چند دقیقه کاهش پیدا می‌کند.

چرا سایتم برای بعضی باز می‌شود و برای بعضی نه؟

تقریباً همیشه یعنی resolverهای مختلف پاسخ‌های متفاوتی در کش دارند، یا رکوردهای NS شما با delegation ثبت‌شده در ثبت‌کننده دامنه یکی نیست. اول با dig مستقیم از هر نیم‌سرور بپرسید و پاسخ‌ها را مقایسه کنید.

برای استفاده از CDN باید رکوردهایم را عوض کنم؟

بله، رکورد سایت باید به لبه اشاره کند. اما رکوردهای غیرمرتبط با وب — مثل MX و TXT — باید بدون تغییر بمانند تا ایمیل شما دست‌نخورده کار کند.

DNS جایی است که با کمترین تلاش می‌شود بیشترین خرابی را ساخت و با کمی نظم، کاملاً قابل پیش‌بینی‌اش کرد. اگر می‌خواهید DNS و لبه را یکجا مدیریت کنید، دامنه‌تان را در پنل nsin اضافه کنید؛ هر دامنه جدید هفت روز نسخه کامل Enterprise را رایگان دارد — فرصت خوبی برای انتقال زون با TTL پایین و تست کامل قبل از سوئیچ نهایی.