انواع رکورد DNS: مرجع کامل نحو، مثال و محدودیت‌ها

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

ساختار پایه‌ای که همه انواع رکورد DNS روی آن سوارند

هر خط در زون فایل چهار بخش دارد: نام، TTL، کلاس و نوع، سپس مقدار. TTL و کلاس اختیاری‌اند و اگر ننویسید، مقدار پیش‌فرض زون اعمال می‌شود. کلاس در ۹۹ درصد موارد IN است و عملاً همیشه حذف می‌شود.

www    3600    IN    A    185.10.20.30
^      ^       ^     ^    ^
نام    TTL    کلاس  نوع  مقدار

نکته‌ای که خیلی‌ها را زمین می‌زند: در زون فایل، نامی که به نقطه ختم نشود، به انتهای زون چسبانده می‌شود. یعنی mail می‌شود mail.example.com. ولی mail.example.com. با نقطه پایانی، مطلق است. اگر در مقدار رکورد MX یا CNAME نقطه پایانی را جا بیندازید، سرور شما را به دامنه‌ای کاملاً متفاوت ارجاع می‌دهد و هیچ خطایی هم نمی‌گیرید.

رکوردهای آدرس: A، AAAA و محدودیت واقعی‌شان

A و AAAA

رکورد A یک آدرس IPv4 و AAAA یک آدرس IPv6 را نگاشت می‌کند. هر دو می‌توانند چند مقدار داشته باشند و DNS پاسخ را به ترتیب تصادفی برمی‌گرداند؛ این ساده‌ترین شکل load balancing است، ولی نه health check دارد و نه failover.

example.com.     300   IN   A      185.10.20.30
example.com.     300   IN   A      185.10.20.31
example.com.     300   IN   AAAA   2a01:4f8:c17:1234::1

عدد ۳۰۰ ثانیه اینجا معنادار است. اگر رکورد A را برای مهاجرت سرور تغییر می‌دهید، TTL را حداقل ۲۴ ساعت قبل از تغییر به ۳۰۰ یا کمتر برسانید، وگرنه تا پایان عمر TTL قبلی، بخشی از کاربران به سرور قدیمی می‌روند. جزئیات این رفتار را در راهنمای انتشار DNS و کش TTL نوشته‌ایم.

رکورد CNAME و قاعده‌ای که نقضش می‌کنند

CNAME یک نام را به نام دیگر alias می‌کند، نه به IP. قاعده سخت‌گیرانه‌اش این است: در یک نام، CNAME نمی‌تواند در کنار هیچ رکورد دیگری وجود داشته باشد. نه MX، نه TXT، نه A.

shop.example.com.   3600   IN   CNAME   example.myshopify.com.

این‌جا اشتباه می‌کنند: رکورد CNAME را روی ریشه دامنه (example.com.) می‌گذارند و بعد می‌بینند ایمیل کار نمی‌کند یا رکورد TXT تأیید دامنه ناپدید شده. بعضی ارائه‌دهنده‌های DNS این کار را با CNAME flattening پنهان می‌کنند و مشکل تا روزی که یک سرویس ثالث به رکورد دیگری روی همان نام نیاز پیدا کند، دیده نمی‌شود. اگر ریشه دامنه را باید به سرویس بیرونی وصل کنید، از رکورد ALIAS یا ANAME استفاده کنید، نه CNAME خام.

رکوردهای ایمیل: MX، SPF، DKIM و DMARC

MX

رکورد MX دو بخش دارد: عدد اولویت و نام سرور. عدد کمتر یعنی اولویت بالاتر. اگر دو سرور با اولویت یکسان بگذارید، ترتیب تصادفی می‌شود و این تقریباً همیشه اشتباه پیکربندی است.

example.com.   3600   IN   MX   10   mail1.example.com.
example.com.   3600   IN   MX   20   mail2.example.com.

مقدار MX باید نام باشد، نه IP. نوشتن آدرس IP در ستون مقدار، خطای رایجی است که بعضی پنل‌ها بی‌سروصدا قبول می‌کنند و بعضی دیگر رد.

SPF، DKIM و DMARC

این سه، رکورد TXT هستند با نام‌های مشخص. SPF روی ریشه می‌نشیند و فقط یک رکورد SPF مجاز است؛ دو رکورد TXT با v=spf1 باعث permerror می‌شود و نتیجه‌اش fail شدن همه ایمیل‌هاست.

example.com.                3600  IN  TXT  "v=spf1 include:_spf.google.com ~all"
sel1._domainkey.example.com. 3600 IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCS..."
_dmarc.example.com.         3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

سقف ۱۰ بار lookup در SPF یک محدودیت واقعی است، نه توصیه. هر include و a و mx یک lookup مصرف می‌کند و عبور از ۱۰ باعث permerror می‌شود. اگر SPF شما به ۸ رسیده، جای اضافه کردن include نیست؛ باید بازنویسی شود.

رکوردهای سرویس و مسیریابی: SRV، CAA، TXT و NS

SRV

SRV چهار مقدار دارد: priority، weight، port و target. برای سرویس‌هایی مثل SIP، XMPP و Minecraft استفاده می‌شود.

_sip._tcp.example.com.   3600   IN   SRV   10 60 5060 sipserver.example.com.

نام رکورد SRV همیشه با زیرخط شروع می‌شود: _service._proto.name. اگر زیرخط را حذف کنید، رکورد معتبر است ولی هیچ‌کس آن را query نمی‌کند.

