CNAME أم سجل A: أيّهما تستخدم وقاعدة الجذر

ما يفعله سجل A وسجل CNAME فعلًا

يجيب السجلان على السؤال نفسه – إلى أين يشير هذا الاسم؟ – لكنهما يجيبان بنوعين مختلفين من المعلومات، وهذا الفارق الوحيد يفسّر كل القواعد التالية.

سجل A يربط اسمًا مباشرةً بعنوان IPv4. example.com → 203.0.113.10. هنا تنتهي السلسلة: صار عند المحلّل ما يحتاجه فتوقّف. (المقابل في IPv6 هو سجل AAAA، وكل ما في هذا الدليل ينطبق عليه بالمثل.)

سجل CNAME يربط اسمًا باسم آخر. www.example.com → example.com، أو shop.example.com → myshop.myprovider.net. لا يحصل المحلّل على عنوان، بل على اسم ثانٍ عليه أن يستعلم عنه الآن. CNAME اختصار لـ«الاسم المعياري»، وأفضل قراءة للسجل أنه جملة: الاسم الحقيقي لهذا هناك، فاسأل عنه بدلًا من ذلك.

هذه الإحالة هي كل المقصود. فإذا غيّر ما تشير إليه عنوان IP يومًا، يستمر CNAME في العمل دون أن تلمس شيئًا، لأنك لم تكتب العنوان قطّ.

الفارق الذي يهم فعلًا

عمليًا يتلخّص الاختيار في سؤال واحد: لمن العنوان؟

• لك – خادم أو VPS أو موازن تحميل بعنوان ثابت تتحكم فيه. استخدم سجل A. العنوان معروف لك، ولن يتغيّر دون علمك، والجواب المباشر هو الأسرع.
• لغيرك – منصة استضافة، أو CDN، أو منشئ متاجر، أو خدمة نماذج أو صفحة حالة. استخدم CNAME. فعناوينهم تتغيّر، غالبًا بصمت ودون إشعار، وCNAME يجعل تغييرهم لا يكون انقطاعك.

لهذا تطلب منك صفحة الإعداد في أي منصة إنشاء CNAME بدلًا من إعطائك عنوان IP. ليس هذا تقليدًا، بل احتفاظهم بحق الانتقال. ثبّت عنوانهم الحالي في سجل A وتكون قد خرجت بصمت من نافذة صيانتهم.

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

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

الجذر – ويسمّى أيضًا جذر المنطقة أو النطاق المجرّد – هو example.com دون شيء قبله. وهو الاسم الوحيد في منطقتك الذي لا يمكن أن يكون CNAME. وليس هذا قيدًا ابتكره مزوّدك، بل ينتج عن القاعدة أعلاه.

يحمل جذرك بالفعل سجلات يجب أن توجد ليعمل النطاق أصلًا: سجلات NS التي تسمّي خوادم أسمائك الموثوقة، وسجل SOA الذي يصف المنطقة. وهي تقيم على الجذر بحكم التعريف. وبما أن CNAME يمنع أي سجل آخر على الاسم نفسه، والجذر ملزم بحمل NS و SOA، فإن CNAME على الجذر تناقض. وخادم DNS الملتزم بالمعيار لن يقدّمه.

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

ما تضعه على الجذر بدلًا من ذلك

هناك أربعة حلول عملية، مرتّبة تقريبًا بحسب ما ينبغي تفضيله.

استخدم سجل alias الخاص بمزوّدك

يوفّر معظم مزوّدي DNS الحديثين نوع سجل يتصرّف كـCNAME لكنه مسموح على الجذر: ALIAS، أو ANAME، أو تسطيح CNAME لدى Cloudflare. الأسماء تختلف والآلية واحدة: يحلّ خادم الأسماء الهدف بنفسه ويجيب على الاستعلام بسجل A الناتج. يرى العالم الخارجي سجل A عاديًا تمامًا، فلا تُخرق أي قاعدة، وأنت مع ذلك لم تكتب عنوان IP.

وهذا هو الجواب الصحيح كلما أتاحه مزوّدك. والمأزق أنها ميزة لدى المزوّد لا في DNS نفسه: انقل منطقتك إلى مكان لا يدعمها ولن يرافقك السجل.

أعد توجيه الجذر إلى www

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

المقايضة شكلية: سيظهر www. في رابطك المرئي، ولبعض الناس رأي حاسم في ذلك.

استخدم سجل A، لكن بوعي

إذا نشرت المنصة عنوان IP ثابتًا وتعهّدت به كتابةً، فسجل A على الجذر مقبول. والكلمة الفاعلة هي «تعهّدت». فعنوان وجدته عبر اختبار هدف CNAME لديهم ليس تعهّدًا، بل لقطة لحظة، وسيتغيّر.

