رکورد CNAME چیست؟ نحوهٔ کار alias در DNS و جایی که خراب می‌شود

رکورد CNAME چیست

یک رکورد CNAME (canonical name record) می‌گوید که یک نام DNS نام مستعار (alias) نام دیگری است. www.example.com CNAME example.net یعنی: هر چه می‌خواهید دربارهٔ www.example.com بدانید، به‌جایش از example.net بپرسید. نام سمت چپ alias است؛ نام سمت راست canonical name است، که target هم نامیده می‌شود.

یک CNAME یک hostname نگه می‌دارد، هرگز یک آدرس IP. نمی‌گوید سایت کجا زندگی می‌کند؛ می‌گوید کدام نام دیگر می‌داند. همهٔ فایدهٔ آن همین است: مالک target می‌تواند آدرس‌هایش را هر زمان تغییر دهد، و هر alias که به آن اشاره می‌کند بدون آنکه کسی zone خودش را ویرایش کند دنبالش می‌رود.

این رکورد همان چهار بخش هر رکورد DNS دیگر را دارد: یک نام، یک TTL، نوع و مقدار. در یک zone file شبیه نمونهٔ زیر است. به نقطهٔ پایانی بعد از target توجه کنید: این نشان می‌دهد نام کامل است، جزئیاتی که بخش اشتباهات رایج به آن برمی‌گردد.

وقتی دنبالشان باشید، CNAMEها همه‌جا هستند. www که به یک hostname مربوط به CDN اشاره می‌کند، shop.example.com که به یک پلتفرم فروشگاه میزبانی‌شده اشاره می‌کند، status.example.com که به یک سرویس صفحهٔ وضعیت اشاره می‌کند، و رکوردهای تاییدی که ابزارهای SaaS از شما می‌خواهند بسازید خیلی وقت‌ها CNAME هستند. راهنمای DNS انواع دیگر رکورد را پوشش می‌دهد؛ این مطلب روی alias می‌ماند.

رکوردهای CNAME در یک zone file

$ORIGIN example.com.
; name     TTL   class type   target (canonical name)
www        3600  IN    CNAME  example.cdn-provider.net.
shop       3600  IN    CNAME  shops.hosted-store.example.
status     3600  IN    CNAME  example.status-service.example.

resolver چگونه یک CNAME را دنبال می‌کند

مرورگرها هیچ‌وقت CNAME نمی‌خواهند. آن‌ها یک آدرس می‌خواهند: یک رکورد A برای IPv4 و یک رکورد AAAA برای IPv6. CNAME وقتی وارد بازی می‌شود که resolveری که این جستجو را برایشان انجام می‌دهد، در مسیر به یکی برخورد کند.

resolver از nameserverهای authoritative دامنهٔ example.com رکورد A برای www.example.com را می‌پرسد. به‌جای یک آدرس، آن‌ها با CNAME پاسخ می‌دهند: www.example.com نام مستعار example.cdn-provider.net است. سپس resolver دوباره جستجو را برای نام target شروع می‌کند، این بار از nameserverهای cdn-provider.net، و رکورد A را از آنجا می‌گیرد. هر دو رکورد را به مرورگر برمی‌گرداند: اول CNAME، بعد آدرس.

وقتی یک nameserver برای هر دو نام authoritative باشد، کل زنجیره را در یک پاسخ می‌گذارد و سفر دوم را صرفه‌جویی می‌کند. در غیر این صورت هر hop یک جستجوی جدا است، و برای همین یک CNAME روی یک cache سرد می‌تواند چند میلی‌ثانیه هزینه داشته باشد و وقتی پاسخ‌ها cache شدند هیچ هزینه‌ای ندارد.

اگر خودِ نوع CNAME را بپرسید، resolver روی alias می‌ایستد و آن را دنبال نمی‌کند. این همان کاری است که یک CNAME lookup در اکثر ابزارهای آنلاین می‌کند: به شما می‌گوید یک alias به کدام نام اشاره می‌کند، نه آدرسی که در نهایت به آن می‌رسد.

