سجل CNAME

📅 آخر تحديث: ٢٥ يوليو ٢٠٢٦
✍️ نُشر في: ٢٥ يوليو ٢٠٢٦
الموسوعة الحرة

سجل CNAME ( اختصارًا لـ C الاسم المتعارف عليه ) هو نوع من سجلات الموارد في نظام أسماء النطاقات (DNS) يربط اسم نطاق (الاسم المستعار) بآخر (الاسم المتعارف عليه). [ 1 ] : §  3.6.2

قد يكون هذا مفيدًا عند تشغيل خدمات متعددة (مثل خادم FTP وخادم ويب ، يعمل كل منهما على منفذ مختلف) من عنوان IP واحد . على سبيل المثال، يمكن استخدام سجلات CNAME لتوجيه ftp.example.com و www.example.com إلى سجل DNS الخاص بـ example.com ، والذي بدوره يحتوي على سجل A يشير إلى عنوان IP. بالتالي، إذا تغير عنوان IP، يكفي تسجيل التغيير في مكان واحد فقط داخل الشبكة: في سجل DNS A الخاص بـ example.com .

يجب أن تشير سجلات CNAME دائمًا إلى اسم نطاق آخر، وليس مباشرة إلى عنوان IP.

تفاصيل

تم تحديد سجلات CNAME لنظام أسماء النطاقات في RFC 1034 [ 1 ] وتم توضيحها في القسم 10 من RFC 2181. [ 2 ]

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

$ORIGIN example.com. […] bar.example.com. 3600 IN CNAME foo.example.com. foo.example.com. 3600 IN A 192.0.2.23

انظر إلى منطقة DNS الموضحة على اليمين: عند إجراء بحث عن سجل A لـ bar.example.com ، سيرى المحلل سجل CNAME ويعيد تشغيل البحث عن foo.example.com ، ويعيد في النهاية 192.0.2.23 .

احتمال حدوث لبس

باستخدام سجل CNAME، يمكن توجيه اسم مثل bar.example.com إلى foo.example.com . ولهذا السبب، قد يُظن خطأً، خلال المحادثات غير الرسمية، أن الجزء الأيسر ( bar.example.com ) من سجل DNS هو سجل CNAME ، وهذا غير صحيح. يخزن سجل CNAME الاسم الرسمي (الحقيقي) للمضيف، مما يجعل الجزء الأيمن هو سجل CNAME الفعلي .

bar.example.com. 3600 IN CNAME foo.example.com.

ذُكر هذا الالتباس تحديدًا في RFC 2181، "توضيحات لمواصفات نظام أسماء النطاقات (DNS)". يُعدّ الاسم الموجود على اليسار اسمًا بديلًا للاسم الموجود على اليمين (جزء RDATA)، وهو ( أو ينبغي أن يكون) اسمًا متعارفًا عليه. [ 2 ] : §  10.1.1 بعبارة أخرى، انظر إلى سجل CNAME الموضح على اليمين. يمكن تفسير ذلك على أنه يشير إلى أن bar.example.com هو اسم بديل للاسم المتعارف عليه foo.example.com . سيطلب العميل bar.example.com وستكون الإجابة foo.example.com .

قيود

  • يجب أن تشير سجلات CNAME دائمًا إلى اسم نطاق آخر، وليس أبدًا إلى عنوان IP.
  • إذا كان سجل CNAME موجودًا في عقدة، فلا ينبغي أن تكون هناك بيانات أخرى؛ وهذا يضمن عدم اختلاف بيانات الاسم المتعارف عليه عن أسماءه المستعارة. [ 1 ] : 15 [ 3 ] ويُستثنى من ذلك حالة استخدام DNSSEC ، حيث يمكن أن توجد سجلات متعلقة بـ DNSSEC مثل RRSIG و NSEC ، إلخ. [ 2 ] : § 10.1 
  • ينبغي تجنب سجلات CNAME التي تشير إلى سجلات CNAME أخرى نظرًا لقلة كفاءتها، ولكنها ليست خطأً. [ 1 ] ومن الممكن، بالتالي، إنشاء حلقات غير قابلة للحل باستخدام سجلات CNAME ، كما في المثال التالي:
    $ORIGIN example.com. […] foo.example.com. 3600 IN CNAME bar.example.com. bar.example.com. 3600 IN CNAME foo.example.com.
  • RFC 1034 يجعل وجود سجل SOA في قمة المنطقة شرطًا إضافيًا، [ 1 ] : § 4.2.1 مما يمثل عائقًا آخر أمام وضع سجل CNAME يظهر في قمة المنطقة.
  • قد تتسبب سجلات CNAME التي يتم خدمتها بواسطة سجلات DNAME في حدوث حلقات تكرارية في المحللات القديمة.
  • يجب ألا تشير سجلات MX و NS مطلقًا إلى اسم مستعار CNAME . [ 2 ] : § 10.3 لذا، على سبيل المثال، يجب ألا تحتوي منطقةعلى بنيات مثل: 
    $ORIGIN example.com. @ 3600 IN SOA ns1.example.com. hostmaster@example.com ( zone-admin.example.com. […] ) @ 2400 IN MX 0 foo.example.com. foo.example.com. 3600 IN CNAME host.example.com. host.example.com. 3600 IN A 192.0.2.1
  • قد لا تحتوي النطاقات المستخدمة في أوامر بروتوكول نقل البريد البسيط (MAIL) وبروتوكول نقل البريد العشوائي (RCPT) على سجل CNAME . [ 4 ] عمليًا، قد ينجح هذا، ولكنه قد يتصرف بشكل مختلف مع خوادم البريد المختلفة، وقد يؤدي إلى آثار غير مرغوب فيها. [ 5 ]

