الخلاصة

  • يجعل CNAME اسم المالك alias إلى هدف واحد. ولكي لا يقدم الاسم والهدف حقيقتين متعارضتين، لا يجوز للمالك أن يحمل في الوقت نفسه سجلات عادية مثل A وMX وTXT وNS.
  • يخزن resolver سجل CNAME ثم يبدأ البحث من الهدف. تتحكم المنطقة المصدر في التحويل، بينما تتحكم authority الخاصة بالهدف في البيانات النهائية؛ ولا يشكل ذلك delegation أو دليلاً على الهوية.

اسمان وظيفيان داخل عقدة واحدة كانا سيصنعان تناقضاً

لنفترض أن portal.example هو CNAME يشير إلى service.example.net. عندما يطلب العميل عنواناً، يعيد خادم المصدر سجل alias ثم يبحث resolver عن A أو AAAA عند الهدف. ماذا لو نشرت المنطقة المصدر أيضاً سجل A خاصاً بـportal.example؟ أي عنوان ينبغي للذاكرة المؤقتة أن تصدق: العنوان المباشر للاسم القديم أم العنوان الذي يظهر بعد اتباع التحويل؟

لم يترك RFC 1034، الصادر في نوفمبر/تشرين الثاني 1987، هذا التعارض لاختيار كل implementation. مالك CNAME هو alias، والاسم الموجود في RDATA هو canonical target. وإذا وجد CNAME عند عقدة فلا ينبغي أن توجد فيها بيانات عادية أخرى.

لم تكن القاعدة مجرد تنسيق أنيق لملف zone. فهي تمنع اختلاف بيانات canonical name عن بيانات alias. كما تتيح لـresolver استخدام CNAME مخزن من دون الرجوع إلى authoritative server كي يسأل إن كان نوع آخر عند المالك نفسه ينقض التحويل.

صنعت الحصرية سلطة ضيقة: لا يقرر CNAME العنوان أو mail exchanger أو الخدمة، بل يقرر أين يستأنف السؤال.

الإجابة كانت تغيّر السؤال التالي

CNAME ليس اسماً بديلاً يعود كنص ساكن. عندما لا يكون QTYPE هو CNAME، تطلب خوارزمية RFC 1034 وضع السجل في Answer، وتغيير QNAME العامل إلى الهدف، ثم بدء البحث من جديد. أما سؤال CNAME نفسه فلا يتبع التحويل، لأن المطلوب هو فحصه.

يميّز RFC 9499 بين original QNAME المرسل فعلاً، وeffective QNAME في كل مرحلة من chain، وfinal QNAME في نهايتها. لذلك قد تكرر الاستجابة السؤال الأصلي بينما يكون owner للـRRset النهائي اسماً آخر.

يمنع هذا التمييز توسيع النفي. قد يكون alias موجوداً وقد أجابت سلطته عنه بصورة صحيحة، فيما يكون الهدف غير موجود أو متعطلاً أو تابعاً لمنطقة أخرى. لا يثبت NXDOMAIN في النهاية أن alias الأصلي لم يوجد.

التحويل لم يكن تفويضاً

يدفع alias وdelegation resolver إلى متابعة الطريق، لكنهما ينقلان أشياء مختلفة. يحدد RRset من نوع NS عند zone cut الخوادم صاحبة السلطة على المنطقة الفرعية. أما CNAME فيظل بياناً نشرته سلطة المصدر عن اسمها. يبدأ بحثاً آخر ولا يسلم المنطقة المصدر إلى مشغل الهدف.

يستطيع مدير المصدر إنشاء portal.example أو تغييره أو حذفه، ويحدد TTL الخاص به. وتتحكم authority لـservice.example.net في A وAAAA وسائر البيانات النهائية وTTL الخاصة بها. الإشارة إلى الهدف لا تمنح المصدر حق تعديله، كما لا تمنح الهدف حق تعديل alias.

وضح RFC 6604 لاحقاً حالات CNAME وDNAME chains. يمكن أن تكون الخطوة الأولى authoritative، ثم تحمل الاستجابة referral أو failure من مرحلة تالية. سلطة العبارة الأولى ليست ضماناً لكل الرحلة.

هدف واحد لكل alias لا يعني اسماً واحداً لكل جهاز

أغرت كلمة “canonical” بقراءة أوسع: كأن لكل host أو interface اسماً رسمياً واحداً. رفض RFC 2181 هذا الاستنتاج. لا يفرض DNS هوية اسمية وحيدة على الجهاز.

القاعدة أدق: لكل owner من نوع CNAME هدف canonical واحد. كما أن تسمية المالك نفسه “CNAME” تخفي الاتجاه؛ المالك هو alias، وقيمة السجل هي canonical name في هذه العلاقة.

يمكن لأسماء متعددة أن تقود إلى خدمة واحدة. ويمكن لاسم ليس alias أن يحمل أنواعاً عدة من RRsets. المحظور هو أن يقول المالك “تابع السؤال في مكان آخر” ويقدم نفسه في اللحظة ذاتها كوجهة مستقلة.

لماذا لم يستطع zone apex استعمال الاختصار

