الخلاصة

  • أدخل RFC 2672 سجل DNAME عام 1999 ليستبدل لاحقة المالك بلاحقة الهدف عند حل أي اسم تابع. وهكذا أصبحت قاعدة واحدة تمثل مجموعة مفتوحة من الأسماء البديلة.
  • لا يعيد DNAME توجيه اسم مالكه ولا ينشئ تفويضاً. تبقى SOA وNS لازمتين عند قمة المنطقة، ويبقى التفويض ناتجاً عن مجموعة NS تضعها المنطقة الأم عند حدّ المنطقة.
  • حوّل RFC 6672 خبرة التشغيل إلى قيود صريحة: تركيب CNAME لكل سؤال، التحقق من DNAME الموقّع، حجب البيانات التابعة، رفض DNAME ذي البدل، تقييد الحلقات، وإرجاع YXDOMAIN إذا صار الاسم الناتج أطول من المسموح.

ما بين اسم بديل واحد ومنطقة مفوّضة

ميّز تصميم DNS في RFC 1034 بين عمليتين. يعلن CNAME أن اسماً محدداً بديل لاسم قانوني آخر. أما مجموعة NS عند حدّ المنطقة فتدلّ المحلّل على الخوادم ذات السلطة للمنطقة الابنة.

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

إذا انتقلت مؤسسة من old.example إلى new.example، فإن CNAME لـwww لا يغطي mail أو lab.mail أو الأسماء التي ستظهر لاحقاً. أما إعادة تفويض المنطقة القديمة فقد تغيّر صاحب سلطة الإجابة، مع أن المطلوب ربما كان مجرد إبقاء المسارات القديمة صالحة.

احتاج DNS إلى فعل أوسع من بديل منفرد وأضيق معنىً من تسليم منطقة. جاء DNAME لهذه المساحة.

قاعدة واحدة للاّحقة

عرّف RFC 2672 النوع 39 في أغسطس 1999. عندما تنتهي تسمية تابعة باسم مالك DNAME، تُستبدل تلك اللاحقة بالهدف. المطابقة تقع على حدود ملصقات DNS الكاملة.

إذا أشار old.example إلى new.example، يتحول www.lab.old.example إلى www.lab.new.example. تبقى www.lab كما هي. لا تنسخ منطقة المصدر بيانات الهدف ولا تكتسب سلطة عليها.

ربط النص الأصلي الآلية بإعادة ترقيم الشبكات وDNS العكسي وتغيير أسماء المؤسسات. هذه أمثلة تشرح الحاجة التصميمية، وليست قياساً لمدى الانتشار. الفكرة الدائمة هي ضغط الإدارة: سجل واحد يغطي أسماء معروفة ومجهولة ولم تُنشأ بعد.

لكن الضغط يركز الخطر أيضاً. خطأ في سطر واحد يستطيع تغيير وجهة فرع كامل. قلة الأسطر لا تعني ضيق الأثر.

المالك بقي في مكانه

يوضح RFC 6672، الذي حل محل المواصفة الأولى، الاستثناء الحاسم: ينطبق DNAME على الأسماء الأدنى من مالكه، لا على المالك نفسه.

يمكن لـwww.old.example أن ينتقل إلى اللاحقة الجديدة، بينما يبقى السؤال عن old.example عند القمة القديمة. قد توجد هناك أنواع بيانات متوافقة، وتظل SOA وNS واجبتين إذا كان المالك قمة منطقة.

لهذا لا يستطيع DNAME أن يعكس منطقة كاملة. قد يلزم تكرار MX عند القمة القديمة أثناء تغيير اسم المؤسسة. ويجب على خدمة الويب أو الشهادة أو نظام البريد قبول الاسم القديم صراحة. يستطيع DNS الوصول إلى اسم جديد، لكنه لا يفرض على التطبيق اعتبار الهويتين واحدة.

الاستثناء ليس نقصاً؛ إنه تعريف أمين للوعد. الآلية تربط بنية الأسماء التابعة، ولا تعلن تطابق نطاقين أو سلطتين.

CNAME يُصنع عند وصول السؤال