سجل DNAME

يُعرَّف سجل DNAME (اختصارًا لاسم التفويض ) في RFC 6672 [ 6 ] ( مع العلم أن RFC 2672 [ 7 ] السابق أصبح الآن قديمًا). يوفر سجل DNAME إعادة توجيه (اسمًا بديلًا) لشجرة فرعية من شجرة أسماء النطاقات في نظام أسماء النطاقات (DNS). أي أن جميع الأسماء التي تنتهي بلاحقة معينة تُعاد توجيهها إلى جزء آخر من نظام أسماء النطاقات. في المقابل، يُنشئ سجل CNAME اسمًا بديلًا لاسم واحد فقط، وليس لنطاقاته الفرعية. ومثل سجل CNAME ، يستمر بحث DNS بإعادة محاولة البحث باستخدام الاسم الجديد. يقوم خادم الأسماء بإنشاء سجل CNAME لتطبيق سجل DNAME على الاسم المطلوب - حيث يكون لسجلات CNAME لكل عقدة في الشجرة الفرعية نفس تأثير سجل DNAME للشجرة الفرعية بأكملها.

$ORIGIN example.com. […] foo.example.com. 1200 IN DNAME bar.example.com. bar.example.com. 3600 IN A 192.0.2.23 xyzzy.bar.example.com. 3600 IN A 192.0.2.24 *.bar.example.com. 3600 IN A 192.0.2.25

على سبيل المثال، إذا كانت هناك منطقة DNS كما هو موضح على اليمين، فإن البحث عن سجل A لـ foo.example.com لن يعيد أي بيانات لأن DNAME ليس CNAME ، ولا يوجد سجل A محدد للمضيف .foo

ومع ذلك، فإن البحث عن xyzzy. foo .example.com سيتم ربطه بـ DNAME وسيعيد سجل A الخاص بـ xyzzy. bar .example.com ، وهو 192.0.2.24 ؛ إذا كان سجل DNAME سجل CNAME ، فسيعيد هذا الطلب رسالة "الاسم غير موجود".

وأخيرًا، سيتم تعيين DNAME لطلب foobar.foo.example.com وسيعيد 192.0.2.25 .

سجل ANAME

تُطبّق العديد من منصات نظام أسماء النطاقات المُدارة نوع سجل غير قياسي يُعرف باسم ALIAS [ 8 ] أو ANAME [ 9 ] . تُدار هذه السجلات الوهمية من قِبل مسؤولي نظام أسماء النطاقات كما تُدار سجلات CNAME ، ولكن يتم نشرها وحلها بواسطة (بعض) عملاء نظام أسماء النطاقات كما تُحلّل سجلات A. عادةً ما تُهيأ سجلات ANAME للإشارة إلى نطاق آخر، ولكن عند الاستعلام عنها من قِبل عميل، تُجيب بعنوان IP. على الرغم من تقديم أنواع سجلات ANAME للتوحيد القياسي [ 10 ] ، إلا أن هناك تطبيقات أخرى غير متوافقة، لذا يُمكنها القيام بأي شيء يختاره مالك منصة نظام أسماء النطاقات، بما في ذلك وجودها في قمة منطقة النطاق ووجودها للنطاقات التي تستقبل البريد.

تتمثل الميزة الرئيسية لسجلات ANAME مقارنةً بسجلات CNAME في إمكانية استخدامها على مستوى قمة النطاق، بينما لا يتعامل محلل أسماء النطاقات المتوافق مع المعايير مع أسماء النطاقات التي تحتوي على سجلات CNAME على أنها قمة نطاق. [ 11 ] كذلك، بينما يتطلب عميل DNS استعلامين على الأقل لتحويل سجل CNAME إلى سجل A ثم إلى عنوان IP، فإن ANAME يُحيل الاستعلام الثاني وما يليه إلى الخادم. إذا كان خادم DNS قادرًا على تحويل سجل A وتخزين عنوان IP المطلوب مؤقتًا بكفاءة أعلى وبزمن استجابة أقل من عملاء DNS، فسيتمكن عميل DNS من حل الاستعلام بشكل أسرع.

