ما هو سجل CNAME؟ كيف تعمل أسماء DNS البديلة، وأين تنكسر

ما هو سجل CNAME

سجل CNAME (سجل الاسم الكنسي) يقول إن اسم DNS واحدًا هو بديل (alias) لاسم آخر. www.example.com CNAME example.net يعني: كل ما تريد معرفته عن www.example.com، اسأل example.net بدلًا منه. الاسم على اليسار هو البديل؛ والاسم على اليمين هو الاسم الكنسي، ويسمى أيضًا الهدف (target).

يحمل CNAME اسم مضيف (hostname)، لا عنوان IP أبدًا. فهو لا يقول أين يعيش الموقع؛ بل يقول أي اسم آخر يعرف ذلك. وهذا هو جوهر فائدته: يستطيع مالك الهدف تغيير عناوينه في أي وقت، وكل بديل يشير إليه يتبعه دون أن يعدّل أحد منطقته (zone) الخاصة.

للسجل أربعة أجزاء كما في أي سجل DNS آخر: الاسم، وTTL، والنوع، والقيمة. في ملف منطقة (zone file) يبدو كالعيّنة أدناه. لاحظ النقطة الختامية بعد الهدف: فهي تُعلِم بأن الاسم كامل، وهذا تفصيل تعود إليه فقرة الأخطاء الشائعة.

سجلات CNAME في كل مكان حين تبحث عنها. www التي تشير إلى اسم مضيف CDN، وshop.example.com التي تشير إلى منصة متجر مُستضافة، وstatus.example.com التي تشير إلى خدمة صفحة حالة، وسجلات التحقق التي تطلبها منك أدوات SaaS غالبًا ما تكون CNAME أيضًا. يغطي دليل DNS أنواع السجلات الأخرى؛ أما هذا الدليل فيبقى عند البديل.

سجلات 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.

كيف يتبع المحلل سجل CNAME

لا تطلب المتصفحات سجل CNAME أبدًا. بل تطلب عنوانًا: سجل A لعناوين IPv4 وسجل AAAA لعناوين IPv6. ويدخل CNAME في اللعبة حين يجده المحلل (resolver) الذي يبحث نيابةً عنها في طريقه.

يسأل المحلل خوادم الأسماء الموثوقة (authoritative nameservers) لـexample.com عن سجل A لـwww.example.com. وبدل عنوان، تجيب بـCNAME: فـwww.example.com بديل لـexample.cdn-provider.net. ثم يبدأ المحلل البحث من جديد عن اسم الهدف، هذه المرة عند خوادم أسماء cdn-provider.net، ويحصل هناك على سجل A. ويُعيد كلا السجلّين إلى المتصفح: CNAME، ثم العنوان.

وحين يكون خادم الأسماء نفسه موثوقًا لكلا الاسمين، فإنه يضع السلسلة كاملة في جواب واحد ويوفّر الرحلة الثانية. وإلا فكل خطوة بحث منفصلة، ولهذا قد يكلف CNAME بضع مللي ثوانٍ على ذاكرة تخزين مؤقتة باردة، ولا شيء حين تُخزَّن الأجوبة مؤقتًا.

وإن طلبت نوع CNAME نفسه، يتوقف المحلل عند البديل ولا يتبعه. وهذا ما تفعله عملية بحث CNAME (CNAME lookup) في معظم الأدوات على الإنترنت: تخبرك إلى أي اسم يشير البديل، لا العنوان الذي يصل إليه في النهاية.

$ 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. وهما نهاية كل عملية بحث: مهما كانت سلسلة البدائل التي يتبعها المحلل، فإنه يتوقف عند سجل A أو AAAA. أما CNAME فيربط اسمًا باسم آخر، ويحتاج دائمًا خطوة إضافية.

استخدم سجل A أو AAAA حين تتحكم أنت بالعنوان ونادرًا ما يتغيّر: خادمك الخاص، أو موازن تحميل (load balancer) بعنوان IP ثابت، أو VPS. فأنت من يصون العنوان، وإن تغيّر وجب عليك تعديل كل سجل يحمله.