$ dig www.example.com A +noall +answer
www.example.com.            3600  IN  CNAME  example.cdn-provider.net.
example.cdn-provider.net.     60  IN  A      203.0.113.25

$ dig www.example.com CNAME +short
example.cdn-provider.net.

CNAME در برابر رکوردهای A و AAAA

یک رکورد A یک نام را به یک آدرس IPv4 نگاشت می‌کند و یک رکورد AAAA به یک آدرس IPv6. این‌ها پایان هر جستجو هستند: هر زنجیرهٔ aliasای که یک resolver دنبال کند، روی یک رکورد A یا AAAA متوقف می‌شود. یک CNAME یک نام را به نام دیگری نگاشت می‌کند و همیشه به یک مرحلهٔ بیشتر نیاز دارد.

وقتی خودتان آدرس را کنترل می‌کنید و به‌ندرت تغییر می‌کند، از رکورد A یا AAAA استفاده کنید: سرور خودتان، یک load balancer با IP ثابت، یک VPS. آدرس را خودتان نگه می‌دارید، و اگر تغییر کند باید هر رکوردی که آن را نگه داشته ویرایش کنید.

وقتی کس دیگری آدرس را کنترل می‌کند از CNAME استفاده کنید: یک CDN، یک پلتفرم میزبانی‌شده، یک ابزار SaaS. آدرس‌هایشان می‌تواند تغییر کند، بر اساس منطقه فرق کند، یا از یک pool بیاید، و نباید شما مجبور باشید بدانید. به‌خصوص یک CDN ممکن است به همان hostname در جاهای مختلف با آدرس‌های edge متفاوت پاسخ دهد؛ یک CNAME به hostname آن این رفتار را رایگان می‌گیرد، یک آدرس IP کپی‌شده یک پاسخ را منجمد می‌کند.

تفاوت عملی در سرعت کم است. یک CNAME فقط وقتی target در cache نباشد یک جستجو اضافه می‌کند، و targetهای پرطرفدار تقریباً همیشه هستند. تفاوت در نگهداری زیاد است: یک رکورد A که IP یک provider را hard-code کرده دلیل کلاسیک این است که یک سایت ماه‌ها بعد، وقتی provider آدرس‌هایش را عوض می‌کند، خاموش می‌شود.

چرا دامنهٔ ریشه نمی‌تواند CNAME باشد

این قانون از مشخصات اصلی DNS می‌آید. RFC 1034 بخش 3.6.2 می‌گوید اگر یک CNAME روی یک نام حاضر باشد، هیچ دادهٔ دیگری نباید آنجا حاضر باشد، و RFC 2181 این را تأیید می‌کند. دلیلش نحوهٔ کار resolution است: یک CNAME یعنی «همه‌چیز دربارهٔ این نام جای دیگری زندگی می‌کند»، پس resolveری که یکی را پیدا می‌کند دیگر چیز دیگری روی آن نام جستجو نمی‌کند. یک رکورد دوم کنار آن یا نادیده گرفته می‌شود یا متناقض است. تنها استثنا رکوردهای DNSSEC هستند که خودِ CNAME را امضا می‌کنند.

دامنهٔ ریشه (apex، همان example.com خالی) همیشه رکوردهای دیگری دارد. هر zone باید یک رکورد SOA و رکوردهای NS روی apex خودش داشته باشد، و اکثر دامنه‌ها در آنجا رکوردهای MX برای ایمیل و رکوردهای TXT برای SPF و تایید دامنه هم دارند. یک CNAME روی apex باید همهٔ این‌ها را جایگزین کند، پس استاندارد آن را ممنوع می‌کند، و اکثر providerهای DNS از ذخیره‌کردنش خودداری می‌کنند.

