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

DNS چیست؟ سیستم نام دامنه (Domain Name System) دفترچهٔ آدرس اینترنت است: نامی مثل example.com را به آدرس IP سرور تبدیل می‌کند تا مرورگر، سرور ایمیل و هر برنامهٔ دیگری بداند به کجا وصل شود. در این راهنما مسیر این تبدیل را قدم‌به‌قدم می‌بینید، رکوردهای رایج DNS را با مثال یاد می‌گیرید و دامنه را به سرور، ایمیل و Google Search Console وصل می‌کنید.

سایتی که بعد از جابه‌جایی هنوز سرور قبلی را نشان می‌دهد، ایمیلی که به اسپم می‌رود و SSLی که صادر نمی‌شود، معمولاً به یک رکورد اشتباه برمی‌گردند. در مثال‌ها به‌جای example.com و IPهای نمونه (مثل 203.0.113.10) مقدارهای خودتان را بگذارید.

به‌طور خلاصه:

• resolver (سرور DNSی که از طرف شما می‌پرسد) پاسخ را از سرور ریشه، سرور پسوند (مثل .com یا .ir) و نیم‌سرور مرجع دامنه می‌گیرد و به مدت TTL کش می‌کند.
• رکورد NS (نیم‌سرور) تعیین می‌کند رکوردها را کجا ویرایش کنید؛ A، CNAME، MX و TXT می‌گویند هر نام به کجا برود.
• اتصال دامنه به سرور: رکورد A برای @ و www روی IP سرور، سپس بررسی با dig +short example.com.
• ایمیل سالم: MX درست، فقط یک رکورد SPF، کلید DKIM، رکورد DMARC و PTR هماهنگ.
• زمان اعمال تغییر، «۴۸ ساعت» ثابت نیست؛ به TTL رکورد قبلی بستگی دارد.

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

شبکه با IP کار می‌کند و آدم‌ها با نام. DNS پایگاه دادهٔ توزیع‌شده‌ای است که این دو را به هم وصل می‌کند: هیچ سروری همهٔ نام‌ها را ندارد و هر بخش از فضای نام را سرورهای مشخصی پاسخ می‌دهند. پرسش‌ها معمولاً با UDP روی پورت 53 فرستاده می‌شوند و پاسخ‌های بزرگ و انتقال منطقه (Zone Transfer) از TCP روی همان پورت استفاده می‌کنند.

ساختار درختی نام‌ها

نام دامنه از راست به چپ خوانده می‌شود. در www.example.com. نقطهٔ پایانی ریشه (Root) است، com پسوند یا TLD است (دامنه‌های .ir را ایرنیک مدیریت می‌کند)، example دامنه‌ای است که از ثبت‌کننده (Registrar) خریده‌اید و www زیردامنه‌ای است که خودتان در DNS می‌سازید. مجموعهٔ رکوردهای یک دامنه و زیردامنه‌هایش را «منطقه» یا Zone می‌گویند.

مسیر یک درخواست، قدم‌به‌قدم

1. مرورگر و سیستم‌عامل (Stub Resolver) اول کش خود و فایل hosts را نگاه می‌کنند.
2. بعد سؤال به resolver بازگشتی (Recursive Resolver) می‌رود، مثل DNS اپراتور یا 1.1.1.1؛ اگر پاسخ در کشش باشد، فوراً جواب می‌دهد.
3. وگرنه از یک سرور ریشه (Root Server) می‌پرسد و فقط ارجاع (Referral) می‌گیرد: «برای .com سراغ این سرورها برو».
4. سرور TLD (مثل a.gtld-servers.net یا a.nic.ir) نیم‌سرورهای example.com را معرفی می‌کند.
5. نیم‌سرور مرجع (Authoritative Server) رکورد A را برمی‌گرداند و resolver آن را به اندازهٔ TTL کش می‌کند.

سرورهای ریشه ۱۳ نام (a تا m) دارند که با روش Anycast در بیش از ۲۰۰۰ نقطه تکرار شده‌اند (root-servers.org). این مسیر را با dig +trace ببینید (خروجی آبان ۱۴۰۵، کوتاه‌شده):

$ dig +trace example.com A
.                 509504  IN  NS  a.root-servers.net.
.                 509504  IN  NS  b.root-servers.net.
...
;; Received 525 bytes from 1.1.1.1#53(1.1.1.1) in 146 ms

com.              172800  IN  NS  a.gtld-servers.net.
com.              172800  IN  NS  b.gtld-servers.net.
...
;; Received 1171 bytes from 192.5.5.241#53(f.root-servers.net) in 128 ms

example.com.      172800  IN  NS  hera.ns.cloudflare.com.
example.com.      172800  IN  NS  elliott.ns.cloudflare.com.
;; Received 506 bytes from 192.52.178.30#53(k.gtld-servers.net) in 118 ms

example.com.      300     IN  A   172.66.147.243
example.com.      300     IN  A   104.20.23.154
;; Received 179 bytes from 108.162.192.162#53(hera.ns.cloudflare.com) in 115 ms