استخدم CNAME حين يتحكم طرف آخر بالعنوان: CDN، أو منصة مُستضافة، أو أداة SaaS. فعناوين هذا الطرف قد تتغيّر، أو تختلف حسب المنطقة، أو تأتي من مجموعة عناوين (pool)، ولا ينبغي أن تحتاج لمعرفة ذلك. وقد يجيب CDN بعينه عن اسم المضيف نفسه بعناوين حافة (edge) مختلفة في أماكن مختلفة؛ وCNAME يشير إلى اسم مضيفه يحصل على هذا السلوك مجانًا، أما عنوان IP منسوخ فيجمّد جوابًا واحدًا.

الفرق العملي في السرعة صغير. فـCNAME يضيف عملية بحث واحدة فقط حين لا يكون الهدف مخزَّنًا مؤقتًا، والأهداف الشائعة تكون مخزَّنة في الغالب. أما الفرق في الصيانة فكبير: سجل A مكتوب مباشرة بعنوان IP المزوّد هو السبب الكلاسيكي لاختفاء موقع بعد أشهر، حين يُعيد المزوّد ترقيم عناوينه.

لماذا لا يمكن أن يكون النطاق الجذر CNAME

تأتي القاعدة من مواصفة DNS الأصلية. يقول RFC 1034 في البند 3.6.2 إنه إذا وُجد CNAME عند اسم ما، فلا ينبغي أن توجد بيانات أخرى عند ذلك الاسم، ويؤكد RFC 2181 ذلك. والسبب يكمن في طريقة عمل تحليل الأسماء: فـCNAME يعني "كل ما يخص هذا الاسم يعيش في مكان آخر"، فالمحلل الذي يجده يتوقف عن البحث عن أي شيء آخر عند ذلك الاسم. وسجل ثانٍ بجانبه سيكون مُتجاهَلًا أو متناقضًا. والاستثناء الوحيد هو سجلات DNSSEC التي توقّع CNAME نفسه.

وللنطاق الجذر (apex، أي example.com العاري) دائمًا سجلات أخرى. فكل منطقة يجب أن يكون لها سجل SOA وسجلات NS عند جذرها، ومعظم النطاقات لديها أيضًا سجلات MX للبريد وسجلات TXT لـSPF وتحقق النطاق هناك. وCNAME عند الجذر سيحتاج إلى استبدال كل هذه السجلات، فالمعيار يمنعه، ومعظم مزوّدي DNS يرفضون حفظ واحد.

والمزوّدون الذين يقبلونه ينتجون منطقة تنكسر بطرق غير متوقعة: بعض المحللات تُعيد CNAME وتفقد سجلات MX، فيبدأ البريد بالارتداد؛ وبعضها يُعيد سجلات MX ويتجاهل البديل. ولهذا فإن www هو المكان الكلاسيكي لـCNAME، ولماذا يحتاج النطاق العاري إلى حل مختلف، يغطيه القسم التالي.

لماذا يملك الجذر أصلًا سجلات سيتعارض معها 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

لأن الناس يريدون النطاق العاري أيضًا على CDN، بنى مزوّدو DNS حلولًا بديلة. تحمل أسماء مختلفة، لكنها تفعل الشيء نفسه: يتبع المزوّد البديل نيابةً عنك وينشر النتيجة كسجلات A وAAAA عادية عند الجذر.

تضبط شيئًا يشبه CNAME على example.com. وحين يصل استعلام، يحلّل خادم أسماء المزوّد الهدف بنفسه، ويأخذ العناوين التي يجدها ويجيب بها. وبالنسبة للعالم الخارجي، يملك الجذر سجلات A وAAAA عادية، فيمكن لـSOA وNS وMX وTXT أن تجلس بجانبها بشكل قانوني. يسمي بعض المزوّدين هذا سجل ALIAS، وبعضهم ANAME، وآخرون تسطيح CNAME (CNAME flattening). ولدى Amazon Route 53 سجلات alias خاصة به، تشير فقط إلى موارد AWS. وقد اقتُرح ANAME كمعيار لكنه لم يُنهَ أبدًا، فكل واحدة من هذه الحلول ميزة خاصة بالمزوّد، لا نوع سجل ينتقل معك بين المزوّدين.