providerهایی که آن را می‌پذیرند یک zone می‌سازند که به شکل‌های غیرقابل‌پیش‌بینی خراب می‌شود: بعضی resolverها CNAME را برمی‌گردانند و رکوردهای MX را گم می‌کنند، پس ایمیل شروع می‌کند به bounce شدن؛ بعضی‌ها رکوردهای MX را برمی‌گردانند و alias را نادیده می‌گیرند. همین است که www جای کلاسیک یک CNAME است و چرا دامنهٔ خالی به پاسخ دیگری نیاز دارد، که در بخش بعد پوشش داده می‌شود.

چرا apex از قبل رکوردهایی دارد که یک CNAME با آن‌ها برخورد می‌کند

example.com.      3600  IN  SOA    ns1.dns-host.example. hostmaster.example.com. ( ... )
example.com.      3600  IN  NS     ns1.dns-host.example.
example.com.      3600  IN  MX     10 mail.example.com.
example.com.      3600  IN  TXT    "v=spf1 include:_spf.mail.example ~all"
; example.com.    3600  IN  CNAME  example.cdn-provider.net.   <- not allowed here
www.example.com.  3600  IN  CNAME  example.cdn-provider.net.   ; fine: www has no other records

ALIAS، ANAME و CNAME flattening

چون کاربران می‌خواهند دامنهٔ خالی را هم روی یک CDN بگذارند، providerهای DNS راه‌حل‌هایی ساختند. اسم‌های متفاوتی دارند، اما همه یک کار می‌کنند: provider alias را به‌جای شما دنبال می‌کند و نتیجه را به‌شکل رکوردهای A و AAAA معمولی روی apex منتشر می‌کند.

شما چیزی شبیه یک CNAME روی example.com تنظیم می‌کنید. وقتی یک query می‌رسد، nameserver provider خودش target را resolve می‌کند، آدرس‌هایی که پیدا می‌کند را می‌گیرد و با آن‌ها پاسخ می‌دهد. از دید دنیای بیرون، apex رکوردهای A و AAAA معمولی دارد، پس SOA، NS، MX و TXT می‌توانند قانونی کنار آن‌ها بنشینند. بعضی providerها به این ALIAS می‌گویند، بعضی ANAME، و بعضی دیگر CNAME flattening. Amazon Route 53 رکوردهای alias مخصوص خودش را دارد که فقط به منابع AWS اشاره می‌کنند. ANAME به‌عنوان یک استاندارد پیشنهاد شد اما هیچ‌وقت تمام نشد، پس هرکدام از این‌ها یک قابلیت provider است، نه یک نوع رکورد که با شما بین providerها جابه‌جا شود.

ارزش دارد این trade-offها را بدانید. آدرس‌ها از جایی که nameserver provider نشسته انتخاب می‌شوند، نه جایی که بازدیدکننده هست، پس یک CDN که بر اساس منطقه متفاوت پاسخ می‌دهد ممکن است یک edge کمتر مناسب بدهد، مگر اینکه provider شبکهٔ بازدیدکننده را هم منتقل کند (EDNS Client Subnet). provider همچنین کنترل می‌کند چند وقت یک‌بار پاسخ را تازه می‌کند، که می‌تواند از TTL خودِ target عقب بیفتد. و وقتی DNS host خود را عوض می‌کنید، این قابلیت همراهتان نمی‌آید.

یک پاسخ استاندارد جدیدتر هم هست: نوع رکورد HTTPS (RFC 9460) یک شکل alias دارد که روی apex مجاز است. پشتیبانی مرورگرها از آن شکل هنوز محدود است، پس آن را یک گزینهٔ آینده در نظر بگیرید، نه راه‌حل امروز.

کاری که یک CNAME انجام نمی‌دهد

CNAME یک redirect نیست. فقط تغییر می‌دهد یک نام به چه آدرس‌هایی resolve می‌شود و هیچ چیز دیگری. نوار آدرس همچنان www.example.com را نشان می‌دهد، و مرورگر همچنان در هر درخواست Host: www.example.com می‌فرستد و در TLS handshake گواهی‌ای معتبر برای www.example.com می‌خواهد.