بلوک‌ها به‌ترتیب: ریشه‌ها، ارجاع به سرورهای .com، ارجاع به نیم‌سرورهای Cloudflare و پاسخ نهایی. ستون دوم TTL به ثانیه است (۱۷۲۸۰۰ یعنی ۲ روز).

نیم‌سرور و رکورد DNS چه فرقی دارند؟

نیم‌سرور (Name Server) جایی است که منطقهٔ دامنه نگه داشته می‌شود و رکوردها محتوای آن منطقه‌اند. نیم‌سرور را در پنل ثبت‌کننده عوض می‌کنید (برای دامنه‌های .ir در پنل ایرنیک)، اما رکوردها را فقط در سرویسی می‌توانید ویرایش کنید که نیم‌سرورهای فعلی به آن تعلق دارند. پس قدم اول هر عیب‌یابی این است:

$ dig NS example.com +short
hera.ns.cloudflare.com.
elliott.ns.cloudflare.com.

اگر خروجی نیم‌سرورهای Cloudflare است، ویرایش رکورد در cPanel هاست هیچ اثری ندارد، و برعکس:

نیم‌سرورهای فعلی	رکوردها را کجا ویرایش کنید
نیم‌سرورهای هاست	Zone Editor در cPanel یا بخش DNS در DirectAdmin
نیم‌سرورهای Cloudflare	داشبورد Cloudflare، صفحهٔ DNS › Records
نیم‌سرورهای ثبت‌کننده	بخش مدیریت DNS در پنل ثبت‌کننده
نیم‌سرور روی سرور خودتان	Zone File در BIND یا پنل سرور

نیم‌سرور اختصاصی و رکورد Glue

اگر نیم‌سرور زیرمجموعهٔ خود دامنه باشد (ns1.example.com برای example.com)، resolver برای یافتن IP آن در دور باطل می‌افتد؛ برای همین IP آن به‌صورت رکورد Glue در سرور TLD هم ثبت می‌شود (در پنل ثبت‌کننده‌ها معمولاً بخش Child Name Servers). برای یک سایت معمولی، نیم‌سرورهای هاست یا یک سرویس DNS کافی است.

پیش از تغییر نیم‌سرور، رکوردها را منتقل کنید

رکوردها با تغییر نیم‌سرور خودبه‌خود منتقل نمی‌شوند و اگر MX و TXTهای ایمیل را در سرویس جدید نسازید، ایمیل دامنه قطع می‌شود. اول همهٔ رکوردها را در سرویس جدید بسازید (نتیجهٔ اسکن خودکار سرویس‌هایی مثل Cloudflare را هم با فهرست خودتان مقایسه کنید)، اگر DNSSEC فعال است طبق بخش امنیت خاموشش کنید و بعد نیم‌سرور را عوض کنید. تا منطقهٔ قدیمی پاک نشده، رکوردهایش را با dig @old-nameserver می‌توانید بخوانید.

انواع رکوردهای DNS با مثال

نوع	کاربرد	نمونهٔ مقدار
A	نام به IPv4	203.0.113.10
AAAA	نام به IPv6	2001:db8::10
CNAME	نام مستعار برای نامی دیگر	example.com.
MX	سرور دریافت ایمیل با اولویت	10 mail.example.com.
TXT	SPF، DKIM، DMARC، تأیید مالکیت	“v=spf1 mx ~all”
NS	نیم‌سرورهای منطقه	ns1.example.net.
SOA	مشخصات منطقه و شمارهٔ سریال	سریال، Refresh، Retry و…
SRV	میزبان و پورت یک سرویس	0 5 25570 mc.example.com.
CAA	CAهای مجاز برای صدور SSL	0 issue “letsencrypt.org”
PTR	IP به نام (DNS معکوس)	mail.example.com.
HTTPS	اطلاعات اتصال مثل پشتیبانی HTTP/3	1 . alpn=h2,h3

همین رکوردها در یک Zone File با قالب BIND این شکل را دارند؛ پنل‌های گرافیکی همین فیلدها (نام، نوع، مقدار، TTL) را جدا می‌گیرند:

$ORIGIN example.com.
$TTL 3600
@         IN  SOA   ns1.example.net. hostmaster.example.com. (
                    2026102801 ; serial
                    7200       ; refresh
                    3600       ; retry
                    1209600    ; expire
                    3600 )     ; negative caching TTL
@         IN  NS    ns1.example.net.
@         IN  NS    ns2.example.net.
@         IN  A     203.0.113.10
@         IN  AAAA  2001:db8::10
www       IN  CNAME example.com.
mail      IN  A     203.0.113.20
@         IN  MX    10 mail.example.com.
@         IN  TXT   "v=spf1 mx ~all"
_dmarc    IN  TXT   "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

@ یعنی خود دامنه و نامی که به نقطه ختم می‌شود نام کامل است؛ به بقیهٔ نام‌ها دامنه اضافه می‌شود، پس mail یعنی mail.example.com.

رکورد A و AAAA