وتستحق المقايضات أن تُعرف. تُختار العناوين من موضع خادم أسماء المزوّد، لا من موضع الزائر، فـCDN يجيب بطريقة مختلفة حسب المنطقة قد يُسلِّم حافة (edge) أقل ملاءمة، إلا إذا مرّر المزوّد شبكة الزائر (EDNS Client Subnet). ويتحكم المزوّد أيضًا بمعدل تحديث الجواب، وقد يتأخر عن TTL الهدف. وحين تنقل مستضيفي DNS، لا تنتقل الميزة معك.

وهناك أيضًا حل معياري أحدث: نوع سجل HTTPS (RFC 9460) له شكل بديل مسموح به عند الجذر. ودعم المتصفحات لهذا الشكل محدود حتى الآن، فعامله كخيار مستقبلي، لا كحل اليوم.

ما لا يفعله CNAME

CNAME ليس إعادة توجيه (redirect). فهو يغيّر فقط العناوين التي يُحلَّل إليها الاسم، ولا شيء آخر. يبقى شريط العنوان يُظهر www.example.com، وما زال المتصفح يرسل Host: www.example.com في كل طلب، ويطلب في مصافحة TLS شهادة صالحة لـwww.example.com.

ولهذا نتيجتان يتعثر الناس فيهما. أولًا، يجب ضبط الخادم الذي يقف خلف الهدف ليقبل اسم مضيفك. فإشارة www إلى somebody-else.example.net بـCNAME لا تجعل خادمهم يقدّم موقعك؛ بل يقدّم ما يقدّمه لأي Host مجهول، غالبًا صفحة خطأ أو موقع افتراضي. ولهذا تطلب CDN ومنصات الاستضافة إضافة اسم المضيف في لوحتها أولًا، ثم توجيه DNS ثانيًا.

ثانيًا، يجب أن تغطي الشهادة اسمك، لا اسم الهدف. فشهادة لـexample.cdn-provider.net لا تنفع زائر www.example.com؛ وبلا شهادة لاسمك الخاص، تُظهر المتصفحات تحذير شهادة حتى لو كان DNS صحيحًا.

وإن كان ما تريده إرسال الزوّار من رابط إلى آخر، بحيث يتغيّر شريط العنوان، فذلك إعادة توجيه HTTP، أي 301 أو 302 يجيب به خادم الويب. انظر 301 مقابل 302.

أخطاء CNAME الشائعة

CNAME عند الجذر. مشروح أعلاه: استخدم خيارات النطاق الجذر التي يقدّمها مستضيف DNS لديك بدل إجبار CNAME على example.com.

CNAME بجانب سجلات أخرى. تنطبق القاعدة على كل اسم، لا على الجذر فقط. فإذا احتاج www سجل TXT للتحقق، أو كان لدى shop سجل MX أصلًا، فلا يمكنك إضافة CNAME هناك أيضًا. ترفض معظم المزوّدين ذلك؛ وما لا يرفضه يتركك باسم يجيب بشكل مختلف من محلل إلى آخر. ضع سجلات التحقق على اسم خاص بها حيث تسمح الخدمة بذلك.

غياب النقطة الختامية. في ملف منطقة، الاسم بلا نقطة أخيرة نسبيّ وتُضاف إليه اسم المنطقة. فـwww CNAME example.cdn-provider.net داخل example.com يصبح example.cdn-provider.net.example.com.، اسمًا لا وجود له. اكتب الهدف بنقطته الختامية. محرّرات DNS على الويب تختلف: معظمها يأخذ الهدف بلا نقطة ويضيفها هو نفسه، وقلّة تطلبها. تحقق من النتيجة بـdig بدل الثقة بالنموذج.

