رکوردهای DNS اطلاعاتی هستند که مشخص می‌کنند یک نام دامنه چه آدرسی دارد، ایمیل آن کجا دریافت می‌شود یا چه داده‌ای برای تأیید یک سرویس ارائه می‌کند. نوع رکورد تعیین می‌کند مقدار آن باید IP باشد، نام میزبان باشد یا متن. به همین دلیل، انتخاب نوع درست به‌اندازهٔ وارد کردن مقدار درست اهمیت دارد.
برای نمونه، تغییر رکورد A سایت لزوماً مقصد ایمیل را تغییر نمی‌دهد و ساخت CNAME هم نشانی مرورگر را به صفحهٔ دیگری منتقل نمی‌کند. در این راهنما، انواع رکورد DNS را با یک مثال پیوسته می‌خوانیم تا بدانید هر فیلد چه معنایی دارد و پیش از ویرایش چه چیزی را بررسی کنید. اگر با نقش DNS آشنا نیستید، ابتدا مقالهٔ DNS چیست و چگونه کار می‌کند را ببینید.
هر رکورد DNS از چه بخش‌هایی تشکیل می‌شود؟
رکوردها در محدودهٔ مدیریتی مشخصی به نام Zone نگهداری می‌شوند. پنل‌ها معمولاً فیلدهای زیر را نمایش می‌دهند، هرچند نام و نحوهٔ ورود آن‌ها ممکن است متفاوت باشد:
- نام یا Host: نامی که اطلاعات به آن مربوط است؛ مانند دامنهٔ اصلی یا زیردامنهٔ www. نماد @ در بسیاری از پنل‌ها به ریشهٔ Zone اشاره می‌کند.
- نوع یا Type: مشخص می‌کند داده از چه جنسی است؛ مثلاً A برای IPv4 و MX برای مقصد دریافت ایمیل.
- مقدار یا Value: دادهٔ همان رکورد است. برای MX معمولاً اولویت هم در فیلدی جدا وارد می‌شود.
- زمان نگهداری در کش یا TTL: مدت مجاز ذخیرهٔ پاسخ در کش، معمولاً برحسب ثانیه است؛ نه زمان تضمین‌شدهٔ فعال شدن سرویس.
یک رکورد در فایل متنی Zone می‌تواند چنین شکلی داشته باشد:
example.com. 3600 IN A 192.0.2.10این سطر، نام کامل example.com، زمان ۳۶۰۰ ثانیه، کلاس IN برای اینترنت، نوع A و مقدار IPv4 را نشان می‌دهد. در پنل معمولاً لازم نیست کل سطر را وارد کنید؛ هر جزء در فیلد خودش قرار می‌گیرد. نقطهٔ پایانی، نام کامل را در قالب فایل Zone مشخص می‌کند؛ رفتار پنل را از راهنمای همان سرویس بررسی کنید.
همهٔ نام‌ها، IPها و مقادیر این مقاله آموزشی‌اند. example.com، آدرس IPv4 نمونه و پیشوند IPv6 مستنداتی را با اطلاعات واقعی پروژه جایگزین کنید. این مثال‌ها تنظیم آمادهٔ انتشار برای دامنه یا ایمیل شما نیستند.
انواع رکورد DNS در یک نگاه
| نوع رکورد | جنس مقدار | کاربرد معمول |
|---|---|---|
| A | آدرس IPv4 | معرفی آدرس یک میزبان |
| AAAA | آدرس IPv6 | معرفی آدرس نسخهٔ شش یک میزبان |
| CNAME | نام میزبان دیگر | تعریف نام مستعار |
| MX | اولویت و نام سرور ایمیل | معرفی مقصد دریافت ایمیل دامنه |
| TXT | متن با قالب موردنیاز سرویس | تأیید مالکیت و اطلاعاتی مانند سیاست ایمیل |
این پنج نوع، همهٔ رکوردهای DNS نیستند. برای مثال، NS به مرجع پاسخ‌گویی مربوط است و SOA اطلاعات مدیریتی Zone را نگه می‌دارد. در ادامه بر رکوردهایی تمرکز می‌کنیم که هنگام اتصال سایت و سرویس‌های دامنه بیشتر با آن‌ها روبه‌رو می‌شوید.
رکورد A و AAAA؛ معرفی آدرس یک نام
رکورد A یک نام را به آدرس IPv4 مرتبط می‌کند. نمونهٔ زیر، آدرس نام اصلی دامنه را مشخص می‌کند:
example.com. 3600 IN A 192.0.2.10مقدار A فقط آدرس IPv4 است؛ شمارهٔ پورت، https و مسیرهایی مانند /shop/ در آن قرار نمی‌گیرند. یک نام می‌تواند چند رکورد A داشته باشد، اما این کار به‌تنهایی بررسی سلامت سرورها یا جابه‌جایی تضمین‌شده در زمان خرابی را فراهم نمی‌کند. کاربرد و ساختار آن را در راهنمای رکورد A بخوانید.
رکورد AAAA همین نقش را برای IPv6 دارد؛ عدد چهار در نام آن به معنای چهار IP یا چهار برابر شدن سرعت نیست. نمونهٔ زیر فقط آدرس نسخهٔ شش را معرفی می‌کند:
example.com. 3600 IN AAAA 2001:db8::10یک نام می‌تواند هم A و هم AAAA داشته باشد. تعریف AAAA، مسیر IPv6 را روی سرور یا شبکه راه‌اندازی نمی‌کند؛ مقصد باید واقعاً از آن مسیر پاسخ بدهد. بنابراین هنگام جابه‌جایی سایت، رکورد نسخهٔ شش را هم بررسی کنید تا بخشی از کاربران به آدرس قدیمی نرسند. تعریف استاندارد AAAA را در سند پشتیبانی DNS از IPv6 بخوانید.
محصولات ابر آراد را ببینید و مشخصات هر سرویس را مقایسه کنید.
رکورد CNAME؛ ارجاع یک نام به نام دیگر
CNAME نام مستعار را به نام دیگری مرتبط می‌کند. در این مثال، Resolver برای یافتن آدرس www.example.com، اطلاعات نام example.com را بررسی می‌کند:
www.example.com. 3600 IN CNAME example.com.مزیت این روش در چنین سناریویی این است که برای تغییر آدرس مقصد، لازم نیست همان IP را جداگانه در رکورد www هم ویرایش کنید. البته این ارتباط فقط در DNS است؛ وب‌سرور و گواهی HTTPS باید نام www را نیز بشناسند. CNAME تغییر مسیر HTTP نیست و نشانی صفحه را در مرورگر عوض نمی‌کند. راهنمای CNAME این تفاوت را توضیح می‌دهد.
مقدار CNAME باید نام باشد، نه IP یا URL کامل. برای همان نامی که CNAME دارد، رکوردهای معمول دیگری مانند A، MX یا TXT تعریف نکنید. این محدودیت مربوط به همان نام است؛ داشتن CNAME برای www با وجود رکورد A یا MX روی example.com تعارضی ندارد. همچنین مقصد نباید به خود نام یا به زنجیره‌ای حلقه‌ای برگردد.
در ریشهٔ Zone، رکوردهای ضروری مانند SOA و NS وجود دارند؛ بنابراین CNAME استاندارد برای آن محل مناسب نیست. بعضی ارائه‌دهندگان با قابلیت‌هایی مانند ALIAS یا CNAME flattening، ارجاع نام در ریشه را با سازوکار دیگری پیاده می‌کنند. این قابلیت را نباید ویژگی همگانی DNS دانست؛ برای نمونه، مستندات flattening کلودفلر توضیح می‌دهد که پاسخ نهایی می‌تواند IP باشد، نه رکورد CNAME معمولی.
رکورد MX؛ مشخص کردن مقصد دریافت ایمیل
MX به سامانه‌های ارسال ایمیل می‌گوید پیام مربوط به یک دامنه را به کدام سرور ایمیل تحویل دهند. مقدار آن از اولویت و نام میزبان تشکیل می‌شود:
example.com. 3600 IN MX 10 mail.example.com.
mail.example.com. 3600 IN A 192.0.2.20سطر اول، mail.example.com را برای دریافت ایمیل دامنه معرفی می‌کند؛ سطر دوم آدرس IPv4 همان میزبان را مشخص می‌کند. در پروژهٔ واقعی، اگر از سرویس ایمیل بیرونی استفاده می‌کنید، نام و اولویت‌های اعلام‌شدهٔ همان سرویس را وارد کنید؛ لازم نیست نام مقصد زیر دامنهٔ خودتان باشد.
وقتی چند MX دارید، عدد کمتر ترجیح بالاتری دارد؛ برای مثال، اولویت ۱۰ بر ۲۰ مقدم است. عدد اولویت، شمارهٔ پورت نیست. مقصد MX باید نامی باشد که رکورد آدرس A یا AAAA دارد و نباید خودش CNAME باشد. این الزام را بخش ۱۰٫۳ استاندارد DNS تصریح می‌کند.
ساخت MX، صندوق ایمیل یا سرویس SMTP ایجاد نمی‌کند و مجوز ارسال ایمیل از طرف دامنه هم به‌تنهایی از آن به دست نمی‌آید. در نتیجه، باز شدن سایت یا درست بودن رکورد A آن، برای تأیید کارکرد ایمیل کافی نیست. پیش از تغییر MX، سرویس مقصد و حساب‌های موردنیاز را آماده کنید و رکوردهای قبلی را بدون شناخت وابستگی‌ها حذف نکنید.
رکورد TXT؛ داده‌ای که سرویس دیگری آن را می‌خواند
TXT متن را به یک نام مرتبط می‌کند. یک سرویس می‌تواند از شما بخواهد برای تأیید مدیریت دامنه، متنی مشخص را در نام مشخصی منتشر کنید. این نمونه فقط جنس داده را نشان می‌دهد:
example.com. 3600 IN TXT "verification=sample-token"رشتهٔ بالا هیچ سرویسی را تأیید نمی‌کند؛ در کار واقعی باید مقدار دقیق ارائه‌شده توسط سرویس، روی همان نام خواسته‌شده ثبت شود. گیومه در نمونه، قالب فایل Zone است؛ بعضی پنل‌ها آن را خودشان اضافه می‌کنند. متن ذخیره‌شده را پس از ثبت بررسی کنید تا فاصله یا علامت اضافه وارد مقدار نشده باشد.
از TXT برای انتشار داده‌های SPF، DKIM و DMARC هم استفاده می‌شود؛ اما هرکدام قالب و نام محل انتشار خودش را دارد. خود رکورد TXT جلوی جعل ایمیل را نمی‌گیرد؛ سامانهٔ دریافت‌کننده باید داده را با قواعد همان سازوکار تفسیر کند. این کاربردها در راهنمای TXT معرفی شده‌اند.
چند TXT با کاربردهای متفاوت می‌توانند روی یک نام وجود داشته باشند؛ بااین‌حال، برای یک نام بیش از یک سیاست SPF منتشر نکنید. اگر چند فرستندهٔ ایمیل دارید، سیاست را طبق راهنمای آن سرویس‌ها یکپارچه کنید. استاندارد SPF انتشار چند سیاست مستقل روی همان نام را مجاز نمی‌داند. پس «یک SPF» با «فقط یک TXT» یکسان نیست.
رکورد ثبت‌شده را با نام و نوع درست بررسی کنید
ابتدا مطمئن شوید رکوردها را در DNS مرجع فعال دامنه ویرایش کرده‌اید. سپس دقیقاً همان نام و همان نوع را بپرسید. دستورهای زیر با ابزار نصب‌شدهٔ dig در لینوکس یا مک اجرا می‌شوند؛ نام‌ها را جایگزین کنید:
dig example.com A +noall +answer
dig example.com AAAA +noall +answer
dig www.example.com CNAME +noall +answer
dig example.com MX +noall +answer
dig example.com TXT +noall +answerدر پاسخ A و AAAA آدرس، در CNAME نام مقصد، در MX اولویت و نام سرور و در TXT متن را بررسی کنید. برای MX، آدرس نام مقصد را هم جدا بپرسید. راهنمای رسمی dig، نحو پرس‌وجوی نوع مشخص و انتخاب سرور را توضیح می‌دهد.
در ویندوز می‌توانید همین نوع پرسش‌ها را با nslookup انجام دهید؛ مثلاً برای MX:
nslookup -type=MX example.comخالی بودن بخش پاسخ به‌تنهایی ثابت نمی‌کند دامنه وجود ندارد؛ ممکن است آن نام، رکوردی از نوع درخواستی نداشته باشد. وضعیت پاسخ و نام پرسیده‌شده را هم ببینید. اگر مرجع پاسخ تازه را برمی‌گرداند ولی Resolver مقدار قبلی را نشان می‌دهد، کش را بررسی کنید؛ تغییر مجدد و پی‌درپی رکورد معمولاً راه تشخیص این تفاوت نیست.
پیش از ذخیرهٔ تغییر، نام، نوع، مقدار و وابستگی آن به سایر رکوردها را یک بار با اطلاعات سرویس مقصد تطبیق دهید. سپس کارکرد واقعی وب یا ایمیل را آزمایش کنید؛ پاسخ درست DNS به‌تنهایی آماده بودن برنامه، گواهی HTTPS یا صندوق ایمیل را تأیید نمی‌کند.
یک دامنه می‌تواند مقصد وب و ایمیل متفاوتی داشته باشد
در مثال‌های بالا، example.com برای وب به 192.0.2.10 اشاره می‌کند، www از طریق CNAME به نام اصلی وابسته است و ایمیل از طریق MX به mail.example.com با آدرس 192.0.2.20 می‌رسد. TXT نیز دادهٔ تأیید را منتشر می‌کند؛ مقصد انتقال صفحه یا پیام نیست.
این تفکیک در تغییر زیرساخت مهم است: با ویرایش A دامنه، آدرس وب تغییر می‌کند، اما MX و آدرس مستقل میزبان ایمیل خودبه‌خود عوض نمی‌شوند. اگر نام مقصد MX به همان نامی وابسته باشد که آدرسش را تغییر می‌دهید، وضعیت متفاوت است. پیش از ویرایش، وابستگی میان نام‌ها را بخوانید؛ فقط به ظاهر هر سطر نگاه نکنید.
برای بررسی مسیر مدیریت رکوردهای دامنه، صفحهٔ DNS ابری ابر آراد را ببینید. اگر میان تغییر آدرس وب، مقصد ایمیل یا دادهٔ تأیید سرویس تردید دارید، نام و نوع رکورد و مقدار اعلام‌شدهٔ سرویس مقصد را آماده کنید و از مشاورهٔ ابر آراد کمک بگیرید.
از صفحه تماس ابر آراد، مسیر ارتباط با تیم را انتخاب کنید.
دیدگاه‌ها و پرسش‌های شما
تجربه یا پرسش خود را درباره موضوع مقاله با ما در میان بگذارید.
هنوز دیدگاهی ثبت نشده است؛ شما گفت‌وگو را شروع کنید.