A نام را به IPv4 و AAAA به IPv6 وصل می‌کند. چند رکورد A برای یک نام مجاز است (Round Robin)، اما جای Load Balancer را نمی‌گیرد، چون DNS از خاموش شدن یک سرور خبر ندارد. AAAA را فقط وقتی بسازید که سرور واقعاً روی IPv6 سرویس می‌دهد. AAAA جامانده می‌تواند کاربران IPv6 را به سرور قدیمی ببرد یا اتصال برخی برنامه‌ها را ناموفق کند و صدور گواهی Let’s Encrypt را هم مختل می‌کند، چون Let’s Encrypt اول IPv6 را امتحان می‌کند و فقط در صورت timeout سراغ IPv4 می‌رود. رکورد Wildcard (*.example.com) هم به همهٔ زیردامنه‌هایی پاسخ می‌دهد که رکورد جداگانه ندارند.

رکورد CNAME و محدودیت‌هایش

CNAME یک نام را مستعار نام دیگری می‌کند، مثلاً www را به دامنهٔ اصلی یا shop را به یک سرویس بیرونی. سه قاعده دارد:

1. نامی که CNAME دارد رکورد دیگری نمی‌تواند داشته باشد (RFC 1034)؛ پس روی خود دامنه (@) که SOA و NS دارد، CNAME مجاز نیست.
2. مقدار MX و NS نباید نامی باشد که CNAME دارد (RFC 2181).
3. هر حلقهٔ زنجیرهٔ CNAME که به منطقهٔ دیگری برود، پرس‌وجوی اضافه و یک نقطهٔ خرابی تازه است؛ زنجیره را کوتاه نگه دارید.

برای دامنهٔ اصلی، CNAME Flattening در Cloudflare یا رکورد ALIAS/ANAME سرویس DNS همین کار را با برگرداندن IP نهایی انجام می‌دهد. ALIAS در cPanel فقط روی سرورهای PowerDNS هست و مستندات cPanel آن را آزمایشی می‌داند و توصیه نمی‌کند.

رکورد MX و اولویت

MX سرور دریافت ایمیل را تعیین می‌کند. عدد اولویت کمتر یعنی آن سرور اول امتحان شود؛ عددهای بزرگ‌تر پشتیبان‌اند و عددهای برابر بار را تقسیم می‌کنند. نمونهٔ واقعی Gmail:

$ dig gmail.com MX +short
5 gmail-smtp-in.l.google.com.
10 alt1.gmail-smtp-in.l.google.com.
20 alt2.gmail-smtp-in.l.google.com.
30 alt3.gmail-smtp-in.l.google.com.
40 alt4.gmail-smtp-in.l.google.com.

مقدار MX باید نام میزبانی با رکورد A یا AAAA باشد، نه IP و نه نامی با CNAME. دامنه‌ای که ایمیل دریافت نمی‌کند می‌تواند Null MX به شکل 0 . منتشر کند (RFC 7505) تا فرستنده‌ها بی‌دلیل تلاش نکنند.

رکورد TXT: SPF، DKIM و DMARC

TXT متن آزاد است و بیشتر برای احراز هویت ایمیل و اثبات مالکیت دامنه به کار می‌رود: SPF فرستنده‌های مجاز را فهرست می‌کند، DKIM نامه را امضای دیجیتال می‌کند و DMARC به گیرنده می‌گوید با نامهٔ ردشده چه کند. یک نام می‌تواند چند TXT داشته باشد و هر رشتهٔ TXT حداکثر ۲۵۵ کاراکتر است.

رکوردهای NS و SOA

NSهای داخل منطقه باید با نیم‌سرورهای ثبت‌شده در ثبت‌کننده یکی باشند. SOA (Start of Authority) شناسنامهٔ منطقه است:

$ dig example.com SOA +short
elliott.ns.cloudflare.com. dns.cloudflare.com. 2418004112 10000 2400 604800 1800

مقادیر به‌ترتیب: نیم‌سرور اصلی، ایمیل مسئول (dns@cloudflare.com)، شمارهٔ سریال، Refresh، Retry، Expire و مدت کش پاسخ منفی. اگر BIND را خودتان اداره می‌کنید، بعد از هر تغییر سریال را بالا ببرید (مثلاً 2026102801)؛ وگرنه نیم‌سرورهای ثانویه تغییر را نمی‌گیرند.

رکورد SRV

SRV میزبان و پورت یک سرویس را اعلام می‌کند و نامش قالب _service._protocol.domain دارد. مثال آشنا، سرور ماینکرفت Java روی پورتی غیر از 25565 است؛ بازیکن فقط نام دامنه را وارد می‌کند و پورت از رکورد خوانده می‌شود:

_minecraft._tcp.example.com.  3600  IN  SRV  0 5 25570 mc.example.com.

مقدار به‌ترتیب اولویت، وزن، پورت و میزبان است و میزبان باید رکورد A داشته باشد.

رکورد CAA

CAA تعیین می‌کند کدام مراکز صدور گواهی (CA) برای دامنهٔ شما SSL صادر کنند (RFC 8659)؛ بدون آن، هر CA عمومی پس از اعتبارسنجی مالکیت می‌تواند. رکورد issue گواهی Wildcard را هم پوشش می‌دهد:

example.com.  3600  IN  CAA  0 issue "letsencrypt.org"

