DNS دفترچه‌تلفن اینترنت است: شما نام دامنه را می‌دانید (example.com) و DNS می‌گوید آن نام به کدام سرور اشاره می‌کند، ایمیل‌هایش را کدام سرور تحویل می‌گیرد و چه اطلاعات دیگری درباره‌اش ثبت شده. هر کدام از این اطلاعات یک رکورد است و هر رکورد یک نوع دارد. رکورد A نام را به آدرس IPv4 می‌رساند، AAAA به IPv6، CNAME یک نام را مستعارِ نام دیگر می‌کند، MX سرور ایمیل دامنه را معرفی می‌کند و TXT متن آزادی است که بیشتر برای تأیید مالکیت و امنیت ایمیل (SPF، DKIM، DMARC) به کار می‌رود.

اگر فقط دنبال همین بودید، جدول پایین خلاصه‌ی کامل است. در ادامه سراغ جزئیاتی می‌رویم که معمولاً دردسر درست می‌کنند: TTL و «انتشار» تغییرات، این‌که چرا CNAME روی خود دامنه‌ی اصلی مجاز نیست، و این‌که چطور با dig و nslookup ببینیم دنیا واقعاً چه چیزی از دامنه‌ی ما می‌بیند.

DNS دقیقاً چه کار می‌کند؟

وقتی در مرورگر example.com را باز می‌کنید، سیستم‌عامل از یک resolver (معمولاً سرور DNS اینترنت‌دهنده یا شبکه‌ی محلی) می‌پرسد: «آدرس example.com چیست؟». اگر resolver جواب را از قبل در حافظه داشته باشد همان را برمی‌گرداند. اگر نه، از سرورهای ریشه شروع می‌کند، به سرورهای .com می‌رسد و در نهایت از سرورهای نام معتبر (authoritative) همان دامنه جواب را می‌گیرد؛ یعنی همان سرورهایی که شما رکوردها را در پنلشان وارد کرده‌اید.

دو نکته از همین‌جا مهم است:

  • رکوردها را فقط در پنل سرویس‌دهنده‌ای ویرایش کنید که سرورهای نام دامنه به آن اشاره می‌کند. اگر NSها روی سرویس A باشد و شما در پنل سرویس B رکورد بسازید، هیچ اتفاقی نمی‌افتد.
  • resolverها جواب‌ها را برای مدتی نگه می‌دارند. این مدت همان TTL است که پایین‌تر سراغش می‌رویم.

جدول انواع رکورد DNS

در مثال‌های زیر از دامنه‌ی رزروشده‌ی example.com و آدرس‌های مخصوص مستندات (203.0.113.x و 2001:db8::) استفاده شده است.

نوع کارش مثال
A نام را به آدرس IPv4 می‌رساند example.com. 3600 IN A 203.0.113.10
AAAA نام را به آدرس IPv6 می‌رساند example.com. 3600 IN AAAA 2001:db8::10
CNAME نام را مستعارِ نام دیگری می‌کند www.example.com. 3600 IN CNAME example.com.
MX سرور دریافت ایمیل دامنه را معرفی می‌کند example.com. 3600 IN MX 10 mail.example.com.
TXT متن آزاد؛ تأیید مالکیت، SPF، DKIM، DMARC example.com. 3600 IN TXT "v=spf1 mx -all"
NS سرورهای نام معتبر دامنه را مشخص می‌کند example.com. 86400 IN NS ns1.example.net.
CAA می‌گوید کدام مرجع صدور گواهی اجازه‌ی صدور SSL دارد example.com. 3600 IN CAA 0 issue "letsencrypt.org"

هر خط به ترتیب این‌هاست: نام، TTL به ثانیه، کلاس (تقریباً همیشه IN)، نوع رکورد و مقدار. در پنل‌های گرافیکی معمولاً فقط نام، نوع، مقدار و TTL را می‌بینید و بقیه را خود پنل می‌سازد. نقطه‌ی انتهای نام‌ها (example.com.) یعنی «نام کامل است»؛ بیشتر پنل‌ها این را هم خودشان اضافه می‌کنند.

A و AAAA

ساده‌ترین و پرکاربردترین رکوردها. اگر سرور شما IPv6 دارد، کنار A یک AAAA هم بگذارید؛ اگر ندارد، AAAA نسازید. یک AAAA غلط از A نداشتن بدتر است، چون کاربرانی که IPv6 دارند اول همان را امتحان می‌کنند و به جایی نمی‌رسند.