حين يطبق الخادم الاستبدال، يضمّن DNAME ويُركّب CNAME للاسم المطلوب تحديداً. قد يحصل السؤال عن www.lab.old.example على CNAME إلى www.lab.new.example مع أن ذلك السجل لم يُخزّن قط في ملف المنطقة.

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

تغيرت قاعدة مدة الصلاحية بعد خبرة التشغيل. استخدمت المواصفة الأولى TTL صفراً؛ أما RFC 6672 فيمنح CNAME مدة DNAME، مع إلزام المحللات بقبول القيمتين لأن التطبيقات القديمة بقيت عاملة.

وسقطت فكرة إشارة EDNS لفهم DNAME، لأنها لم تُعرّف أصلاً. جاءت قابلية التشغيل البيني من إجابات DNS العادية والسلوك المتوافق، لا من تفاوض غير موجود.

DNSSEC وقّع السبب لا كل نتيجة

لا تعرف المنطقة مسبقاً كل اسم تابع قد يسأل عنه مستخدم، فلا يمكنها توقيع عدد غير محدود من سجلات CNAME. لذلك يُوقّع DNAME.

يتحقق المحلّل من توقيع القاعدة، ويعيد تنفيذ استبدال اللاحقة، ثم يتأكد أن CNAME غير الموقّع هو النتيجة الحتمية نفسها. الدليل هو قاعدة موثقة وحساب قابل للإعادة، لا توقيع مستقل لكل ناتج آني.

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

مع ذلك، صحة القفزة الأولى لا توثق السلسلة كلها. قد يأتي CNAME أو DNAME آخر أو منطقة غير موقعة أو خطأ. يوضح RFC 6604 أن رمز الاستجابة وبتات الحالة تصف النتيجة النهائية للسلسلة. مؤشر أصيل لا يجعل الهدف موجوداً أو موثوقاً تلقائياً.

الإشارة ليست تفويضاً

يسمي RFC 9499 النطاق الفرعي تحت مالك DNAME اسماً بديلاً. أما التفويض فهو إنشاء منطقة منفصلة عندما تضع المنطقة الأم مجموعة NS لأصل الابن عند حدّ منطقة.

تغيّر إحالة NS الخوادم التي ينسب إليها المحلّل سلطة الاسم الأصلي. أما DNAME فيغيّر الاسم الجاري البحث عنه؛ ثم يسلك الاسم الجديد تفويضات مساحة الهدف الموجودة أصلاً.

لذلك لا يجوز لـDNAME وNS الدال على تفويض أن يشتركا في مالك واحد خارج القمة. وإذا استخدمت المنطقة الابنة DNAME عند قمتها، يكون السجل أسفل الحد ضمن بياناتها السلطوية، إلى جانب SOA وNS.

مشغّل المصدر يملك المؤشر. مشغّلا الأم والابن يديران تفويض المصدر. مشغّل الهدف يملك البيانات النهائية. سلاسة الإجابة لا تدمج هذه السلطات الثلاث.

ما تحت القاعدة قد يصبح غير مرئي

لا ينبغي وجود سجلات موارد تحت مالك DNAME في المنطقة نفسها. إذا حمّلها الخادم فإنها تُحجب، لأن البحث يلتقي قاعدة التحويل قبل الوصول إليها.

يمكن لإضافة سطر واحد أن تخفي أسماء عديدة من دون حذف أسطرها. وقد يحتفظ مخبأ تكراري ببيانات تابعة قديمة وDNAME جديد في الوقت نفسه. يسمح RFC 6672 بمعالجة انتقالية، ثم تعتمد استعادة الاتساق على انتهاء TTL القديم.

لذلك يبدأ النشر بجرد الفرع كله. كما أن التراجع يخضع لزمن موزع: حذف السجل من الخادم السلطوي لا يلغي فوراً نسخاً ما زالت صالحة في المخابئ.

DNAME وحيد عند مالكه ولا يتعايش هناك مع CNAME. يمنح البروتوكول قاعدة واحدة نطاقاً واسعاً، لكنه لا يسمح بوجهتين متنافستين في النقطة نفسها.

البدل كان سيصنع قاعدة التحكم نفسها

