پنل DNS را باز کرده‌اید، دامنه را به سرور جدید وصل کرده‌اید، و مرورگر همچنان ERR_NAME_NOT_RESOLVED میدهد. یا بدتر: سایت بالا می‌آید ولی روی www کار می‌کند و روی دامنهٔ بدون www نه. در نُه مورد از ده موردی که این علامت را دیده‌ام، کسی رکورد CNAME را روی ریشهٔ دامنه (zone apex) گذاشته است. این کار طبق RFC 1034 و RFC 2181 ممنوع است و بعضی ارائه‌دهندگان DNS اصلاً اجازه نمی‌دهند ذخیره‌اش کنید؛ بعضی‌ها ذخیره می‌کنند و بعد در resolve رفتار غیرقابل‌پیش‌بینی نشان می‌دهند.
چرا CNAME روی ریشهٔ دامنه کار نمی‌کند
هر ناحیهٔ DNS باید در رأس خودش رکوردهای SOA و NS داشته باشد. اگر روی همان نام یک CNAME بگذارید، یعنی گفته‌اید «هر چیزی که این نام دارد، در واقع نام دیگری است» — و این با وجود SOA تناقض دارد. نتیجه‌اش این است که resolverها بسته به پیاده‌سازی، یا SOA را نادیده می‌گیرند یا کل ناحیه را معیوب می‌بینند.
علامتش همیشه یکسان نیست. گاهی dig جواب میدهد ولی مرورگر نه. گاهی رکورد MX دامنه از کار می‌افتد و ایمیل‌ها بی‌صدا برمی‌گردند، چون CNAME روی ریشه، MX را هم زیر سؤال می‌برد. این بدترین حالت است: سایت سالم به نظر می‌رسد و ایمیل تراکنشی سه روز بعد می‌خوابد.
رکورد A چه زمانی جواب درست است
برای ریشهٔ دامنه، رکورد A (یا AAAA برای IPv6) انتخاب پیش‌فرض است. اگر IP سرور ثابت است، همین را بگذارید و تمام:
example.com. 3600 IN A 185.xxx.xxx.xxx
www.example.com. 3600 IN CNAME example.com.عدد 3600 همان TTL است، بر حسب ثانیه. قبل از هر مهاجرت، این را به ۳۰۰ ثانیه کاهش دهید و یک روز صبر کنید. اگر TTL را روی ۸۶۴۰۰ نگه دارید و بعد IP را عوض کنید، تا یک روز کامل بخشی از کاربران به سرور قدیمی می‌روند و بخشی به جدید. این تفاوت، همان چیزی است که «سایت برای بعضی‌ها باز میشود و برای بعضی‌ها نه» را می‌سازد.
وقتی IP ثابت نیست: ALIAS و ANAME
مشکل واقعی جایی شروع میشود که IP ندارید. روی CDN، روی load balancer ابری، یا روی سرویس‌هایی که IP پشتشان هر چند هفته عوض میشود. اینجا نمی‌توانید A ثابت بگذارید، چون هر بار IP عوض شود باید دستی DNS را ویرایش کنید.
راه‌حل استانداردشده ALIAS است (بعضی ارائه‌دهندگان ANAME می‌نامندش). این رکورد در سطح ناحیه resolve میشود، نه در سطح resolver کاربر. یعنی سرور DNS شما خودش می‌رود مقصد را lookup می‌کند و IP نهایی را بهعنوان A برمیگرداند. از دید کاربر، یک رکورد A معمولی است.
| رکورد | روی ریشه | روی ساب‌دامین | هزینهٔ پنهان |
|---|---|---|---|
A | بله | بله | IP عوض شود، دستی ویرایش می‌خواهد |
CNAME | خیر | بله | یک پرش اضافه در resolve |
ALIAS | بله | بله | وابسته به ارائهدهندهٔ DNS |
اگر DNS دامنه‌تان ALIAS ندارد و نمی‌خواهید nameserver عوض کنید، گزینهٔ سوم این است که DNS را به Cloudflare یا Route 53 بسپارید که هر دو این رکورد را دارند. اینجا انتخاب من روشن است: اگر IP ثابت دارید، A بگذارید و به هیچ چیز دیگری فکر نکنید. اگر IP پویا دارید، ALIAS ارزش تغییر nameserver را دارد.
هزینهٔ پنهان یک پرش اضافه
هر CNAME یک مرحلهٔ lookup اضافه به مسیر resolve اضافه می‌کند. برای یک دامنه این عدد ناچیز است، حدود ۲۰ تا ۵۰ میلی‌ثانیه در شرایط عادی. ولی اگر زنجیره بسازید، فرق می‌کند:
a.example.com CNAME b.example.com
b.example.com CNAME c.example.com
c.example.com CNAME target.cdn.netاینجا resolver باید سه بار پشت سر هم بپرسد. بعضی resolverها بعد از ۸ تا ۱۰ پرش زنجیره را قطع می‌کنند و SERVFAIL برمی‌گردانند. اگر روی www هم CNAME گذاشته‌اید و هم داخل CDN یک CNAME دیگر تعریف کرده‌اید، ممکن است به این سقف نزدیک شوید. زنجیره را کوتاه نگه دارید؛ یک پرش، نه سه تا.
اینجا اشتباه می‌کنند: خیلی‌ها فکر می‌کنند چون CNAME «خودکار IP را دنبال می‌کند»، پس همیشه گزینهٔ امن‌تری از A است. بعد روی ریشه می‌گذارندش و سه ساعت دنبال مشکل در فایروال سرور می‌گردند. نشانه‌اش این است که dig +short example.com روی سیستم شما جواب میدهد ولی روی موبایل با اینترنت همراه نه. اختلاف بین resolverها، امضای رکورد غیرمجاز روی ریشه است.
چطور در عمل تشخیص بدهیم
قبل از هر تغییری، وضعیت فعلی را ببینید. این سه دستور تقریباً همه چیز را روشن می‌کنند:
dig +noall +answer example.com A
dig +noall +answer www.example.com CNAME
dig +trace example.comدستور اول باید یک رکورد A برگرداند. اگر CNAME برگرداند، مشکل همان است که گفتیم. دستور سوم مسیر کامل resolve را از root servers تا ناحیهٔ شما نشان میدهد و اگر جایی زنجیره قطع شده باشد، همان‌جا لو می‌رود. برای بررسی انتشار DNS در نقاط مختلف دنیا هم می‌توانید از ابزارهای رایگان سرورنت استفاده کنید.
یک نکتهٔ عملی دیگر: TTL را قبل از تغییر چک کنید، نه بعدش. اگر TTL فعلی ۸۶۴۰۰ است و شما همین حالا رکورد را عوض کرده‌اید، تا ۲۴ ساعت آینده در وضعیت نیمه‌مهاجرت هستید و هیچ کاری از دستتان برنمی‌آید جز صبر. این را در برنامهٔ مهاجرت لحاظ کنید، وگرنه شب اول با ترافیک نصفه مواجه می‌شوید.
رکوردهای دیگر روی همان نام
یک محدودیت که کمتر گفته میشود: هر نامی که CNAME دارد، نمی‌تواند هیچ رکورد دیگری داشته باشد. نه MX، نه TXT، نه SRV. اگر روی mail.example.com هم CNAME بگذارید و هم MX، بعضی سرورهای ایمیل پیام را رد می‌کنند و بعضی‌ها بی‌صدا به صندوق اسپم می‌فرستند. برای زیردامنه‌های ایمیل، همیشه A بگذارید.
همین قاعده برای رکوردهای تأیید دامنه هم هست. اگر TXT تأیید Google Workspace یا گواهی SSL را روی نامی می‌گذارید که CNAME دارد، تأیید شکست می‌خورد و پیام خطا هم معمولاً گنگ است. اول CNAME را بردارید، TXT را بگذارید، تأیید را بگیرید، بعد اگر لازم بود برگردانید.
برای سایت‌های وردپرسی، این تنظیمات معمولاً یک‌بار انجام میشود و بعد فراموش میشود تا روزی که سرور عوض شود. اگر روی هاست لینوکس هستید و IP سرور ثابت است، همان رکورد A کافی است و نیازی به پیچیدگی بیشتر ندارید. مستندات فنی سرورنت هم در پایگاه دانش جزئیات تنظیم DNS هر سرویس را دارد.
پرسش‌های پرتکرار
آیا می‌توانم روی ریشهٔ دامنه CNAME بگذارم؟
نه، طبق استاندارد DNS این کار مجاز نیست و باعث تعارض با رکوردهای SOA و NS میشود. بعضی پنل‌ها اجازهٔ ذخیره‌اش را می‌دهند ولی رفتار resolverها در برابر آن یکسان نیست و نتیجه‌اش خطاهای پراکنده و سخت‌تشخیص است. برای ریشه از A یا ALIAS استفاده کنید.
تفاوت ALIAS و CNAME چیست؟
CNAME در سمت resolver کاربر resolve میشود و یک نام دیگر را برمیگرداند؛ ALIAS در سمت سرور DNS شما resolve میشود و IP نهایی را بهعنوان A تحویل میدهد. به همین دلیل ALIAS روی ریشهٔ دامنه مجاز است و CNAME نه. پشتیبانی ALIAS به ارائهدهندهٔ DNS شما بستگی دارد.
چرا سایت روی www باز میشود ولی روی دامنهٔ اصلی نه؟
تقریباً همیشه یعنی رکورد www درست تنظیم شده ولی رکورد ریشه وجود ندارد یا اشتباه است. با dig +noall +answer example.com A چک کنید؛ اگر خروجی خالی بود، رکورد ریشه را اضافه کنید. اگر CNAME برگرداند، آن را حذف و با A جایگزین کنید.
TTL را روی چه عددی بگذارم؟
در حالت عادی ۳۶۰۰ ثانیه منطقی است. قبل از مهاجرت یا تغییر IP، آن را به ۳۰۰ ثانیه کاهش دهید و حداقل یک دورهٔ کامل TTL قبلی صبر کنید. بعد از پایدار شدن، می‌توانید دوباره بالا ببرید. TTL پایین دائمی، تعداد کوئری‌های DNS شما را زیاد می‌کند و روی سایت‌های پرترافیک قابل توجه است.
اگر همین حالا درگیر این مسئله هستید، اول با dig وضعیت فعلی را ببینید و بعد تصمیم بگیرید. در بیشتر موارد جواب یک رکورد A ساده است؛ پیچیدگی را فقط جایی اضافه کنید که IP واقعاً ثابت نیست.
دیدگاه‌ها ۰
هنوز دیدگاهی ثبت نشده؛ اولین نفر باشید!