تم تقديم نوع سجل ANAME كمسودة معيارية إلى فريق عمل عمليات نظام أسماء النطاقات (DNSOP) التابع لفرقة عمل هندسة الإنترنت (IETF)، إلا أن آخر مراجعة له انتهت صلاحيتها في يناير 2020، [ 10 ] لعدم حصوله على الإجماع اللازم لاقتراحه. ومنذ ذلك الحين، تم استبداله بسلسلة من المسودات لنوعين جديدين من السجلات، مما أدى إلى اعتماد RFC 9460، بعنوان "ربط الخدمة وتحديد المعلمات عبر نظام أسماء النطاقات ( SVCB) وسجلات موارد HTTPS )، كمعيار مقترح في نوفمبر 2023. [ 12 ]

انظر أيضاً

مراجع

  1. 1 2 3 4 5 موكابيتريس، بول ف. (1 نوفمبر 1987). أسماء النطاقات - المفاهيم والتسهيلات . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC1034 . RFC 1034. مؤرشف من الأصل في 18 أغسطس 2023. تم الاسترجاع في 16 مارس 2019 .
  2. 1 2 3 4 إلز، روبرت وبوش، راندي (1 يوليو 1997). توضيحات لمواصفات نظام أسماء النطاقات (DNS) . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC2181 . RFC 2181. مؤرشف من الأصل في 19 أغسطس 2023. تم الاسترجاع في 30 يونيو 2026 .
  3. ↑ بار، ديفيد (1 فبراير 1996). "سجلات CNAME" . أخطاء تشغيل وتكوين نظام أسماء النطاقات الشائعة . فريق عمل هندسة الإنترنت . القسم 2.4. doi : 10.17487/RFC1912 . RFC 1912. مؤرشف من الأصل في 15 أغسطس 2023. تم الاسترجاع في 4 يوليو 2026 . 
  4. ↑ برادن، روبرت ت. (1 أكتوبر 1989). "التوحيد القياسي" . متطلبات مضيفي الإنترنت - التطبيق والدعم . فريق عمل هندسة الإنترنت . القسم 5.2.2. doi : 10.17487/RFC1123 . المعيار 3. RFC 1123. مؤرشف من الأصل في 6 سبتمبر 2023. تم الاسترجاع في 23 يوليو 2020 . 
  5. ↑ بيرنشتاين، دي جيه (2000). "سجلات CNAME في البريد" . بنية البريد الإلكتروني على الإنترنت . مؤرشف من الأصل في 6 مارس 2016. تم الاسترجاع في 3 يونيو 2011 .
  6. ↑ روز، سكوت وويغاردز، ووتر (18 يونيو 2012). إعادة توجيه DNAME في نظام أسماء النطاقات (DNS) . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC6672 . ISSN 2070-1721 . RFC 6672. مؤرشف من الأصل في 31 أكتوبر 2024. تم الاسترجاع في 30 يونيو 2026 . 
  7. ↑ كروفورد، مات (1 أغسطس 1999). إعادة توجيه اسم DNS غير الطرفي . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC2672 . RFC 2672. مؤرشف من الأصل في 18 أغسطس 2024. تم الاسترجاع في 30 يونيو 2026 .
  8. ↑ "ما هو سجل ALIAS؟" . مساعدة DNSimple . 2013. مؤرشف من الأصل في 7 مايو 2017. تم الاسترجاع في 26 يوليو 2019 .
  9. ↑ "سجلات ANAME" . نظام أسماء النطاقات أصبح سهلاً . 2015. مؤرشف من الأصل في 18 نوفمبر 2025. تم الاسترجاع في 24 سبتمبر 2022 .
  10. 1 2 فينش، توني؛ هانت، إيفان؛ فان دايك، بيتر؛ إيدن، أنتوني؛ وميكينغ، ماتيس (8 يوليو 2019). أسماء مستعارة خاصة بالعناوين في نظام أسماء النطاقات (ANAME) . فريق عمل هندسة الإنترنت . المعرف draft-ietf-dnsop-aname-04 . مؤرشف من الأصل في 3 أكتوبر 2023. تم الاسترجاع في 26 يوليو 2019 .
  11. ↑ غولدلست، سوزان؛ ألموند، كاثي؛ تشولز، غريغ (31 يوليو 2024). "CNAME في قمة النطاق" . قاعدة معارف المصادر المفتوحة التابعة لاتحاد أنظمة الإنترنت . مؤرشفة من الأصل في 14 فبراير 2026. تم الاطلاع عليها في 8 أبريل 2023 .
  12. ↑ شوارتز، بنيامين م.؛ بيشوب، مايك؛ ونيغرين، إريك (6 نوفمبر 2023). ربط الخدمة وتحديد المعلمات عبر نظام أسماء النطاقات (SVCB وسجلات موارد HTTPS) . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC9460 . ISSN 2070-1721 . RFC 9460. مؤرشف من الأصل في 3 ديسمبر 2025. تم الاسترجاع في 30 يونيو 2026 . 

للمزيد من القراءة

  • RFC 2219 – استخدام أسماء مستعارة لنظام أسماء النطاقات لخدمات الشبكة 
  • RFC 6672 – نسخ شجرة فرعية لمنطقة DNS على اسم مضيف ثانٍ 
  • RFC 9460 – زيادة كفاءة اتصال الشبكة عن طريق نشر تفاصيل تكوين الخادم في نظام أسماء النطاقات (DNS)