اگر گواهی تجاری هم دارید (مثلاً از طریق خرید SSL)، CA آن را با یک رکورد issue دیگر اضافه کنید تا تمدیدش رد نشود. روی هاست cPanel هم ببینید AutoSSL از کدام CA گواهی می‌گیرد؛ برای Sectigo رکورد 0 issue "sectigo.com" لازم است.

رکورد PTR یا DNS معکوس

PTR برعکس A، IP را به نام برمی‌گرداند و در پنل DNS دامنهٔ شما ساخته نمی‌شود؛ مالک IP، یعنی ارائه‌دهندهٔ سرور، آن را تنظیم می‌کند. برای سرور ایمیل، PTR عملاً الزامی است:

$ dig -x 8.8.8.8 +short
dns.google.

TTL و زمان اعمال تغییرات DNS

TTL (Time To Live) می‌گوید resolverها پاسخ را چند ثانیه کش کنند. «انتشار DNS» (Propagation) در واقع همین کش است: رکورد جدید همان لحظه روی نیم‌سرور مرجع فعال است، اما resolverهایی که نسخهٔ قدیمی را دارند تا پایان TTL همان را برمی‌گردانند. اگر TTL رکورد قبلی ۳۶۰۰ ثانیه بوده، در بدترین حالت حدود یک ساعت صبر لازم است.

چرا تغییر نیم‌سرور تا ۲ روز طول می‌کشد؟

عدد معروف «۴۸ ساعت» از TTL رکوردهای NS در سرور TLD می‌آید که در اختیار شما نیست: برای .com این مقدار ۱۷۲۸۰۰ ثانیه است و در بررسی ما در آبان ۱۴۰۵، سرورهای ایرنیک ارجاع دامنه‌های .ir را با TTL ۹۰۰ ثانیه برمی‌گرداندند:

$ dig example.com NS @a.gtld-servers.net +norec +noall +authority
example.com.   172800  IN  NS  hera.ns.cloudflare.com.
example.com.   172800  IN  NS  elliott.ns.cloudflare.com.

$ dig nic.ir NS @a.nic.ir +norec +noall +authority
nic.ir.        900     IN  NS  ns1.nic.ir.
nic.ir.        900     IN  NS  ns2.nic.ir.
...

منطقهٔ قبلی را تا چند روز پس از تغییر حذف نکنید، چون برخی resolverها NS را از آن هم می‌خوانند و کش می‌کنند.

کش پاسخ منفی

پاسخ NXDOMAIN («چنین نامی وجود ندارد») هم به مدت تعیین‌شده در SOA (در مثال بالا ۱۸۰۰ ثانیه) کش می‌شود. برای همین زیردامنه‌ای که پیش از ساختنش جست‌وجو کرده‌اید، گاهی تا نیم ساعت روی سیستم شما باز نمی‌شود، در حالی که از شبکهٔ دیگری کار می‌کند.

جابه‌جایی سرور بدون قطعی

وضعیت	TTL پیشنهادی
حالت عادی سایت (A، AAAA، CNAME)	۳۶۰۰ ثانیه
رکوردهای کم‌تغییر (MX، TXT)	۳۶۰۰ تا ۸۶۴۰۰ ثانیه
از یک روز پیش از جابه‌جایی	۳۰۰ ثانیه
رکورد Proxied در Cloudflare	Auto، ثابت ۳۰۰ ثانیه

این اعداد قاعدهٔ رایج‌اند، نه استاندارد. ترتیب جابه‌جایی:

1. دست‌کم به اندازهٔ TTL فعلی پیش از جابه‌جایی، TTL رکوردهای A و AAAA را ۳۰۰ ثانیه کنید.
2. سایت را روی سرور جدید آماده کنید و پیش از تغییر DNS با فایل hosts آزمایش کنید. اگر گواهی سرور جدید هنوز صادر نشده، هشدار گواهی در این آزمایش طبیعی است؛ با HTTP آزمایش کنید یا گواهی را با چالش DNS-01 بگیرید.
3. رکورد A را عوض کنید و پاسخ نیم‌سرور مرجع را بررسی کنید.
4. سرور قدیمی را یکی دو روز روشن نگه دارید و بعد TTL را به حالت عادی برگردانید.

# Linux/macOS: /etc/hosts   Windows: C:\Windows\System32\drivers\etc\hosts
203.0.113.10   example.com www.example.com
# remove this line after testing

اتصال دامنه به سرور مجازی، قدم‌به‌قدم

فرض کنید IP سرور مجازی شما 203.0.113.10 است. با dig NS example.com +short ببینید DNS کجا مدیریت می‌شود، همان‌جا این دو رکورد را بسازید و A و AAAA قدیمیِ همین نام‌ها (مثلاً IP صفحهٔ پارک ثبت‌کننده) را حذف کنید:

Type    Name    Value            TTL
A       @       203.0.113.10     3600
CNAME   www     example.com.     3600

برای www رکورد A هم درست است؛ CNAME فقط جابه‌جایی بعدی را ساده‌تر می‌کند، چون یک رکورد را تغییر می‌دهید.

