برای اتصال دامنه به سرور، یک رکورد A برای ریشهٔ دامنه (@) با آی‌پی سرور و یک رکورد A یا CNAME برای www بسازید؛ اگر سرور IPv6 دارد، رکورد AAAA هم اضافه کنید. ایمیل دامنه با رکوردهای MX و تنظیمات SPF، DKIM و DMARC در رکوردهای TXT کار می‌کند. CNAME را روی ریشهٔ دامنه نگذارید و پس از هر تغییر، نتیجه را با dig بررسی کنید.
پیش از شروع: رکوردها را کجا تنظیم کنیم؟
رکوردهای DNS در پنل جایی تنظیم می‌شوند که Name Serverهای دامنهٔ شما به آن اشاره می‌کنند. این جا ممکن است پنل ثبت‌کنندهٔ دامنه باشد، یک سرویس DNS مثل Cloudflare، یا CDNی که دامنه را به آن سپرده‌اید. اشتباه رایج این است که رکورد را در پنلی تغییر می‌دهید که دیگر مسئول دامنه نیست و هیچ اثری نمی‌بینید.
برای اطمینان، Name Serverهای فعلی را ببینید:
dig NS example.com +short
هر پنلی که این Name Serverها متعلق به آن است، همان‌جا باید رکوردها را ویرایش کنید. اگر با مفاهیم پایه آشنا نیستید، ابتدا مقالهٔ DNS چیست و چطور کار می‌کند را بخوانید.
اجزای هر رکورد
در همهٔ پنل‌ها، هر رکورد این بخش‌ها را دارد:
- Type (نوع): A، AAAA، CNAME، MX، TXT و غیره.
- Name (نام): زیردامنه‌ای که رکورد برای آن است. علامت
@یعنی خود دامنه (مثلاًexample.com) وwwwیعنیwww.example.com. در برخی پنل‌ها باید نام کامل را بنویسید. - Value (مقدار): آی‌پی، نام مقصد یا متن، بسته به نوع رکورد.
- TTL: مدتی که پاسخ در کش Resolverها می‌ماند. مقدار «Auto» یا چند دقیقه تا یک ساعت برای بیشتر کاربردها مناسب است.
اتصال دامنه به سرور: رکورد A و AAAA
رکورد A نام دامنه را به آی‌پی نسخهٔ ۴ سرور متصل می‌کند. برای راه‌اندازی یک سایت، معمولاً این دو رکورد لازم است:
| Type | Name | Value |
|---|---|---|
| A | @ | 203.0.113.10 |
| A | www | 203.0.113.10 |
اگر سرور آی‌پی نسخهٔ ۶ هم دارد، رکوردهای AAAA معادل را اضافه کنید تا کاربران IPv6 مستقیم وصل شوند. فقط وقتی AAAA بسازید که سرویس واقعاً روی IPv6 در دسترس باشد؛ رکورد AAAA به آدرسی که وب‌سرور روی آن گوش نمی‌دهد، باعث میشود برخی کاربران سایت را باز نکنند یا با تأخیر باز کنند.
پس از ساخت رکوردها، باید روی سرور هم وب‌سرور را برای این دامنه پیکربندی کنید و گواهی SSL بگیرید؛ مراحل کامل در آموزش Nginx و Let's Encrypt آمده است. Certbot برای صدور گواهی نیاز دارد که رکورد A از قبل به سرور اشاره کند.
زیردامنه با CNAME
CNAME یک نام را به نام دیگری ارجاع می‌دهد، نه به آی‌پی. کاربرد رایجش اتصال زیردامنه به سرویسی است که آدرس ثابتی به شکل نام به شما می‌دهد؛ مثل CDN، سرویس ایمیل‌مارکتینگ یا صفحه‌سازها:
| Type | Name | Value |
|---|---|---|
| CNAME | www | example.com |
| CNAME | cdn | your-id.cdn-provider.example |
سه قاعدهٔ مهم CNAME:
- روی ریشهٔ دامنه (@) CNAME نگذارید. استاندارد DNS اجازه نمی‌دهد نامی که CNAME دارد رکورد دیگری داشته باشد و ریشهٔ دامنه همیشه رکوردهای NS و SOA دارد. برخی ارائه‌دهندگان با قابلیتی به نام CNAME Flattening یا ALIAS این محدودیت را دور می‌زنند.
- نامی که CNAME دارد نمی‌تواند هم‌زمان رکورد MX یا TXT داشته باشد.
- مقدار CNAME را بدون
http://و بدون مسیر بنویسید؛ فقط نام میزبان.
توضیح کامل‌تر و مثال‌های CDN در رکورد CNAME چیست آمده است. برای اتصال دامنهٔ اختصاصی به CDN کلودیفای هم مراحل در راهنمای تنظیم CNAME توضیح داده شده است.
- به آی‌پی اشاره می‌کند
- روی ریشهٔ دامنه مجاز است
- با تغییر آی‌پی باید دستی عوض شود
- کنار MX و TXT مشکلی ندارد
- به نام دیگری اشاره می‌کند
- روی ریشهٔ دامنه مجاز نیست
- تغییرات مقصد خودکار دنبال میشود
- مناسب CDN و سرویس‌های خارجی
ایمیل دامنه: MX و TXT
اگر می‌خواهید ایمیل‌هایی مثل info@example.com داشته باشید، ارائه‌دهندهٔ ایمیل (سرویس ایمیل سازمانی یا سرور ایمیل خودتان) مقادیر لازم را به شما می‌دهد. ساختار کلی:
| Type | Name | Value | Priority |
|---|---|---|---|
| MX | @ | mail.example.com | 10 |
| TXT | @ | v=spf1 include:_spf.provider.example ~all | — |
| TXT | selector._domainkey | v=DKIM1; k=rsa; p=… | — |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@example.com | — |
- MX سرورهای دریافت ایمیل را تعیین می‌کند. عدد Priority کمتر یعنی اولویت بالاتر. مقدار MX باید نام میزبان باشد، نه آی‌پی، و آن نام نباید CNAME باشد.
- SPF (در TXT) مشخص می‌کند کدام سرورها مجازند از طرف دامنهٔ شما ایمیل بفرستند. هر دامنه فقط یک رکورد SPF باید داشته باشد؛ اگر چند سرویس دارید، همه را در یک رکورد ترکیب کنید.
- DKIM کلید عمومی امضای ایمیل‌هاست که ارائه‌دهنده می‌دهد.
- DMARC سیاست برخورد با ایمیل‌هایی را تعیین می‌کند که SPF یا DKIM را رد می‌کنند. با
p=noneشروع کنید و پس از اطمینان سخت‌گیرتر شوید.
بدون این سه رکورد، ایمیل‌هایی که از سرور شما ارسال می‌شوند (مثلاً ایمیل فراموشی رمز سایت) احتمال زیادی دارد که در پوشهٔ اسپم بیفتند.
رکوردهای کاربردی دیگر
- TXT برای تأیید مالکیت: Google Search Console و بسیاری سرویس‌ها برای تأیید مالکیت دامنه یک رکورد TXT با مقدار مشخص می‌خواهند.
- CAA: مشخص می‌کند کدام مراکز صدور گواهی اجازه دارند برای دامنهٔ شما گواهی SSL صادر کنند؛ مثلاً
0 issue "letsencrypt.org". اگر CAA تعریف کنید و مرکز صدور مورد استفاده‌تان در آن نباشد، صدور گواهی شکست می‌خورد. - رکورد Wildcard: نام
*همهٔ زیردامنه‌هایی را که رکورد مشخصی ندارند پوشش می‌دهد؛ برای سرویس‌هایی که برای هر مشتری زیردامنه می‌سازند کاربرد دارد.
TTL و زمان اعمال تغییرات
تغییر رکوردها بلافاصله در Name Server ثبت میشود، اما Resolverهایی که پاسخ قبلی را کش کرده‌اند تا پایان TTL همان را برمی‌گردانند. اگر قرار است آی‌پی سرور را عوض کنید، از یک روز قبل TTL را کم کنید. توضیح کامل این موضوع در انتشار DNS چقدر طول می‌کشد آمده است.
بررسی رکوردها با dig
پس از هر تغییر، به‌جای اینکه فقط مرورگر را رفرش کنید، رکوردها را مستقیم بررسی کنید:
dig example.com A +short
dig www.example.com +short
dig example.com AAAA +short
dig example.com MX +short
dig example.com TXT +short
# پرسش مستقیم از Name Server دامنه (بدون کش)
dig @ns1.provider.example example.com A
اگر پاسخ Name Server درست است ولی Resolverهای دیگر هنوز پاسخ قدیمی می‌دهند، فقط باید منتظر پایان TTL بمانید.
$ dig NS example.com +shortns1.provider.example.$ dig example.com A +short203.0.113.10$ dig www.example.com +shortexample.com.203.0.113.10$ dig example.com MX +short10 mail.example.com.$
یک سناریوی کامل: سایت روی سرور، فایل‌ها روی CDN، ایمیل روی سرویس جداگانه
برای اینکه همه‌چیز کنار هم معنا پیدا کند، فرض کنید یک فروشگاه اینترنتی دارید. سایت روی سرور مجازی خودتان اجرا میشود، تصاویر و فایل‌های ثابت از طریق CDN تحویل داده می‌شوند و ایمیل سازمانی را یک سرویس ایمیل مدیریت می‌کند. رکوردهای لازم این‌ها هستند: یک رکورد A برای ریشهٔ دامنه و یک CNAME برای www که هر دو به سرور می‌رسند؛ یک CNAME برای زیردامنهٔ static که به آدرس CDN اشاره می‌کند؛ رکوردهای MX که ارائه‌دهندهٔ ایمیل داده است؛ یک رکورد TXT برای SPF که هم سرویس ایمیل و هم سرور سایت (برای ایمیل‌های سفارش) را مجاز می‌کند؛ رکورد DKIM و رکورد DMARC.
نکته اینجاست که هر سرویس فقط رکوردهای خودش را لازم دارد و تغییر یکی روی بقیه اثری ندارد. اگر روزی سرور را عوض کنید، فقط رکورد A تغییر می‌کند و ایمیل و CDN دست‌نخورده می‌مانند.
اشتباه‌های رایج
- ساختن رکورد در پنلی که Name Serverهای دامنه به آن اشاره نمی‌کنند.
- نوشتن نام کامل در فیلد Name در پنلی که خودش دامنه را اضافه می‌کند؛ نتیجه نامی مثل
www.example.com.example.comاست. - CNAME روی ریشهٔ دامنه یا کنار MX.
- دو رکورد SPF جداگانه به‌جای یک رکورد ترکیبی.
- رکورد AAAA به آی‌پی‌ای که سرویس روی آن در دسترس نیست.
- فراموش کردن رکورد www؛ کاربرانی که با www وارد می‌شوند خطا می‌گیرند.
با رعایت این نکته‌ها، اتصال دامنه به سرور مجازی و سرویس‌هایتان بدون دردسر انجام میشود.
سؤالات متداول
برای اتصال دامنه به سرور کدام رکورد لازم است؟
یک رکورد A برای ریشهٔ دامنه با نام @ و یک رکورد A یا CNAME برای www. اگر سرور IPv6 دارد و سرویس روی آن در دسترس است، رکوردهای AAAA را هم اضافه کنید.
چرا نمی‌توانم روی ریشهٔ دامنه CNAME بسازم؟
طبق استاندارد DNS، نامی که CNAME دارد نباید رکورد دیگری داشته باشد، اما ریشهٔ دامنه همیشه رکوردهای NS و SOA دارد. برخی ارائه‌دهندگان با ALIAS یا CNAME Flattening این محدودیت را جبران می‌کنند.
چند رکورد SPF میتوانم داشته باشم؟
فقط یکی. وجود دو رکورد SPF باعث خطا در ارزیابی میشود. اگر چند سرویس ارسال ایمیل دارید، همهٔ includeها را در یک رکورد ترکیب کنید.
رکورد را ساختم ولی سایت هنوز باز نمی‌شود؛ چرا؟
اول با dig بررسی کنید رکورد درست ثبت شده است. اگر Name Server پاسخ درست می‌دهد، احتمالاً کش Resolverها هنوز پاسخ قبلی را دارد یا وب‌سرور روی سرور برای این دامنه پیکربندی نشده است.
از ۱٬۲۰۰ تومان در ساعت · پرداخت ریالی
مقالات مرتبط
رکورد CNAME چیست، چه فرقی با رکورد A دارد و چطور یک ساب‌دامنه را با CNAME به CDN وصل کنیم؛ همراه با تنظیم در Cloudflare، تست با dig و رفع خطاهای رایج.
ادامه
چرا تغییر رکورد DNS دیر اعمال میشود: TTL، کش ریزالورها، کش مرورگر و سیستم‌عامل، تغییر NS؛ روش بررسی با dig و nslookup، پاک کردن کش و برنامه‌ریزی جابه‌جایی سرور بدون قطعی.
ادامه
آموزش نصب Nginx روی Ubuntu 24.04، ساخت server block برای دامنه، گرفتن گواهی SSL رایگان Let's Encrypt با Certbot، ریدایرکت HTTPS، تمدید خودکار و پیکربندی reverse proxy برای اپلیکیشن.
ادامه
۱۰ کار امنیتی ضروری بلافاصله بعد از تحویل سرور لینوکس: به‌روزرسانی، کاربر sudo، کلید SSH، غیرفعال‌سازی ورود با رمز، فایروال UFW، Fail2ban، به‌روزرسانی خودکار و بکاپ.
ادامه