این دو نتیجه دارد که افراد روی آن می‌لنگند. اول، سروری که پشت target است باید تنظیم شده باشد تا hostname شما را بپذیرد. اشاره‌دادن www به somebody-else.example.net با یک CNAME باعث نمی‌شود سرور آن‌ها سایت شما را سرو کند؛ هر چیزی که برای یک Host ناشناس سرو می‌کند را سرو می‌کند، معمولاً یک صفحهٔ خطا یا یک سایت پیش‌فرض. برای همین CDNها و پلتفرم‌های میزبانی از شما می‌خواهند اول hostname را در پنلشان اضافه کنید و بعد DNS را اشاره دهید.

دوم، گواهی باید نام خود شما را پوشش دهد، نه نام target را. یک گواهی برای example.cdn-provider.net به یک بازدیدکنندهٔ www.example.com کمکی نمی‌کند؛ بدون گواهی‌ای برای نام خودتان، مرورگرها حتی وقتی DNS درست است یک هشدار گواهی نشان می‌دهند.

اگر می‌خواهید بازدیدکنندگان را از یک URL به URL دیگر بفرستید، به‌طوری‌که نوار آدرس تغییر کند، آن یک HTTP redirect است، یک 301 یا 302 که یک وب‌سرور پاسخ می‌دهد. ببینید 301 در برابر 302: ریدایرکت‌ها.

اشتباهات رایج CNAME

یک CNAME روی apex. بالاتر پوشش داده شد: به‌جای تحمیل یک CNAME روی example.com، از گزینه‌های دامنهٔ ریشه که DNS host شما ارائه می‌دهد استفاده کنید.

یک CNAME کنار رکوردهای دیگر. این قانون روی هر نامی اعمال می‌شود، نه فقط apex. اگر www به یک رکورد TXT برای تایید نیاز دارد، یا shop از قبل یک رکورد MX دارد، نمی‌توانید یک CNAME هم آنجا اضافه کنید. اکثر providerها رد می‌کنند؛ آن‌هایی که رد نمی‌کنند شما را با نامی تنها می‌گذارند که از resolveری به resolver دیگر متفاوت پاسخ می‌دهد. رکوردهای تاییدی را، جایی که سرویس اجازه می‌دهد، روی نام خودشان بگذارید.

نقطهٔ پایانی گم‌شده. در یک zone file، نامی بدون نقطهٔ پایانی نسبی است و نام zone به آن اضافه می‌شود. www CNAME example.cdn-provider.net داخل example.com تبدیل می‌شود به example.cdn-provider.net.example.com.، نامی که وجود ندارد. target را با نقطهٔ پایانی‌اش بنویسید. ویرایشگرهای وب DNS فرق دارند: اکثرشان target را بدون نقطه می‌گیرند و خودشان آن را اضافه می‌کنند، و چندتایی آن را می‌خواهند. نتیجه را با dig بررسی کنید، نه با اعتماد به فرم.

یک CNAME به یک آدرس IP. مقدار یک CNAME باید یک hostname باشد. www CNAME 203.0.113.25 یا رد می‌شود یا به‌شکل نامی ذخیره می‌شود که هیچ‌وقت resolve نمی‌شود. یک آدرس باید در یک رکورد A یا AAAA باشد.

زنجیره‌های طولانی. یک CNAME می‌تواند به یک CNAME دیگر اشاره کند، اما هر hop یک جستجوی احتمالی دیگر و یک TTL دیگر است. resolverها بعد از تعداد مشخصی hop دست می‌کشند، و یک loop (a به b، b برگشت به a) کاملاً شکست می‌خورد. مستقیم به نام نهایی‌ای که provider شما می‌دهد اشاره کنید.

MX یا NS که به یک alias اشاره می‌کند. RFC 2181 بخش 10.3 می‌گوید targetهای رکوردهای MX و NS باید آدرس خودشان را داشته باشند، نه CNAME باشند. بعضی سرورهای ایمیل هنوز تحویل می‌دهند، بعضی‌ها نه.