در cPanel با Zone Editor

1. در cPanel، بخش Domains، روی Zone Editor بزنید (اگر نیست، هاست آن را برای حساب شما فعال نکرده است) و جلوی دامنه Manage را بزنید.
2. رکورد A با نام example.com. را Edit کنید، IP جدید را در فیلد Address (ستون Record) بنویسید و Save Record را بزنید؛ اگر رکوردی نیست، از Add Record بسازید. www در cPanel معمولاً CNAME به خود دامنه است و تغییری نمی‌خواهد.

هشدار: در بسیاری از هاست‌های cPanel، رکورد MX پیش‌فرض به خود دامنه اشاره می‌کند و mail هم یک CNAME به خود دامنه است. اگر A دامنهٔ اصلی را به سرور مجازی ببرید و ایمیل روی هاست بماند، ایمیل‌های ورودی و اتصال برنامه‌های ایمیل به mail.example.com هم به سرور مجازی می‌روند. پیش از تغییر، CNAME نام mail را حذف کنید (نامی که CNAME دارد رکورد دیگری نمی‌پذیرد)، به‌جایش یک رکورد A با نام mail و IP هاست بسازید (این IP در صفحهٔ اصلی cPanel، کادر General Information آمده است) و بعد MX را روی mail.example.com بگذارید.

در Cloudflare

1. در صفحهٔ DNS › Records روی Add record بزنید؛ Type را A، Name را @ و IPv4 address را IP سرور بگذارید و Save کنید. برای www هم یک رکورد بسازید.
2. Proxy status را آگاهانه انتخاب کنید: در حالت Proxied (ابر نارنجی) IP سرور پنهان می‌ماند ولی فقط ترافیک HTTP و HTTPS عبور می‌کند؛ برای SSH و سرویس‌های دیگر از IP یا زیردامنه‌ای با حالت DNS only استفاده کنید. MX و TXT همیشه DNS only هستند.

بررسی نتیجه

$ dig @ns1.example.net example.com A +short    # authoritative, no cache
203.0.113.10
$ dig example.com A +short                     # your resolver, may be cached
203.0.113.10

اگر نیم‌سرور مرجع IP جدید را می‌دهد ولی resolver شما هنوز IP قدیمی را، فقط منتظر پایان TTL بمانید. بعد وب‌سرور (Nginx یا Apache) را برای هر دو نام پیکربندی کنید و گواهی SSL بگیرید؛ Let’s Encrypt تا DNS درست نشده باشد اعتبارسنجی را رد می‌کند.

رکوردهای ایمیل و تأیید دامنه

ایمیل روی هاست cPanel

اگر نیم‌سرورهای دامنه روی همان هاست باشند، cPanel رکوردهای MX، SPF و DKIM را خودش می‌سازد. ابزار Email Deliverability در بخش Email وضعیت DKIM، SPF، DMARC و PTR را نشان می‌دهد؛ اگر DNS روی همین سرور است، دکمهٔ Repair رکوردها را اصلاح می‌کند، وگرنه با Manage مقدارهای پیشنهادی را ببینید و در سرویس DNS وارد کنید. برای خطاهای ارسال، راهنمای رفع مشکلات ارسال ایمیل در cPanel را هم ببینید.

سرویس ایمیل بیرونی

MX و SPF را دقیقاً از راهنمای همان سرویس بردارید؛ مثلاً Google Workspace اکنون یک MX با مقدار smtp.google.com و اولویت ۱ پیشنهاد می‌کند و SPF آن include:_spf.google.com است. اگر دامنه روی هاست cPanel هم تعریف شده، در Email Routing گزینهٔ Remote Mail Exchanger را انتخاب کنید تا هاست ایمیل‌های این دامنه را محلی تحویل نگیرد. برخی سرویس‌های ایمیل و DNS خارجی هم به‌دلیل تحریم، کاربران ایران را نمی‌پذیرند یا حساب را محدود می‌کنند.

SPF: فقط یک رکورد

دو رکورد SPF روی یک نام طبق RFC 7208 خطای دائمی (permerror) می‌دهد، یعنی عملاً SPF ندارید. معمولاً یکی را cPanel ساخته و دیگری را سرویس خبرنامه خواسته است؛ ادغامشان کنید:

; wrong: two SPF records on the same name
example.com.  TXT  "v=spf1 a mx ~all"
example.com.  TXT  "v=spf1 include:_spf.google.com ~all"

; right: one merged record
example.com.  TXT  "v=spf1 a mx include:_spf.google.com ~all"

سازوکارهای include، a، mx، ptr و exists و اصلاح‌گر redirect، با احتساب includeهای تودرتو، روی هم حداکثر ۱۰ پرس‌وجو مجازند و بیش از ۲ پرس‌وجوی بی‌پاسخ هم خطا می‌دهد؛ ip4 و ip6 شمرده نمی‌شوند. تا مطمئن نشده‌اید همهٔ فرستنده‌ها در رکورد آمده‌اند، از ~all (رد نرم) استفاده کنید، نه -all (رد قطعی).

DKIM و DMARC

