الخلاصة

  • يضع RFC 9432 قائمة النطاقات الأعضاء وبعض خصائصها داخل نطاق DNS عادي، فيستطيع المستهلك إضافة الخدمة الموثوقة أو حذفها أو إعادة تهيئتها تلقائياً. أما بيانات كل نطاق عضو فتصل في نقل مستقل.
  • سلامة بنية الإصدار 2، ومصادقة طرف النقل، وقبول الاسم محلياً، وملكية الفهرس للحالة المراد حذفها، وتنفيذ الخادم العامل للنتيجة المقصودة هي أدلة منفصلة.
  • يحمي المستهلك استقلاله حين يقيد الأعضاء المقبولين خارج نطاق أسرار النقل، ويربط كل حالة بفهرسها ووسمها، ويحتفظ بآخر حالة صالحة عند تلف الفهرس، ويوقف الحذف الجماعي، ويؤرشف ما يمكن استعادته، ويفحص الإجابات الموثوقة من الخارج.

كائن سري يملك أثراً عاماً

ينبغي تقييد الاستعلام عن Catalog Zone، كما يوصي RFC 9432 بحماية نقلها سرياً. السبب واضح: محتواها يكشف النطاقات التي يخدمها المستهلك، وربما المجموعات والخصائص التي تتحكم في معاملتها. تسريب الفهرس يقدم خريطة تشغيلية مفيدة للمهاجم أو المنافس.

لكن حمايته من القراءة لا تجيب عن سؤال التنفيذ. قد يصل الفهرس عبر TLS من الطرف الصحيح، أو يحمل TSIG صالحاً، ثم يحتوي قائمة فارغة بسبب تعطل نظام المخزون عند المنتج. النقل سليم والرسالة لم تُعدّل، إلا أن الاستنتاج «يجب ألا يخدم المستهلك أي نطاق» ما زال خاطئاً.

ينص المعيار على أن المنتج والمستهلك قد يتبعان إدارتين مختلفتين. ليس ضرورياً أن يدخل المنتج إلى أنظمة المستهلك؛ يكفي أن يكون المستهلك قد عيّن ذلك النطاق فهرساً قابلاً للتفسير. عندئذ تتحول سجلات DNS إلى تغييرات في تهيئة الطرف الآخر.

هذه قوة مفيدة، لكنها ليست نتيجة تلقائية للمصادقة. المصادقة تحدد من تكلم. سياسة المستهلك تحدد ما الذي سُمِح له بقوله هنا.

الفهرس لا يحمل محتوى النطاق العضو

تُعرض العضوية بسجلات PTR تحت zones، ولكل عضو وسم فريد يمكن ربط الخصائص به. يحمل سجل TXT واحد قيمة version المتوقعة للإصدار 2. وينتقل الكائن مثل أي نطاق DNS عبر AXFR أو IXFR.

لا توجد سجلات A أو MX أو NS أو DNSSEC الخاصة بالعضو داخل الفهرس. بعد قبول العضو، ينشئ المستهلك تهيئته ثم ينقل محتوى النطاق من خوادمه الأساسية.

لهذا توجد حقيقتان تشغيليتان: حقيقة التهيئة وحقيقة البيانات الموثوقة. يمكن أن ينجح نقل الفهرس ويفشل نقل العضو. قد يحذف عقدةٌ العضو بينما تستمر عقدة أخرى في تقديم نسخة قديمة. وقد يصل NOTIFY للعضو قبل أن يراه المستهلك في الفهرس.

رقم SOA المتطابق للفهرس لا يثبت اتساق الخدمة. يجب أن يمتد الدليل من الاستلام إلى قرار القبول، ثم التهيئة الجارية، ونقل العضو، وتحميله، والإجابة الموثوقة التي يراها العميل.

خمس طبقات للثقة المحدودة

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

الثانية هي مصدر النقل. يقدم TSIG مصادقة معاملات DNS، ويضيف نقل النطاق فوق TLS حماية القناة وسريتها. يثبت ذلك هوية الطرف المهيأ وسلامة الرسالة المرصودة، لا صحة قاعدة العملاء التي ولّدت الرسالة.

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

الرابعة هي ملكية الحالة. لا يحق لفهرس أن يحذف إلا النطاق والحالة اللذين أنشأهما هو ابتداءً. الاسم المتطابق لا يثبت المصدر المتطابق.

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

إذا اختُصرت الطبقات الخمس في مؤشر أخضر واحد، استعارت البنية سلطة النتيجة قبل الوصول إليها.

التالف يتوقف؛ أما الفارغ فقد يمر

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

هذه قاعدة فشل قوية، لكنها تعالج ما لا يمكن تفسيره. الفهرس الفارغ يمكن تفسيره تماماً. قد يحتوي SOA وNS وversion=2 بلا أي خطأ. ربما فقد قارئ المخزون صلاحية الوصول وأعاد صفراً؛ لا يعرف محلل DNS ذلك.