DNAME العادي قاعدة ثابتة تنتج CNAME محدداً. أما DNAME ذو مالك بدل فيجعل توسع البدل يصنع أولاً مالك القاعدة، ثم تصنع القاعدة المؤقتة إعادة التوجيه.

رأى RFC 4592 في ذلك لا حتمية وخطراً على اتساق المخابئ. لذلك لا يوصي RFC 6672 به، ويجيز للخادم التحذير أو رفض التحديث أو المنطقة.

النتيجة المشتقة من حقيقة سلطوية ثابتة قابلة للتحقق. أما اشتقاق الحقيقة التي تمنح سلطة التحويل نفسها فيشوّش المصدر والنطاق. قدرة DNS على استقبال أسئلة مفتوحة لا تعني وجوب اختراع قواعد تحكم مفتوحة أثناء الإجابة.

الحلقات والطول يحددان الكلفة

يمكن أن تكوّن سجلات DNAME حلقات فيما بينها أو مع CNAME. وقد يعيد الاستبدال الاسم إلى مجال القاعدة نفسها. يجب على الخوادم والمحللات تقييد الموارد، مع السماح بأن تكون بعض السلاسل الصحيحة طويلة.

إذا أنتج الاستبدال اسماً يتجاوز حد DNS، يعيد الخادم YXDOMAIN ويعرض DNAME وتوقيعه إن وُجد. ليس ذلك NXDOMAIN: المشكلة ليست غياب الاسم الأصلي، بل استحالة تمثيل النتيجة المحسوبة.

كما يجب أن تكون أهداف NS وMX وPTR وSRV أسماء مضيفين قانونية، وألا يعتمد إيجاد عناوينها على CNAME أو DNAME. لا ينبغي إخفاء أسماء البنية التي تجعل اكتشاف السلطة والخدمة ممكناً خلف سلسلة اختصارات.

يتحمل مدير المصدر تصميم القاعدة، ويعطي الخادم خطأ دقيقاً، ويمنع المحلّل عملاً بلا حد. بساطة الإعداد ليست ترخيصاً لتوزيع كلفة غير محدودة على الآخرين.

الوصول التقني ليس إثباتاً لاستمرار المؤسسة

يحافظ DNAME على علاقة تركيبية ومسار استعلام أثناء الانتقال. لا يحافظ وحده على الملكية أو العقد أو المفاتيح أو الشهادات أو التوافر أو قبول التطبيق.

ينبغي أن تسجل عملية موثوقة من يستطيع تغيير قاعدة المصدر، ومن يدير بيانات الهدف، ومن يضمن قبول الاسمين في الخدمة. كلما بدت إجابة DNS سلسة، زادت ضرورة عدم استنتاج تلك العلاقات من الحزمة وحدها.

استطاع DNAME نقل البحث عبر شجرة الأسماء، ولم يستطع نقل السلطة التي تنظم الشجرة. هذا العجز هو ما جعل إعادة توجيه فرع كامل قابلة للمراجعة والثقة.

المصادر وحدود الأدلة

بنية CNAME والمناطق والتفويض الأصلية في RFC 1034: https://www.rfc-editor.org/rfc/rfc1034.html

المواصفة الأولى لـDNAME في RFC 2672: https://www.rfc-editor.org/rfc/rfc2672.html

مشكلة DNAME ذي البدل في RFC 4592: https://www.rfc-editor.org/rfc/rfc4592.html

الحالة النهائية لسلاسل التحويل في RFC 6604: https://www.rfc-editor.org/rfc/rfc6604.html

قواعد الاستبدال والتركيب وDNSSEC الحالية في RFC 6672: https://www.rfc-editor.org/rfc/rfc6672.html

تعريفات الاسم البديل والتفويض الحالية في RFC 9499: https://www.rfc-editor.org/rfc/rfc9499.html

لا تقدم هذه المصادر نسبة استخدام عالمية حالية أو منفعة تشغيلية عامة. إعادة الترقيم وتغيير المؤسسة أمثلة تصميم. نجاح DNAME لا يثبت وحدة المالك أو قبول التطبيق أو صلاحية الشهادة أو انتقال السلطة.