# DNS چیست؟ رکوردهای A، CNAME، MX و TXT با مثال + اتصال دامنه به سرور > DNS چیست و چطور کار می‌کند؟ رکوردهای DNS با مثال واقعی، اتصال دامنه به سرور، تنظیم MX، SPF و DMARC، بررسی با dig و رفع خطاهای رایج. - صفحه: https://hakanserver.com/what-is-dns/ - تاریخ انتشار: ۱۲ آبان ۱۴۰۵ (2026-11-03) - دسته: دامنه - زمان مطالعه: حدود 23 دقیقه ![تصویر مفهومی DNS: دفترچهٔ آدرسی که نام دامنه را به IP سرور وصل می‌کند](https://hakanserver.com/wp-content/uploads/2026/11/what-is-dns.jpg) 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](https://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](https://hakanserver.com/buy-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](https://hakanserver.com/email-problem-in-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](https://toolbox.googleapps.com/apps/dig/) مفید است. سایت‌های 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) را فعال کنید؛ جزئیات در [روش‌های افزایش امنیت دامنه](https://hakanserver.com/%D8%A7%D9%81%D8%B2%D8%A7%DB%8C%D8%B4-%D8%A7%D9%85%D9%86%DB%8C%D8%AA-%D8%AF%D8%A7%D9%85%D9%86%D9%87/) آمده است. - **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 و ایمیل را با ابزار گرافیکی در اختیارتان می‌گذارد. اگر دامنه و هاست را با هم لازم دارید، صفحهٔ [هاست و دامنه](https://hakanserver.com/buy-hosting-and-domain/) هاکان سرور را ببینید. اگر اپلیکیشن، ربات یا سرویسی با پورت و تنظیمات خاص اجرا می‌کنید، [سرور مجازی](https://hakanserver.com/buy-a-virtual-server/) انتخاب منطقی‌تری است؛ سرور مجازی هاکان سرور در ۵۲ لوکیشن ارائه می‌شود. 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 در سرور میکروتیک](https://hakanserver.com/dns-configuration-on-mikrotik-server/) را ببینید. ## جمع‌بندی DNS زنجیره‌ای از ارجاع‌هاست، از ریشه تا نیم‌سرور مرجع، و در هر مرحله کش و TTL در کار است. بیشتر مشکلات DNS در یکی از سه دسته جا می‌گیرند: رکورد در جای اشتباه ویرایش شده، خود رکورد اشتباه است (CNAME روی دامنهٔ اصلی، دو SPF، MX رو به IP) یا کش هنوز تمام نشده است. قدم بعدی: با `dig NS` ببینید DNS دامنهٔ شما کجا مدیریت می‌شود، رکوردهای فعلی را با بخش عیب‌یابی مقایسه کنید و اگر از دامنه ایمیل می‌فرستید، SPF، DKIM و DMARC را بررسی کنید. - مطلب قبلی: [سرور ابری چیست؟ تفاوت با سرور مجازی و اختصاصی + چک‌لیست خرید](https://hakanserver.com/what-is-cloud-server/index.md) - مطلب بعدی: [نصب IIS روی ویندوز سرور؛ راه‌اندازی سایت، PHP و SSL رایگان](https://hakanserver.com/install-iis-windows-server/index.md) ## مقاله‌های مرتبط - [چرا ایمیل‌ها در cPanel ارسال نمی‌شوند؟حل مشکلات ایمیل](https://hakanserver.com/email-problem-in-cpanel/index.md) - [کانفیگ DNS در سرور میکروتیک](https://hakanserver.com/dns-configuration-on-mikrotik-server/index.md) - [هاست چیست؟ انواع هاست و راهنمای انتخاب هاست مناسب](https://hakanserver.com/%D9%87%D8%A7%D8%B3%D8%AA-%DA%86%DB%8C%D8%B3%D8%AA-%D9%88-%DA%86%D9%87-%D8%A7%D9%86%D9%88%D8%A7%D8%B9%DB%8C-%D8%AF%D8%A7%D8%B1%D8%AF%D8%9F/index.md) ## سرویس‌های مرتبط هاکان سرور - [سرور مجازی](https://hakanserver.com/buy-a-virtual-server/index.md): ۵۲ لوکیشن در ایران و خارج - [سرور اختصاصی](https://hakanserver.com/dedicatedserver/index.md): ایران و ۸ کشور دیگر - [هاست و دامنه](https://hakanserver.com/buy-hosting-and-domain/index.md): هاست سی‌پنل ایران و اروپا فهرست همهٔ مقاله‌ها: https://hakanserver.com/blog/index.md فهرست همهٔ صفحه‌ها و راهنمای سایت: https://hakanserver.com/llms.txt