يحذر RFC 9432 من أن برنامجاً يولد فهرساً فارغاً قد يحذف ملايين النطاقات من الخوادم الثانوية خلال ثوانٍ. لذلك يحتاج المستهلك إلى فحص دلالي للفارق: عدد الإضافات والحذف، نسبتها، اللواحق والعملاء المتأثرون، تغير الوسوم، ظهور خصائص خاصة، وتوافق العملية مع نافذة تغيير ومصدر مستقل.

الفهرس الفارغ غير المخطط له لا يُطبق. يوضع التغيير في حجر تشغيلي وتستمر آخر حالة معروفة إلى أن يُثبت المقصود.

سلطة الحذف تتبع المصدر

إذا اختفى عضو من فهرس معين، يمنع RFC 9432 المستهلك من حذف النطاق وحالته ما لم يكن الفهرس نفسه قد هيأه أول مرة. النطاق الذي أُنشئ يدوياً أو عبر فهرس آخر يبقى خارج سلطة الرسالة الجديدة.

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

عندما يتطابق المصدر، قد يشمل الحذف بيانات النطاق ومفاتيح DNSSEC. يذكر المعيار إمكان الأرشفة المؤقتة لتصحيح الخطأ. يجب أن تحدد السياسة ما يُحفظ، ومدة الحفظ، ومن يستطيع الاستعادة، وكيف تُزامن الحالة المستعادة مع المصدر الموثوق الحالي.

الحفظ الدائم للمفاتيح يوسع خطر التسريب؛ والمسح الفوري يجعل خطأ المخزون نهائياً. كما أن إعادة PTR القديم لا تعيد بالضرورة الحالة القديمة: بعد المسح قد ينشئ البرنامج عضواً جديداً بلا السجل والمفاتيح السابقين.

coo ليس اسماً جديداً فقط

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

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

وقد يرى بعض المستهلكين الإضافة الجديدة قبل أن يروا الإزالة القديمة، فيتعاملون معها كتعارض اسم. يترك RFC جزءاً من الاستعادة خارج نطاقه، وقد تحتاج العملية إلى نقل مفروض وتشخيص منفصل لكل مستهلك.

لذلك يجب أن يذكر قرار الانتقال مصير بيانات النطاق، والسجل، والمؤقتات، والمفاتيح، والبيانات الخاصة، لا أن يكتفي بعبارة «انقل النطاق».

المجموعات والامتدادات اتفاقات محلية

لا تحمل قيمة group معنى عالمياً. يتفق المنتج والمستهلك على ربط القيم المعروفة بملفات تهيئة محلية، ويتجاهل المستهلك ما لا يفهمه، ويقرر كيف يتعامل مع قيم متعددة.

الخصائص تحت ext خاصة بالتنفيذ ولا يُتوقع لها توافق عام. يسجل IANA في الإصدار 2 البوادئ zones وversion وcoo وgroup والمساحة الخاصة *.ext. التسجيل ينسق الأسماء، ولا يمنح خاصية خاصة سلطة دولية.

هذا مثال عملي على Minimum Initial Specification: طبقة مشتركة صغيرة وقابلة للتحقق محلياً، ثم قرارات مستقبلية لدى المشاركين. النشر لا يصنع واقعاً. الواقع يظهر عندما يتبنى برنامج عامل القيمة ويتحقق منها وينفذ أثراً يمكن قياسه.

أثر مختلف في BIND وKnot DNS وPowerDNS

توثق BIND إضافة الأعضاء وحذفهم وإعادة تهيئتهم، ودعم الإصدارين 1 و2، وإعادة ضبط الحالة بتغيير الوسم، وcoo. يحد الفاصل الأدنى سرعة التغييرات، لا صلاحيتها الدلالية.

تربط Knot DNS المجموعات بملفات محلية، وتذكر أن العضو الخارج من الفهرس يُمسح فوراً، بما في ذلك ملف النطاق والسجل والمؤقتات ومفاتيح DNSSEC، مع الاستثناء الموثق لملف النطاق. وقد يؤدي تحديث الفهرس إلى إعادة تحميل أوسع للنطاقات.

توثق PowerDNS أدوار المنتج والمستهلك للإصدار 2، وcoo، وقيم مجموعات متعددة، وقيمة فريدة تشير إلى إعادة ضبط الحالة. للنظم الخلفية والخصائص المدعومة حدودها.

عبارة «يدعم RFC 9432» لا تكفي لأسطول مختلط. يجب اختبار فهرس تالف وفارغ، وتعارض اسم، ومجموعة مجهولة، وحذف عضو، وتغيير وسم، وانتقال ناقص، وإعادة تشغيل واستعادة في كل إصدار. أولوية الكود العامل تعني أن الوثيقة تحدد التوقع، لكن السلوك المرصود يثبت الواقع.

سجل للسلطة من الرسالة إلى الإجابة

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

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

يجب أن يجيب السجل بلا تخمين: ماذا نشر المنتج؟ من صادق النقل؟ ماذا قبل المستهلك؟ أي حالة كان الفهرس يملكها؟ ماذا نفذ البرنامج؟ وماذا استطاع المستخدم حله بعد ذلك؟

المصادر