کلید DKIM را سرویس ایمیل می‌سازد و شما رکورد TXT آن را در selector._domainkey منتشر می‌کنید (selector در cPanel معمولاً default است). کلید ۲۰۴۸ بیتی از ۲۵۵ کاراکتر بلندتر است و اگر پنل خودش تقسیمش نکند، باید در چند رشته وارد شود:

default._domainkey.example.com. TXT ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..." )

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

DMARC را با p=none شروع کنید تا فقط گزارش بگیرید؛ Google توصیه می‌کند SPF و DKIM پیش از آن دست‌کم ۴۸ ساعت فعال باشند. وقتی گزارش‌ها نشان داد همهٔ فرستنده‌های واقعی‌تان احراز هویت می‌شوند، به quarantine و بعد reject بروید.

سرور ایمیل روی VPS و رکورد PTR

برای سرور ایمیل شخصی سه چیز باید هم‌خوان باشد: mail.example.com رکورد A به IP سرور داشته باشد، PTR همان IP به همان نام برگردد و MX به همان نام اشاره کند. از فوریهٔ ۲۰۲۴ (بهمن ۱۴۰۲) Gmail از همهٔ فرستنده‌ها SPF یا DKIM و DNS مستقیم و معکوس معتبر می‌خواهد و از فرستنده‌های بیش از ۵۰۰۰ نامه در روز به Gmail، هر سه SPF، DKIM و DMARC را.

$ dig mail.example.com A +short
203.0.113.20
$ dig -x 203.0.113.20 +short
mail.example.com.

پیش از خرید سرور برای ایمیل، از ارائه‌دهنده بپرسید امکان تنظیم PTR برای IP سرور و باز بودن پورت 25 خروجی وجود دارد یا نه؛ بسیاری از ارائه‌دهنده‌ها این پورت را به‌طور پیش‌فرض می‌بندند. برای چند صندوق ایمیل معمولی، ایمیل هاست کم‌دردسرتر از نگه‌داری سرور ایمیل است.

تأیید دامنه در Google Search Console

1. در Search Console روی Add property بزنید، نوع Domain را انتخاب کنید و example.com را بدون https و www بنویسید.
2. مقدار google-site-verification=... را کپی کنید و یک رکورد TXT با Name برابر @ (یا خالی) و همین مقدار بسازید.
3. با dig TXT example.com +short مطمئن شوید رکورد دیده می‌شود و Verify را بزنید. به گفتهٔ Google ارائهٔ رکورد ممکن است تا دو سه روز طول بکشد؛ اگر ناموفق بود، بعداً دوباره امتحان کنید.

ویژگی نوع Domain فقط با رکورد DNS (TXT یا در برخی حالت‌ها CNAME) تأیید می‌شود. رکورد را بعد از تأیید پاک نکنید، چون مالکیت از دست می‌رود. کنار SPF بودنش هم مشکلی ندارد؛ محدودیت «یک رکورد» برای SPF، DMARC و هر selector در DKIM است، نه برای TXTهای تأیید مالکیت.

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

dig در لینوکس و macOS

dig روی macOS نصب است. در Ubuntu 24.04 و Debian 12 و 13 بستهٔ آن bind9-dnsutils است؛ نام قدیمی dnsutils هم به همین بسته می‌رسد:

sudo apt update && sudo apt install bind9-dnsutils

dig example.com A +short                    # A record
dig example.com MX +short                   # mail servers
dig example.com TXT +short                  # SPF, verification
dig _dmarc.example.com TXT +short           # DMARC
dig example.com NS +short                   # who hosts the zone
dig example.com A +noall +answer            # answer with remaining TTL
dig @1.1.1.1 example.com A +short           # ask a specific resolver
dig @ns1.example.net example.com A +short   # ask the authoritative server
dig -x 203.0.113.10 +short                  # reverse lookup (PTR)
dig +trace example.com                      # full path from the root

در خروجی کامل dig (بدون +short)، مقدار status در خط HEADER مهم‌ترین سرنخ است:

status	معنا	چه کنید
NOERROR با پاسخ	رکورد پیدا شد	مقدار را با انتظارتان مقایسه کنید
NOERROR بدون پاسخ	نام هست، این نوع رکورد نیست	رکورد از نوع درست بسازید
NXDOMAIN	چنین نامی وجود ندارد	املای نام، منطقهٔ درست، کش منفی
SERVFAIL	resolver پاسخ معتبر نگرفت	نیم‌سرورها و DNSSEC را بررسی کنید
REFUSED	سرور به این پرسش پاسخ نمی‌دهد	از سرور مرجع یا resolver درست بپرسید

nslookup و PowerShell در ویندوز

nslookup example.com
nslookup -type=mx example.com
nslookup -type=txt example.com 1.1.1.1
Resolve-DnsName example.com -Type MX
Resolve-DnsName example.com -Type TXT -Server 1.1.1.1

عبارت Non-authoritative answer در خروجی nslookup خطا نیست؛ یعنی پاسخ از resolver آمده است. برای پرسیدن از نیم‌سرور مرجع، نام آن را به‌جای 1.1.1.1 بنویسید.

پاک کردن کش و ابزار آنلاین