يجب أن يحمل apex سجلات SOA وNS. وبما أن CNAME لا يتعايش مع تلك البيانات العادية، فلا يمكن أن يكون apex سجل CNAME عادي. وثق RFC 1912 الخطر في مثال تاريخي من BIND: وضع CNAME بجانب NS عند apex قد يدفع الخادم إلى تجاهل الموارد الأخرى، فتختفي حتى الأسماء الواقعة تحت المنطقة.

تفاصيل السلوك تخص implementations تلك الفترة، أما التعارض فيخص نموذج البيانات. قد تولد خدمة حديثة إجابات address عند apex أو تقدم flattening. يمكن أن يكون ذلك منتجاً مفيداً، لكنه ليس CNAME RR عادياً على السلك. الخلط بينهما يمحو حدود authority وcache المطلوبة وقت العطل.

لا يجوز لـNS وMX إخفاء العنوان التالي خلف alias

يمنع RFC 2181 كذلك أن يكون target لـNS أو exchange لـMX اسماً مستعاراً. يمكن لاستجابات NS وMX أن تضيف العناوين في Additional لتجنب أسئلة متوقعة. هذه المعالجة لا تتبع CNAME أولاً ثم تضيف عناوين canonical target.

لذلك يضيف alias في تلك المواقع استعلامات وحملاً؛ وفي حالات delegation الصعبة قد يؤدي غياب العنوان إلى فشل resolution. ينبغي للمدير أن يحل alias مرة واحدة وينشر مباشرة الاسم الذي يملك address RRsets.

ليست القاعدة حظراً عاماً على إحالة اسم إلى اسم، بل حماية لمواضع يعتمد فيها المسار التشغيلي على اكتشاف عنوان متوقع.

أضاف DNSSEC الدليل ولم يعد الاسم وجهة ثانية

حصلت عبارة “لا بيانات أخرى” على استثناء ضروري مع تطور DNSSEC. سمح RFC 2181 بسجلات الأمان في زمنه، ثم أوجب RFC 4034 وجود RRSIG وNSEC عند CNAME owner في signed zone.

لا تنافس هذه السجلات الهدف. يصادق RRSIG على CNAME RRset، ويسهم NSEC في authenticated denial ودليل الأنواع. إنها تثبت حالة عقدة alias من دون أن تمنحها عنواناً أو مسار بريد أو محتوى تطبيق خاصاً بها.

ويحد RFC 4033 النتيجة الأمنية: يوفر DNSSEC data-origin authentication وintegrity وauthenticated denial عند نجاح validation. لكنه لا يثبت صحة خدمة الهدف، أو هوية شركة، أو عقداً، أو الملكية القانونية للاسم المصدر.

السلسلة مقبولة، أما الحلقة فيجب إيقافها

يمكن لـalias أن يشير إلى alias آخر. ينصح RFC 1034 بتجنب المستويات الكثيرة لضعف الكفاءة، لكنه لا يجعل chain محدودة خطأ. يجب على resolver اكتشاف loops والأهداف النهائية غير الموجودة.

إذن موضوع التشغيل graph لا استبدال نصي. لكل edge owner وauthority وTTL وربما DNSSEC state، وللـterminal RRset عمر آخر. قد تعرض ذاكرتان مؤقتتان مرحلتين مختلفتين من migration واحدة لأن الحواف القديمة لا تنتهي معاً.

لهذا الفصل قيمة. ينقل المصدر اسماً مألوفاً من دون نسخ البيانات النهائية، ويغير الهدف العناوين من دون تعديل كل zone تشير إليه. والثمن أن الطرفين يتغيران بصورة مستقلة بينما تحفظ caches أقوالهما القديمة إلى نهاية TTL.

نجح التنسيق الأدنى لأنه رفض حقيقتين مختلطتين

حل CNAME مشكلة صيانة موزعة بآلية رقيقة عمداً. لم يحتج إلى registry عالمي للأسماء المتكافئة أو حكم مركزي يقرر أي عنوان “ينتمي فعلاً” إلى alias. احتاج فقط إلى edge واحدة غير ملتبسة يستطيع كل resolver تخزينها واتباعها.

الحصرية هي قلب التصميم. يمكن للاسم المصدر أن يكون مساراً أو وجهة، لا الاثنين. حين يختار المسار تبقى سلطته حقيقية ومحدودة: ينشر هدفاً واحداً، ويحفظ evidence الخاصة بالسلسلة، ويترك البيانات النهائية للسلطة التي تسيطر عليها.

المصادر وحدود الدليل

يأتي النموذج والخوارزمية من RFC 1034 وRFC 1035، والأخطاء التشغيلية والتوضيحات من RFC 1912 وRFC 2181، واستثناءات DNSSEC من RFC 4033 وRFC 4034، وحالات chain والمصطلحات من RFC 6604 وRFC 9499. لا تثبت هذه النصوص نسب الانتشار الحالية، أو flattening خاصاً بمزود، أو حدود chain المعاصرة، أو انتشار alias المهجور، أو ملكية application، أو توفر خدمة قائمة.