CNAME عادی را نمی‌توان کنار رکوردهای ضروریِ ریشهٔ همان Zone به کار برد؛ برای وصل‌کردن ریشهٔ دامنه به یک نامِ سرویس، باید قابلیت مشخصِ ارائه‌دهنده مانند ALIAS یا CNAME Flattening را بررسی کنید. این قابلیت‌ها الزاماً رکورد CNAME استاندارد را به کاربر DNS تحویل نمی‌دهند و رفتارشان در همهٔ سرویس‌ها یکسان نیست. حذف NS، SOA یا MX برای جا دادن CNAME راه‌حل درست نیست.
اگر سرویس می‌گوید «این دامنه را با CNAME متصل کنید»، ابتدا معلوم کنید منظور www.example.com است یا خود example.com. این راهنما برای انتخاب و بررسی است؛ هیچ رکوردی در DNS زنده تغییر نمی‌دهد. مبانی را در راهنمای DNS و محل اعمال تنظیم را در مرجع مدیریت DNS دامنه ببینید.
۱. ریشهٔ Zone دقیقاً کجاست؟
ریشه یا Zone Apex نامی است که Zone از آن شروع می‌شود. برای Zone با نام example.com، ریشه همین نام است؛ www.example.com یک نام زیرمجموعه است. اگر یک زیردامنه به Zone مستقل واگذار شده باشد، آن Zone هم ریشهٔ خودش را دارد. بنابراین «هر نامی که زیردامنه است می‌تواند در ریشهٔ Zone خود CNAME عادی شود» برداشت درستی نیست.
علامت @ در بسیاری از پنل‌ها نمایش کوتاه ریشهٔ Zone است، نه یک نام عمومی که باید داخل مقصد CNAME تایپ شود. در مقابل، مقدار CNAME یک نام DNS است؛ آدرس دارای https://، مسیر /app/، شمارهٔ پورت یا IP جای آن نیست.
۲. چرا CNAME عادی در ریشه مشکل دارد؟
طبق بخش CNAME در RFC ۲۱۸۱، نام مستعار عادی نباید داده‌های معمولِ دیگر را هم‌زمان در همان نام داشته باشد؛ داده‌های همراه امنیت DNS استثنای فنی خود را دارند. ریشهٔ Zone به SOA و NS نیاز دارد. تعارض، مربوط به همین نام است؛ نه اینکه تمام Zone پس از داشتن یک CNAME نتواند MX یا TXT داشته باشد.
| نمونهٔ آموزشی | ارزیابی |
|---|---|
www.example.com با CNAME به نام سرویس |
در صورت نبود دادهٔ متعارض در همان نام، الگوی معمولِ قابل بررسی است. |
example.com با CNAME عادی کنار SOA و NS |
تعارض ریشهٔ Zone؛ با حذف رکوردهای ضروری برطرف نمی‌شود. |
| A و CNAME عادی برای نام کاملاً یکسان | انتخاب دو مقصد مستقل نیست؛ تعارض نوع رکورد است. |
CNAME روی www و MX روی example.com |
دو نام متفاوت‌اند؛ صرف این ترکیب تعارض هم‌نام ایجاد نمی‌کند. |
این جدول طرح مفهومی است، نه Zone آمادهٔ کپی. قبل از انتخاب راهکار، نام دقیق و همهٔ رکوردهای همان نام باید مشخص باشند؛ به‌خصوص ایمیل سازمانی، تأیید مالکیت سرویس‌ها و DNSSEC را با تنظیم وب‌سایت یکی نگیرید.
۳. Flattening چه چیزی را عوض می‌کند؟
در CNAME Flattening کلودفلر، سرویس DNS نام مقصد را دنبال می‌کند و IP نهایی را به جای CNAME برمی‌گرداند. به همین دلیل رابط می‌تواند ورودی شبیه CNAME برای ریشه بپذیرد، اما پاسخ عمومیِ پرس‌وجوی A یا AAAA آدرس باشد. رفتار ریشه، سایر نام‌ها و رکوردهای پروکسی‌شده را از مستند همان سرویس بررسی کنید.
دیدن A در پاسخ عمومی ثابت نمی‌کند که مدیر حتماً رکورد A دستی ساخته است. در جهت مقابل، ندیدن CNAME هم ثابت نمی‌کند رکورد گم شده؛ ممکن است پاسخ Flatten شده باشد. برای تشخیص، هم تنظیمِ مرجع DNS و هم پاسخ نوعِ درخواست‌شده را بررسی کنید.
محدودیت مهم: سرویس تأیید مالکیت ممکن است خودِ پاسخ CNAME را انتظار داشته باشد. فعال‌کردن Flattening برای همهٔ CNAMEها می‌تواند آن بررسی را مختل کند؛ قابلیت ریشه را بی‌دلیل به تمام رکوردهای تأیید تعمیم ندهید.
۴. ALIAS با CNAME یکی نیست
نام ALIAS در ارائه‌دهنده‌های مختلف برای رفتارهای متفاوت استفاده می‌شود؛ نوع عمومی و یکسانِ CNAME با نام تازه نیست. برای نمونه، Alias در Amazon Route ۵۳ مقصدهای مجاز و قواعد مشخص خودش را دارد. گزینه‌ای با همین نام در سرویس دیگر الزاماً همان مقصدها یا محدودیت‌ها را ندارد.
| راهکار | قبل از انتخاب چه بپرسیم؟ |
|---|---|
| A یا AAAA | آیا سرویس IP پایدار و رسمی داده و مسئول به‌روزرسانی تغییرات مشخص است؟ |
| CNAME روی زیردامنه | آیا آن نام رکورد متعارض ندارد و سرویس همان نام سفارشی را می‌پذیرد؟ |
| ALIAS یا Flattening در ریشه | آیا مرجع DNS و سرویس مقصد این روش را برای ریشه پشتیبانی می‌کنند؟ پاسخ A/AAAA چگونه تولید می‌شود؟ |
| هدایت HTTP از ریشه به www | آیا یک سرویس وب برای پاسخ و HTTPS نام ریشه وجود دارد؟ DNS به‌تنهایی هدایت HTTP ایجاد نمی‌کند. |
IPهای لحظه‌ای پشت یک نامِ ابری را بدون تأیید سرویس به A ثابت تبدیل نکنید؛ ممکن است بعداً تغییر کنند. همچنین CNAME یا ALIAS گواهی HTTPS برای نام سفارشی شما صادر نمی‌کند؛ پذیرش دامنه و پوشش SSL بخشی جدا از اتصال DNS است.
۵. یک پاسخ واقعی CNAME را بخوانید
در ابزار Google Public DNS، نام عمومی www.python.org و نوع CNAME را بررسی کردیم. این نام فقط نمونهٔ عمومیِ مشاهدهٔ نام مستعار است؛ سرویس یا پیکربندی پیشنهادی برای دامنهٔ شما نیست.
در این مشاهده، Status: 0 و نوع پاسخ 5 ثبت شد؛ مقدار مقصد dualstack.python.map.fastly.net. بود. نقطهٔ انتهایی در خروجی، نمایش نام کامل DNS است. ترتیب، TTL و حتی مقصد سرویس عمومی ممکن است تغییر کند؛ مقدار تصویر را برای سایت خود کپی نکنید.
برای کنترل موضوع ریشه، پرس‌وجوهای CNAME، A، AAAA، SOA و NS را جدا انجام دهید. در آزمون عمومیِ example.com، سؤال CNAME با NOERROR و بدون Answer از نوع CNAME پاسخ گرفت؛ A/AAAA و SOA/NS داده داشتند. این مشاهده تنها وضعیت همان نمونه در زمان آزمون است و به‌تنهایی ثابت نمی‌کند آن سرویس از Flattening استفاده می‌کند.
اگر ابزار با SERVFAIL پاسخ داد، نتیجهٔ آن را «رکورد وجود ندارد» ننامید؛ راهنمای تشخیص SERVFAIL را ببینید. برای خواندن رکوردها با ابزار خط فرمان هم آموزش nslookup موجود است.
۶. تصمیمی بگیرید که ایمیل را مختل نکند
- Zone و ارائه‌دهندهٔ فعال را از نیم‌سرورها مشخص کنید؛ پنل محلیِ یک هاست لزوماً مرجع عمومی نیست.
- نام دقیق موردنیاز سرویس را تعیین کنید: ریشه یا زیردامنه؛ دستور اتصال سرویس را برای همان حالت بخوانید.
- SOA، NS، MX، TXT و رکوردهای تأییدِ فعلی را ثبت کنید؛ صرف نیاز وب، مجوز حذف وابستگی‌های ایمیل نیست.
- پشتیبانی روش انتخابی و اثر آن بر پاسخ عمومی، SSL و تأیید مالکیت را با مسئول DNS بررسی کنید.
- پیش از هر اصلاح واقعی، نسخهٔ قبلی رکوردها، TTL، زمان تغییر و راه بازگردانی مشخص باشد؛ سپس همان نوع پاسخ‌ها و سرویس ایمیل دوباره بررسی شوند.
اگر فقط نام و IP را اشتباه گرفته‌اید، راهنمای نوع رکوردها در Zone Editor و تفاوت نیم‌سرور و رکورد A قدم‌های مقدماتی مناسب‌اند. برای این آموزش هیچ رکوردی ساخته یا حذف نشده است.
۷. پرسش‌های رایج
برای رفتن از example.com به www کافی است CNAME بسازم؟
خیر. تغییر آدرسِ قابل‌مشاهدهٔ مرورگر به پاسخ HTTP نیاز دارد. DNS مقصد اتصال را پیدا می‌کند و HTTPS هم باید نام اولیه را پوشش دهد.
چرا CNAME در پنل هست ولی در سؤال CNAME دیده نمی‌شود؟
Flattening یکی از احتمال‌هاست؛ مرجع اشتباه، نام اشتباه، کش یا رفتار پروکسی هم باید بررسی شوند. از یک پاسخ خالی، حذف رکورد را نتیجه نگیرید.