CNAMEهای آویزان. وقتی یک سرویس را لغو می‌کنید اما promo.example.com CNAME old-campaign.platform.example را جا می‌گذارید، هر کسی که بعداً آن نام را روی همان پلتفرم ادعا کند می‌تواند محتوا را روی زیردامنهٔ شما سرو کند. این subdomain takeover است. وقتی سرویس را حذف می‌کنید، CNAME را هم حذف کنید.

نقطهٔ پایانی، درست و غلط (zone file برای example.com)

; wrong: relative target, becomes example.cdn-provider.net.example.com.
www   3600  IN  CNAME  example.cdn-provider.net

; right: fully qualified target
www   3600  IN  CNAME  example.cdn-provider.net.

; wrong: a CNAME plus another record at the same name
shop  3600  IN  CNAME  shops.hosted-store.example.
shop  3600  IN  MX     10 mail.example.com.

چطور یک رکورد CNAME را جستجو کنیم

dig (لینوکس، macOS، ویندوز از طریق WSL) واضح‌ترین ابزار است. dig www.example.com CNAME +short target این alias را چاپ می‌کند. dig www.example.com +noall +answer کل زنجیره تا آدرس‌ها را چاپ می‌کند. dig @1.1.1.1 ... یا dig @8.8.8.8 ... از یک resolver عمومی خاص می‌پرسد، که وقتی به یک پاسخ cache شده شک دارید کمک می‌کند. و dig +trace delegation را از root serverها به پایین طی می‌کند، که نشان می‌دهد nameserverهای authoritative همین الان چه می‌گویند، با دور زدن هر cache.

nslookup همه‌جا موجود است، از جمله ویندوز معمولی: nslookup -type=CNAME www.example.com. در PowerShell ویندوز، Resolve-DnsName www.example.com -Type CNAME پاسخ منظم‌تری می‌دهد.

ابزارهای online lookup از resolverهای خودشان پاسخ می‌دهند، اغلب از چند کشور هم‌زمان. آن‌ها برای یک سوال مشخص مفید هستند: آیا بقیهٔ دنیا همان پاسخی را می‌بینند که شما می‌بینید؟ اگر بعضی موقعیت‌ها target قدیمی را نشان دهند و بقیه جدیدی را، تغییر هنوز در حال propagate شدن است.

وقتی پاسخ غلط به نظر می‌رسد، مستقیم از nameserver authoritative بپرسید. اول آن را با dig NS example.com +short پیدا کنید، بعد با @ از آن query بگیرید. اگر سرور authoritative پاسخ درست دارد و یک resolver عمومی ندارد، شما به یک cache نگاه می‌کنید که هنوز منقضی نشده. اگر سرور authoritative غلط است، خودِ رکورد باید تعمیر شود، در هر DNS hostای که رکوردهای NS به آن اشاره می‌کنند.

# the target of the alias
dig www.example.com CNAME +short

# the full chain, alias to address, from a public resolver
dig @1.1.1.1 www.example.com +noall +answer

# straight from the authoritative nameserver, no cache involved
dig NS example.com +short
dig @ns1.dns-host.example www.example.com CNAME +short

# Windows
nslookup -type=CNAME www.example.com
Resolve-DnsName www.example.com -Type CNAME

TTL و propagation برای یک CNAME

هر رکورد در یک زنجیره برای TTL خودش cache می‌شود. در مثال dig بالا، CNAME یک TTL برابر 3600 ثانیه دارد و رکورد A target آن 60 ثانیه. یک resolver alias را یک ساعت نگه می‌دارد و آدرس را یک دقیقه. این تقسیم دقیقاً همان چیزی است که با یک CDN می‌خواهید: provider می‌تواند آدرس‌هایش را در یک دقیقه عوض کند، درحالی‌که رکورد خودتان تقریباً هیچ‌وقت تغییر نمی‌کند.

این همچنین به شما می‌گوید تغییرات خودتان چقدر زمان می‌برد. اگر www را از یک target به target دیگری دوباره اشاره دهید، resolverهایی که CNAME قدیمی را cache کرده‌اند تا پایان TTL آن استفاده‌اش می‌کنند، پس با یک TTL برابر 3600، تغییر تا یک ساعت بعد از ذخیره کامل می‌شود. یک روز قبل از یک تغییر برنامه‌ریزی‌شده TTL را به 300 کم کنید، تغییر را انجام دهید، بعد دوباره بالا ببرید.