رکورد CNAME در DNS چیست؟

CNAME می‌گوید «این نام، اسم دیگرِ فلان نام است؛ برای هر جوابی برو سراغ آن». مثلاً www.example.com را CNAME به example.com می‌کنیم تا اگر روزی IP عوض شد فقط یک رکورد A را تغییر دهیم. سرویس‌های بیرونی هم معمولاً از شما می‌خواهند یک زیردامنه را به نامی در دامنه‌ی خودشان CNAME کنید، مثلاً shop.example.com به stores.provider.example.

قاعده‌ی مهم CNAME این است: نامی که CNAME دارد نمی‌تواند هیچ رکورد دیگری داشته باشد. نه MX، نه TXT، نه A. چون CNAME یعنی «همه‌چیزِ این نام را از جای دیگر بخوان» و رکورد دیگر کنارش تناقض است.

رکورد MX

MX می‌گوید ایمیل‌های @example.com به کدام سرور تحویل داده شود. عدد قبل از نام سرور اولویت است و عدد کوچک‌تر یعنی اولویت بالاتر:

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

فرستنده اول سراغ mail1 می‌رود و اگر در دسترس نبود mail2 را امتحان می‌کند. دو نکته که زیاد اشتباه می‌شود: مقدار MX باید نام باشد نه IP، و آن نام نباید CNAME باشد؛ باید مستقیماً رکورد A یا AAAA داشته باشد.

NS و CAA

رکوردهای NS را معمولاً سرویس‌دهنده‌ی DNS خودش می‌سازد و شما فقط در پنل ثبت دامنه همان‌ها را وارد می‌کنید. CAA کمتر شناخته شده ولی ارزان و مفید است: اگر فقط از Let's Encrypt گواهی می‌گیرید، با یک رکورد CAA جلوی صدور گواهی برای دامنه‌تان توسط مراجع دیگر را می‌گیرید. اگر CAA دارید و بعداً مرجع دیگری اضافه کردید، یادتان باشد رکوردش را هم اضافه کنید، وگرنه صدور گواهی شکست می‌خورد. جزئیات گرفتن گواهی در SSL رایگان با Let's Encrypt آمده است.

TTL و «انتشار» تغییرات

TTL عددی به ثانیه است که می‌گوید resolverها جواب را چقدر نگه دارند. TTL برابر 3600 یعنی یک ساعت. چیزی که به آن «انتشار DNS» می‌گویند در واقع پخش‌شدن چیزی نیست؛ resolverهای مختلف جواب قبلی را تا پایان TTL خودش نگه می‌دارند و بعد جواب تازه را می‌پرسند. به همین دلیل بعد از تغییر یک رکورد، بعضی کاربران زودتر و بعضی دیرتر نتیجه را می‌بینند.

روش درست جابه‌جایی سرور:

  1. یکی دو روز قبل، TTL رکوردی را که می‌خواهید عوض کنید پایین بیاورید (مثلاً 300 ثانیه). این کار باید دست‌کم به اندازه‌ی TTL قبلی زودتر انجام شود.
  2. روز جابه‌جایی، مقدار رکورد را عوض کنید. حالا ظرف چند دقیقه بیشتر کاربران به سرور جدید می‌رسند.
  3. چند روز سرور قدیمی را روشن نگه دارید؛ همیشه resolverی هست که به TTL احترام نمی‌گذارد.
  4. وقتی همه‌چیز پایدار شد، TTL را به مقدار معمول (مثلاً 3600) برگردانید.

یک استثنا: تغییر سرورهای نام (NS) در سطح رجیستری انجام می‌شود و TTL آن معمولاً طولانی است (اغلب یک یا دو روز)، پس برای آن صبر بیشتری لازم است.

چرا CNAME روی دامنه‌ی اصلی نمی‌نشیند؟

دامنه‌ی اصلی، یعنی خود example.com بدون هیچ پیشوندی، را apex یا ریشه‌ی zone می‌گویند. این نام همیشه دست‌کم دو نوع رکورد دارد: SOA و NS. قاعده‌ای که بالاتر گفتیم (نامی که CNAME دارد نباید رکورد دیگری داشته باشد) این‌جا مستقیماً نقض می‌شود، پس استاندارد DNS اجازه‌ی CNAME روی apex را نمی‌دهد. تازه اگر هم می‌شد، MX و TXT دامنه از کار می‌افتاد.