CNAME إلى عنوان IP. قيمة CNAME يجب أن تكون اسم مضيف. فـwww CNAME 203.0.113.25 تُرفَض، أو تُحفَظ كاسم لا يُحلَّل أبدًا. مكان العنوان في سجل A أو AAAA.

السلاسل الطويلة. يمكن أن يشير CNAME إلى CNAME آخر، لكن كل خطوة هي عملية بحث محتملة إضافية وTTL إضافي. تتوقف المحللات بعد عدد ثابت من الخطوات، وحلقة (a إلى b، وb تعود إلى a) تفشل تمامًا. أشر مباشرة إلى الاسم النهائي الذي يمنحك مزوّدك.

MX أو NS تشير إلى بديل. يقول RFC 2181 في البند 10.3 إن أهداف سجلات MX وNS يجب أن تملك عناوينها الخاصة، لا أن تكون CNAME. بعض خوادم البريد تُسلِّم رغم ذلك، وبعضها لا.

سجلات CNAME المعلّقة (dangling). حين تُلغي خدمة لكنك تترك promo.example.com CNAME old-campaign.platform.example كما هو، فإن من يستحوذ لاحقًا على ذلك الاسم على المنصة نفسها يستطيع تقديم محتوى على نطاقك الفرعي. وهذا هو الاستحواذ على النطاق الفرعي (subdomain takeover). احذف CNAME حين تحذف الخدمة.