دو چیز بیشتر از TTL رکورد زمان می‌برند. نامی که قبلاً وجود نداشت ممکن است برای زمان negative-caching در رکورد SOA آن zone به‌شکل «وجود ندارد» cache شود؛ اضافه‌کردن CNAME بلافاصله بعد از اینکه کسی آن را جستجو کرده می‌تواند همین‌قدر طول بکشد تا نمایش داده شود. و تغییر nameserverها در registrar شما یک عملیات متفاوت از تغییر یک رکورد است: به TTLای بستگی دارد که registry به delegation می‌دهد، که اغلب یک یا دو روز است. راهنمای DNS propagation را به‌طور کلی پوشش می‌دهد.

اشاره‌دادن یک دامنه به یک CDN با CNAME، در CDN.com.tr

راه‌اندازی معمول CDN، www و زیردامنه‌های دیگر را با یک CNAME به hostname CDN می‌گذارد، و دامنهٔ ریشه را جدا مدیریت می‌کند. در CDN.com.tr یکی از سه روش تحویل را در پنل انتخاب می‌کنید.

Default Endpoint محتوای شما را از یک hostname به‌شکل xyz.cdn.com.tr سرو می‌کند، بدون هیچ کار DNSای. سریع‌ترین راه برای تست است، و بعداً می‌توانید به دامنهٔ خودتان منتقل شوید.

Custom Domain/Subdomain (CNAME) DNS شما را همان‌جا که هست نگه می‌دارد. hostname را در پنل اضافه می‌کنید، مثلاً www.example.com یا assets.example.com، و یک CNAME در DNS host خودتان می‌سازید که آن را به targetای که پنل نشان می‌دهد اشاره می‌دهد، به‌شکل <yourname>.cdn.com.tr. target را دقیقاً، بدون پیشوند اضافه، کپی کنید. دامنهٔ ریشه نمی‌تواند از این روش استفاده کند؛ برای آن پنل یک رکورد A یا Full DNS Transfer ارائه می‌دهد. یک hostname که با CNAME وصل شده گواهی خودش را می‌گیرد، که به‌محض رسیدن درخواست‌ها به edge از طریق HTTP تایید می‌شود. چون hostnameهای CDN کنار رکوردهای A خودشان رکوردهای AAAA هم دارند، یک CNAME به ما همچنین IPv6 را بدون هیچ رکورد اضافه‌ای در سمت شما به این نام می‌دهد.

Full DNS Transfer nameserverهای دامنه را به CDN.com.tr منتقل می‌کند. این پاسخ تمیز به مشکل apex است: پنل به ویرایشگر zone شما تبدیل می‌شود، دامنهٔ ریشه بدون راه‌حل موقت CNAME به edge مسیردهی می‌شود، و ریشه یک گواهی wildcard می‌گیرد که زیردامنه‌هایش را هم پوشش می‌دهد. پنل رکوردهای موجودتان (MX، TXT، زیردامنه‌ها) را قبل از تغییر nameserver اسکن و import می‌کند، و می‌توانید گواهی را از طریق یک رکورد DNS TXT در provider فعلی‌تان قبل از تغییر صادر کنید، پس HTTPS از همان دقیقهٔ اول کار می‌کند.

راهنمای تنظیم DNS برای CDN این تغییر را مرحله‌به‌مرحله توضیح می‌دهد. وقتی CNAME resolve شد، بررسی کنید درخواست‌ها واقعاً از edge می‌گذرند: هدر پاسخ X-Proxy-Cache-MT نشان می‌دهد edge پاسخ را از cache خودش سرو کرده یا نه.

$ dig www.example.com CNAME +short
yourname.cdn.com.tr.

$ curl -sI https://www.example.com/ | grep -i x-proxy-cache-mt
X-Proxy-Cache-MT: HIT