سیستم	دستور
ویندوز	ipconfig /flushdns
Ubuntu 24.04 (systemd-resolved)	sudo resolvectl flush-caches
macOS	sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
Chrome	chrome://net-internals/#dns و دکمهٔ Clear host cache

این دستورها فقط کش دستگاه شما را پاک می‌کنند، نه کش resolver اپراتور. برای دیدن رکورد از بیرون شبکهٔ خودتان، Dig در Google Admin Toolbox مفید است. سایت‌های DNS Propagation Checker فقط وضعیت کش resolverهای مختلف را نشان می‌دهند؛ معیار درستی رکورد، پاسخ نیم‌سرور مرجع است.

عیب‌یابی و اشتباهات رایج DNS

سایت هنوز سرور قبلی را نشان می‌دهد

علت: کش resolver یا مرورگر (اگر Secure DNS مرورگر روشن باشد، از resolver دیگری می‌پرسد)، خطی جامانده در فایل hosts یا رکورد AAAA قدیمی. راه‌حل: پاسخ مرجع را با dig @nameserver ببینید؛ اگر درست است، AAAA اضافه را حذف کنید، کش را پاک کنید و منتظر پایان TTL بمانید.

دامنهٔ اصلی باز می‌شود ولی www نه

علت: یکی از دو نام رکورد ندارد یا وب‌سرور فقط برای یکی پیکربندی شده است. راه‌حل: هر دو نام را جدا با dig بپرسید. اگر DNS درست است، نام دوم را به server_name در Nginx یا ServerAlias در Apache و به گواهی SSL اضافه کنید.

نام دامنه دو بار تکرار شده است

علت: بیشتر پنل‌ها دامنه را خودشان به فیلد Name اضافه می‌کنند؛ نوشتن www.example.com در آن، رکورد www.example.com.example.com می‌سازد. جاانداختن نقطهٔ پایانی در Zone File هم همین اثر را دارد. راه‌حل: در پنل فقط بخش زیردامنه (www) را بنویسید.

ایمیل‌ها به اسپم می‌روند یا برگشت می‌خورند

علت: یکی از رکوردهای بخش ایمیل اشتباه است: دو SPF یا عبور از سقف پرس‌وجوی آن، نبود DKIM، PTR ناهماهنگ یا MX رو به IP یا CNAME. راه‌حل: در Gmail گزینهٔ Show original یک نامهٔ ارسالی را باز کنید؛ جلوی SPF، DKIM و DMARC باید PASS باشد. هر کدام FAIL بود، همان را اصلاح کنید.

SERVFAIL بعد از تغییر سرویس DNS

علت: معمولاً رکورد DS قدیمی DNSSEC در ثبت‌کننده، یا ارجاع به نیم‌سرورهایی که منطقه را ندارند (Lame Delegation). راه‌حل: اگر dig example.com +cd پاسخ می‌دهد ولی بدون +cd خطای SERVFAIL می‌گیرید، مشکل از DNSSEC است؛ DS را در ثبت‌کننده حذف کنید، یا اگر سرویس جدید DNSSEC را روشن کرده، DS تازهٔ آن را جایگزین کنید.

Let’s Encrypt گواهی صادر نمی‌کند

علت: A یا AAAA به سرور دیگری اشاره می‌کند، CAA اجازهٔ letsencrypt.org را نمی‌دهد یا NXDOMAIN هنوز در کش است. راه‌حل: هر سه را با dig بررسی و اصلاح کنید و دوباره درخواست بدهید.

پاسخ 10.10.34.x از داخل ایران

علت: اگر dig از داخل ایران برای دامنه‌ای آدرسی مثل 10.10.34.34 یا 10.10.34.36 برمی‌گرداند، آن دامنه در ایران فیلتر است و پاسخ در مسیر شبکه جایگزین شده؛ با تغییر رکورد هم عوض نمی‌شود. DNSهای داخلی مخصوص دسترسی به سرویس‌های تحریم‌شده هم برای برخی دامنه‌ها عمداً IP دیگری برمی‌گردانند. راه‌حل: رکورد را در پنل DNS خودتان یا با ابزاری آنلاین از بیرون ایران بررسی کنید.

امنیت و نکات حرفه‌ای DNS