وإذا فعلت ذلك، فخفّض مدة TTL للسجل قبل أي ترحيل مخطط له، حتى لا تنتظر ذاكرات التخزين يوم يتغيّر العنوان فعلًا.

تحقّق مما لديك فعلًا

قبل تغيير أي شيء، انظر إلى الحالة الفعلية للمنطقة بدلًا من الوثوق بملخّص لوحة التحكم. استعلم عن الجذر وعن اسم www كلًّ على حدة وقارن: أنت تبحث عمّا إذا كان كل منهما يجيب بسجل A أم بـCNAME، وعمّا إذا كان هناك شيء غير متوقّع أصلًا. تُظهر أداة البحث في DNS المجانية نوع السجل وقيمته ومدة TTL المتبقية لكل منهما.

متى يكون CNAME هو الخيار الصحيح

استخدم CNAME كلما كان الهدف اسمًا لا تتحكم فيه:

• نطاقات فرعية تشير إلى منصة – shop أو docs أو status أو blog أو help نحو خدمة مستضافة. وهذا أكثر استخدام صحيح شيوعًا.
• شبكة CDN أمام مصدرك، حين تعطيك الشبكة اسم مضيف مثل d1234.cloudfront.net.
• سجلات التوثيق والخدمة التي يطلب منك مزوّد إنشاءها بـCNAME، غالبًا بعنوان طويل عشوائي.
• إبقاء www متوافقًا مع الجذر، ليحدّث تغيير واحد كليهما.

والفائدة واحدة في الحالات الأربع: يمكن للمزوّد تغيير بنيته التحتية ويستمر DNS لديك في العمل من دون أن يُمس.

متى يكون سجل A هو الخيار الصحيح

سجل A صحيح حين يكون العنوان ملكك:

• خادمك أو VPS الخاص بك بعنوان ثابت.
• الجذر، حين لا يتوفّر سجل alias وتنشر المنصة عنوانًا مستقرًا.
• موازن تحميل يعطيك مزوّدك عنوانه لا اسم مضيفه.
• مضيفو البنية التحتية – فخادم بريد مذكور في سجل MX، مثلًا، يجب أن يُحلّ عبر A أو AAAA. ولا يُسمح لسجل MX بالإشارة إلى CNAME، وخوادم البريد ترفض ذلك.

وهذه الأخيرة تربك من يرحّل بريده. فـmail.example.com كسجل CNAME يبدو بريئًا، ويعطّل التسليم بطرق مرهقة التشخيص.

الاستعلام الإضافي والمدة الثانية

يكلّف CNAME خطوة إضافية. يسأل المحلّل عن اسمك، فيُقال له «اسأل عن هذا الاسم الآخر»، فيسأل مرة أخرى. وعمليًا هذه الرحلة الزائدة بضعة أجزاء من الألف من الثانية، وتُخدم من الذاكرة في الغالب، فليست سببًا لتجنّب CNAME – لكن نتيجتين تستحقان المعرفة.

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

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

أخطاء شائعة

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

الخلاصة

استخدم سجل A حين يكون عنوان IP ملكك، واستخدم CNAME حين تشير إلى اسم مضيف يملكه غيرك وتريد أن تبقى تغييرات بنيته التحتية غير مرئية لك. ولا يمكن أن يكون جذرك CNAME، لأنه يجب أن يحمل سجلي NS وSOA وCNAME لا يقبل رفيقًا على الاسم نفسه – فاستخدم هناك ALIAS أو ANAME أو تسطيح CNAME لدى مزوّدك، أو أعد توجيه الجذر إلى www، أو استخدم سجل A فقط حين تنشر المنصة عنوانًا مستقرًا. اطّلع على ما يحلّ إليه نطاق اليوم، بنوع السجل والمدة المتبقية، عبر أداة البحث في DNS المجانية، وتأكّد من شهادة المضيف الجديد عبر أداة فحص شهادة SSL.

أدوات وأدلة ذات صلة:

• بحث DNS — استعلم عن سجلات A وAAAA وMX وTXT وNS والمزيد بالقيم وTTL، بالإضافة إلى DNS العكسي.
• فاحص شهادات SSL — افحص شهادة SSL لأي نطاق: الجهة المُصدِرة وتاريخ الانتهاء والأيام المتبقية.
• لماذا تتأخر تغييرات DNS: مدة TTL والانتشار — تغيير DNS ليس بطيئًا، بل مُخزَّن مؤقتًا

أسئلة شائعة