النقطة الختامية، الصحيح والخطأ (ملف منطقة لـ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 (على Linux وmacOS وWindows عبر WSL) هو الأداة الأوضح. dig www.example.com CNAME +short يطبع هدف البديل. dig www.example.com +noall +answer يطبع السلسلة كاملة حتى العناوين. dig @1.1.1.1 ... أو dig @8.8.8.8 ... يسأل محلّلًا عامًا محددًا، وهذا يساعد حين تشك بجواب مخزَّن مؤقتًا. وdig +trace يسير على التفويض من خوادم الجذر نزولًا، وهذا يُظهر ما تقوله خوادم الأسماء الموثوقة الآن فعلًا، متجاوزًا كل ذاكرة تخزين مؤقتة.

nslookup متوفر في كل مكان، حتى على Windows العادي: nslookup -type=CNAME www.example.com. وعلى Windows PowerShell، يمنحك Resolve-DnsName www.example.com -Type CNAME جوابًا أكثر ترتيبًا.

أدوات البحث على الإنترنت تجيب من محلّلاتها الخاصة، غالبًا من عدة دول في آن واحد. وهي مفيدة لسؤال واحد بالذات: هل يرى بقية العالم الجواب نفسه الذي تراه أنت؟ فإن أظهرت بعض المواقع الهدف القديم وأخرى الجديد، فالتغيير ما زال ينتشر.

وحين يبدو الجواب خاطئًا، اسأل خادم الأسماء الموثوق مباشرة. اعثر عليه أولًا بـdig NS example.com +short، ثم استعلمه بـ@. فإن كان لدى الخادم الموثوق الجواب الصحيح ولم يكن لدى محلل عام ذلك، فأنت تنظر إلى ذاكرة تخزين مؤقتة لم تنتهِ صلاحيتها بعد. وإن كان الخادم الموثوق مخطئًا، فالسجل نفسه يحتاج إلى تصحيح، عند أي مستضيف DNS تشير إليه سجلات 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 خاص به. في مثال dig أعلاه، لـCNAME مدة TTL تبلغ 3600 ثانية، ولسجل A الخاص بالهدف 60 ثانية. فيحتفظ المحلل بالبديل لمدة ساعة وبالعنوان لمدة دقيقة. وهذا التقسيم هو بالضبط ما تريده مع CDN: فيستطيع المزوّد تحريك عناوينه خلال دقيقة، بينما سجلك الخاص لا يتغيّر إلا نادرًا.

وهذا يخبرك أيضًا كم يستغرق تطبيق تغييراتك الخاصة. فإن أعدت توجيه www من هدف إلى آخر، تستمر المحللات التي خزّنت CNAME القديم في استخدامه حتى تنتهي صلاحية TTL، فبTTL يبلغ 3600 يكتمل التبديل خلال ساعة من الحفظ. اخفض TTL إلى 300 يومًا قبل تغيير مُخطَّط له، ثم نفّذ التغيير، ثم أعِده إلى ما كان.

وهناك أمران يستغرقان أطول من TTL السجل. فالاسم الذي لم يكن موجودًا من قبل قد يُخزَّن مؤقتًا بصفته "غير موجود" طوال مدة التخزين المؤقت السلبي (negative caching) المحددة في سجل SOA للمنطقة؛ وإضافة CNAME بعد أن بحث عنه أحدهم للتو قد تستغرق تلك المدة للظهور. وتغيير خوادم الأسماء عند مسجّل نطاقك عملية مختلفة عن تغيير سجل: فهي تعتمد على TTL الذي يمنحه السجل (registry) للتفويض، وهو غالبًا يوم أو يومان. يغطي دليل DNS الانتشار (propagation) بشكل عام.

توجيه نطاق إلى CDN بواسطة CNAME، على CDN.com.tr

يضع إعداد CDN المعتاد www والنطاقات الفرعية الأخرى على CNAME إلى اسم مضيف CDN، ويتعامل مع النطاق الجذر بشكل منفصل. على CDN.com.tr تختار إحدى ثلاث طرق تسليم في اللوحة.

نقطة النهاية الافتراضية (Default Endpoint) تقدّم محتواك من اسم مضيف xyz.cdn.com.tr، بلا أي عمل على DNS. وهي أسرع طريقة للاختبار، ويمكنك الانتقال إلى نطاقك الخاص لاحقًا.

نطاق/نطاق فرعي مخصص (CNAME) يُبقي DNS لديك حيث هو. تضيف اسم المضيف في اللوحة، مثل www.example.com أو assets.example.com، وتنشئ CNAME عند مستضيف DNS لديك يشير إلى الهدف الذي تُظهره اللوحة، بصيغة <yourname>.cdn.com.tr. انسخ الهدف بالضبط، دون إضافات. لا يستطيع النطاق الجذر استخدام هذه الطريقة؛ وتقدّم اللوحة له سجل A أو النقل الكامل لـDNS. واسم المضيف المتصل بـCNAME يحصل على شهادته الخاصة، مُتحقَّقة عبر HTTP بمجرد وصول الطلبات إلى الحافة. وبما أن أسماء مضيفي CDN تحمل سجلات AAAA بجانب سجلات A، فإن CNAME يشير إلينا يمنح الاسم أيضًا IPv6، دون سجل إضافي من جانبك.

النقل الكامل لـDNS (Full DNS Transfer) ينقل خوادم أسماء النطاق إلى CDN.com.tr. وهذا هو الحل النظيف لمشكلة الجذر: تصبح اللوحة محرّر منطقتك، ويُوجَّه النطاق الجذر إلى الحافة دون حل بديل عبر CNAME، ويحصل الجذر على شهادة واسعة النطاق (wildcard) تغطي نطاقاته الفرعية. وتفحص اللوحة سجلاتك الحالية (MX، TXT، النطاقات الفرعية) وتستوردها قبل تبديل خوادم الأسماء، ويمكنك إصدار الشهادة عبر سجل TXT في DNS عند مزوّدك الحالي قبل التبديل، لتعمل HTTPS من الدقيقة الأولى.

يشرح دليل ضبط DNS لـCDN خطوات التبديل تفصيليًا. وبعد أن يُحلَّل CNAME، تحقق من أن الطلبات تمر فعلًا عبر الحافة: تُظهر ترويسة الاستجابة X-Proxy-Cache-MT هل قدّمت الحافة الجواب من ذاكرتها المؤقتة.

$ 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