• حساب ثبت‌کننده را محافظت کنید: هر کس نیم‌سرورها را کنترل کند، سایت و ایمیل شما را کنترل می‌کند. ورود دومرحله‌ای و قفل انتقال (Transfer Lock) را فعال کنید؛ جزئیات در روش‌های افزایش امنیت دامنه آمده است.
• DNSSEC را با برنامه روشن و خاموش کنید: برای فعال‌سازی، اول آن را در سرویس DNS روشن کنید و بعد رکورد DS را در ثبت‌کننده بگذارید. پیش از تغییر سرویس DNS، DS را در ثبت‌کننده حذف کنید و دست‌کم به اندازهٔ TTL آن (برای .com معمولاً ۸۶۴۰۰ ثانیه، یعنی یک روز) صبر کنید؛ بعد نیم‌سرور را عوض کنید و پس از فعال شدن سرویس جدید، DNSSEC را در آن روشن کنید و DS تازه را بگذارید. گذاشتن DS سرویس جدید پیش از تغییر نیم‌سرور، دامنه را برای resolverهای اعتبارسنج (مثل 1.1.1.1 و 8.8.8.8) با خطای SERVFAIL از دسترس خارج می‌کند.
• دو نیم‌سرور در شبکه‌های جدا: تا قطعی یک شبکه کل دامنه را از دسترس خارج نکند (RFC 2182).
• رکوردهای رهاشده را پاک کنید: CNAMEی که به سرویس حذف‌شده اشاره می‌کند ممکن است به دست شخص دیگری بیفتد (Subdomain Takeover).
• وابستگی به اتصال بین‌المللی را بسنجید: اگر مخاطبان و سرور داخل ایران‌اند ولی نیم‌سرورها خارج از ایران، هنگام اختلال در اتصال بین‌المللی ممکن است resolverهای داخلی پس از پایان TTL پاسخ تازه نگیرند.
• resolver باز نسازید: اگر BIND را به‌عنوان نیم‌سرور مرجع روی سرور خود نصب می‌کنید، recursion را ببندید تا سرورتان ابزار حملات تقویتی (DNS Amplification) نشود. این دو خط را به بلوک options موجود اضافه کنید، نه این‌که کل فایل را جایگزین کنید:

// /etc/bind/named.conf.options (Ubuntu/Debian)
options {
    // keep the existing lines here
    recursion no;              // authoritative only
    allow-transfer { none; };  // or list your secondary servers
};

بعد پیکربندی را بررسی و بارگذاری کنید و اگر فایروال ufw فعال است، پورت 53 را باز کنید (بدون ذکر پروتکل، UDP و TCP هر دو باز می‌شوند):

sudo named-checkconf && sudo systemctl reload named
sudo ufw allow 53

حالا dig @203.0.113.10 google.com از بیرون سرور نباید پاسخی برگرداند و معمولاً status: REFUSED می‌دهد.

هاست، دامنه یا سرور مجازی؟

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

اگر اپلیکیشن، ربات یا سرویسی با پورت و تنظیمات خاص اجرا می‌کنید، سرور مجازی انتخاب منطقی‌تری است؛ سرور مجازی هاکان سرور در ۵۲ لوکیشن ارائه می‌شود. IP سرویس تا زمانی که سرویس تمدید شود ثابت می‌ماند؛ پس رکورد A آن را لازم نیست دوباره تغییر دهید. پشتیبانی فنی ۲۴ ساعته از طریق تیکت در دسترس است.

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

DNS و IP چه فرقی دارند؟

IP آدرس عددی یک دستگاه در شبکه است و DNS سیستمی که نام را به آن آدرس ترجمه می‌کند. برای همین می‌توانید سایت را به سرور دیگری ببرید و فقط با تغییر رکورد A نشانی را به‌روز کنید.

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

تغییر یک رکورد حداکثر به اندازهٔ TTL قبلی آن طول می‌کشد؛ با TTL ۳۰۰ ثانیه، چند دقیقه. تغییر نیم‌سرور به TTL سرور TLD بستگی دارد: برای .com تا ۲ روز و برای .ir معمولاً کوتاه‌تر.

نیم‌سرور چیست و چند تا لازم است؟

نیم‌سرور سروری است که رکوردهای دامنهٔ شما روی آن قرار دارد. دست‌کم دو نیم‌سرور لازم است و بهتر است در شبکه‌های جدا باشند تا قطعی یکی، دامنه را از کار نیندازد.

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

رکورد A نام را مستقیم به IP وصل می‌کند و CNAME آن را به نام دیگری می‌فرستد. برای خود دامنه A بگذارید؛ برای www یا زیردامنه‌ای که به سرویس بیرونی با IP متغیر اشاره می‌کند، CNAME مناسب‌تر است.

تغییر DNS ویندوز یا مودم چه ربطی به رکوردهای دامنه دارد؟

ربط مستقیمی ندارد. DNS تنظیم‌شده روی ویندوز، مودم یا روتر فقط resolverی است که از طرف شما می‌پرسد؛ رکوردهای دامنه روی نیم‌سرورهای مرجع تعریف می‌شوند. برای تنظیم resolver روی روتر میکروتیک، راهنمای کانفیگ DNS در سرور میکروتیک را ببینید.

جمع‌بندی

DNS زنجیره‌ای از ارجاع‌هاست، از ریشه تا نیم‌سرور مرجع، و در هر مرحله کش و TTL در کار است. بیشتر مشکلات DNS در یکی از سه دسته جا می‌گیرند: رکورد در جای اشتباه ویرایش شده، خود رکورد اشتباه است (CNAME روی دامنهٔ اصلی، دو SPF، MX رو به IP) یا کش هنوز تمام نشده است.

قدم بعدی: با dig NS ببینید DNS دامنهٔ شما کجا مدیریت می‌شود، رکوردهای فعلی را با بخش عیب‌یابی مقایسه کنید و اگر از دامنه ایمیل می‌فرستید، SPF، DKIM و DMARC را بررسی کنید.