راه‌حل‌ها:

  • رکورد A مستقیم روی apex و CNAME فقط روی www و زیردامنه‌ها. ساده‌ترین و استانداردترین راه.
  • CNAME flattening یا ALIAS/ANAME: بعضی سرویس‌دهنده‌های DNS اجازه می‌دهند در پنل چیزی شبیه CNAME روی apex بگذارید، اما در جواب، خودشان نام مقصد را resolve می‌کنند و رکورد A برمی‌گردانند. این قابلیتِ همان سرویس‌دهنده است، نه بخشی از استاندارد، و نامش در هر پنل فرق می‌کند.

SPF، DKIM و DMARC: سه رکورد TXT برای ایمیل

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

  • SPF فهرست سرورهایی است که اجازه دارند از طرف دامنه‌ی شما ایمیل بفرستند. روی خود دامنه قرار می‌گیرد و هر دامنه فقط یک رکورد SPF باید داشته باشد؛ اگر چند سرویس دارید، همه را در یک رکورد بیاورید.
  • DKIM کلید عمومی‌ای است که امضای دیجیتال نامه‌ها با آن بررسی می‌شود. روی نامی به شکل selector._domainkey.example.com قرار می‌گیرد و مقدارش را سرویس ایمیل به شما می‌دهد.
  • DMARC سیاست شما را اعلام می‌کند: اگر نامه‌ای SPF و DKIM را رد کرد، گیرنده با آن چه کند و گزارش‌ها را کجا بفرستد. روی _dmarc.example.com قرار می‌گیرد.
text
example.com.                    IN TXT "v=spf1 mx include:_spf.mailprovider.example -all"
mail2026._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
_dmarc.example.com.             IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

برای DMARC با p=none شروع کنید، چند هفته گزارش‌ها را بخوانید و وقتی مطمئن شدید همه‌ی فرستنده‌های مجاز SPF یا DKIM را پاس می‌کنند، به quarantine و بعد reject بروید.

بررسی رکوردها با dig و nslookup

پنل DNS می‌گوید شما چه وارد کرده‌اید؛ dig می‌گوید دنیا چه می‌بیند. روی اوبونتو dig در بسته‌ی bind9-dnsutils است (sudo apt install bind9-dnsutils)؛ nslookup هم در ویندوز و هم در لینوکس هست.

bash
# جواب کوتاه: فقط مقدار
dig example.com A +short
dig www.example.com CNAME +short
dig example.com MX +short
dig example.com TXT +short
dig _dmarc.example.com TXT +short

# جواب کامل، همراه با TTL باقی‌مانده در ستون دوم
dig example.com A

اگر می‌خواهید بدون دخالت کش resolver ببینید سرور نام معتبر چه جوابی می‌دهد، اول NSها را پیدا کنید و بعد مستقیماً از خودشان بپرسید:

bash
dig example.com NS +short
# فرض کنیم جواب ns1.example.net بود
dig @ns1.example.net example.com A +short

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

برای دیدن کل مسیر پرس‌وجو از ریشه تا سرور معتبر:

bash
dig example.com +trace

و معادل‌های nslookup:

bash
nslookup example.com
nslookup -type=mx example.com
nslookup -type=txt example.com

اشتباه‌های رایج

  • رکورد ساختن در پنلی که NSهای دامنه به آن اشاره نمی‌کند.
  • گذاشتن CNAME کنار رکوردهای دیگر، یا روی apex.
  • MX که به IP یا به یک CNAME اشاره می‌کند.
  • دو رکورد SPF جدا برای یک دامنه؛ در این حالت SPF عملاً نامعتبر می‌شود.
  • AAAA قدیمی که بعد از عوض‌کردن سرور فراموش شده.
  • پایین آوردن TTL درست در لحظه‌ی جابه‌جایی، به جای یک روز قبل.

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

جمع‌بندی

DNS با چند نوع رکورد محدود کار می‌کند: A و AAAA برای آدرس، CNAME برای نام مستعار، MX برای ایمیل، TXT برای تأیید و امنیت ایمیل، NS برای معرفی سرورهای نام و CAA برای محدودکردن صدور گواهی. بیشتر دردسرها از سه جا می‌آید: ویرایش در پنل اشتباه، قاعده‌ی تنها بودن CNAME و بی‌توجهی به TTL. قبل از هر تغییر TTL را پایین بیاورید، بعد از آن با dig از سرور معتبر جواب بگیرید و اگر ایمیل می‌فرستید، SPF و DKIM و DMARC را از روز اول درست بچینید.