CAA

CAA تعیین می‌کند کدام CA مجاز به صدور گواهی SSL برای دامنه شماست. اگر CAA بگذارید و CA اشتباهی را مجاز کنید، تمدید خودکار گواهی شکست می‌خورد و سایت با خطای گواهی منقضی بالا می‌آید.

example.com.   3600   IN   CAA   0 issue "letsencrypt.org"
example.com.   3600   IN   CAA   0 iodef "mailto:security@example.com"

TXT و NS

TXT سقف طول دارد: هر رشته حداکثر ۲۵۵ کاراکتر و کل رکورد تا حدود ۴۰۹۶ بایت. برای مقادیر بلند مثل کلید DKIM، رشته را در چند بخش داخل گیومه بشکنید؛ نرم‌افزار DNS خودش به هم می‌چسباند.

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

مقایسه سریع انواع رکورد DNS

رکورد PTR را جدا برجسته می‌کنم چون بیشترین سوءتفاهم را دارد. PTR را نمی‌توانید در پنل DNS دامنه‌تان بسازید؛ باید ارائه‌دهنده IP آن را تنظیم کند. اگر سرور ایمیل دارید و PTR با نام هلیوی شما هم‌خوان نیست، Gmail ایمیل را رد می‌کند و پیام خطا هم صریح نیست.

ترتیب بررسی وقتی چیزی کار نمی‌کند

1. با dig +trace example.com ببینید پاسخ از کدام سطح می‌آید.
2. با dig @1.1.1.1 example.com A +short پاسخ ریزالور عمومی را با پاسخ authoritative مقایسه کنید.
3. اگر تفاوت داشتند، TTL تمام نشده؛ صبر کنید، نه اینکه رکورد را دوباره ذخیره کنید.
4. برای ایمیل، dig example.com TXT +short را بزنید و بشمارید چند رکورد v=spf1 برگشت.

ترتیب کامل بررسی و نشانه‌های هر مرحله در راهنمای عملی عیب‌یابی DNS آمده. اگر می‌خواهید از بیرون ببینید ریزالورها چه می‌بینند، از ابزار بررسی رکوردهای DNS استفاده کنید؛ سریع‌تر از پاک کردن کش مرورگر است.

انتخاب TTL: تصمیمی که بعداً پشیمانی می‌سازد

پیش‌فرض ۳۶۰۰ ثانیه برای رکوردهای ثابت درست است. برای رکوردهایی که ممکن است در مهاجرت یا failover تغییر کنند، ۳۰۰ ثانیه منطقی‌تر است. ولی TTL کوتاه هزینه دارد: بار query روی نیم‌سرور شما چند برابر می‌شود و اگر DNS شما روی زیرساخت ضعیفی باشد، خودش منبع قطعی می‌شود. من برای دامنه‌های پرترافیک، TTL ۳۰۰ را فقط روی رکوردهای A و CNAME می‌گذارم و بقیه را روی ۳۶۰۰ نگه می‌دارم.

اگر سرور مقصدتان یک VPS است و می‌خواهید رکورد A تا گواهی SSL را یک‌جا راه بیندازید، ترتیب کار در راهنمای اتصال دامنه به سرور مجازی قدم‌به‌قدم آمده. برای زیردامنه‌های پویا هم رکورد wildcard و مدیریت زیردامنه‌ها نکته‌ای دارد که جلوی ساختن صدها رکورد دستی را می‌گیرد.

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

پرسش‌های پرتکرار

آیا می‌توان روی ریشه دامنه رکورد CNAME گذاشت؟

طبق استاندارد، نه. CNAME روی ریشه با رکوردهای NS و SOA تضاد دارد. بعضی ارائه‌دهنده‌ها این را با CNAME flattening شبیه‌سازی می‌کنند و در ظاهر کار می‌کند، ولی اگر بعداً بخواهید رکورد MX یا TXT روی همان نام بگذارید، به مشکل می‌خورید. راه درست، رکورد ALIAS یا ANAME است.

چرا بعد از تغییر رکورد، هنوز IP قدیمی را می‌بینم؟

چون TTL رکورد قبلی تمام نشده و ریزالورها پاسخ کش‌شده را برمی‌گردانند. با dig @8.8.8.8 example.com A +short پاسخ ریزالور را ببینید و با dig @ns1.example.com example.com A +short پاسخ authoritative مقایسه کنید. تفاوت یعنی کش، نه خطای پیکربندی.

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

فقط یکی. دو رکورد TXT با v=spf1 باعث permerror می‌شود و نتیجه‌اش fail شدن اعتبارسنجی است. اگر به سرویس جدیدی نیاز دارید، include را به همان رکورد موجود اضافه کنید و حواستان به سقف ۱۰ lookup باشد.

رکورد PTR را از کجا تنظیم کنم؟

از پنل DNS دامنه‌تان نمی‌توانید. PTR در زون in-addr.arpa قرار می‌گیرد که در اختیار صاحب بلوک IP است. باید از ارائه‌دهنده سرور یا IP بخواهید آن را روی نام هلیوی شما تنظیم کند. برای سرورهای ایمیل، این کار اختیاری نیست.

قبل از هر تغییر، یک بار dig +short بگیرید و خروجی را ذخیره کنید. وقتی چیزی خراب شد، همان یک خط، تفاوت بین پنج دقیقه و پنج ساعت عیب‌یابی است.