الخلاصة

  • شرح RFC 5074، الذي كتبه Sam Weiler، تقنية DNSSEC Lookaside Validation (DLV) للتحقق من النطاقات الموقّعة عندما لا ينشر النطاق الأب سجل DS المعتاد.
  • لم تُلغِ DLV الحاجة إلى الثقة: كان على محلّل الأسماء ضبط مرساة مسبقة لنطاق DLV منفصل، ثم استخدام سجلاته الموثّقة كما لو كانت سجلات DS للنطاق المقصود.
  • حذفت ISC مدخلات سجل DLV في 2017 وأبقت منطقة موقّعة فارغة لحماية الإعدادات القديمة. وفي 2020، نقل RFC 8749 التقنية إلى الحالة التاريخية مع اتساع سلسلة التفويض المعتادة وارتفاع كلفة صيانة شيفرة تحقق إضافية.

توقّف مسار التحقق عند النطاق الأب

قد يوقّع النطاق بياناته ولا يملك رغم ذلك طريقاً مكتملاً لإثبات صحتها أمام محلّل الأسماء. في السلسلة المعتادة، ينشر النطاق الأب سجل Delegation Signer (DS) لربط DNSKEY الخاص بالنطاق الفرعي بالبيانات الموقّعة للأب. وإذا كان أحد الأجداد غير موقّع، أو لم يقبل المسجّل سجل DS للنطاق الفرعي، تنقطع سلسلة التحقق. كان ذلك عائقاً عملياً في بدايات نشر DNSSEC، حين لم تكن الجذرية وكثير من نطاقات المستوى الأعلى موقّعة بعد.

أضافت DLV مدخلاً آخر. يتيح RFC 5074 لنطاق DLV موقّع بصورة مستقلة أن ينشر سجلات موثّقة لنطاقات تقع تحته، حتى إن لم تكن أبناء مباشرين له. وبعد التحقق من مجموعة سجلات DLV، يستطيع المحلّل معاملتها معاملة سجل DS ومواصلة فحص DNSKEY والتوقيعات في النطاق المقصود. يحدد RFC 4431 نوع سجل DLV بالرقم 32769؛ وقد شارك Mark Andrews وSam Weiler في كتابة مواصفته. أما Weiler فكتب RFC 5074 الذي يشرح سلوك أداة التحقق والآلية الأوسع.

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

احتاج الإيقاف إلى التعامل مع ما بقي منشوراً

تقول ISC إن سجلها DLV Registry بدأ العمل في 2006 لمساندة انتقالية إلى DNSSEC. ومع توقيع الجذر واتساع التفويضات الموقّعة في نطاقات المستوى الأعلى، تراجعت الحاجة إلى طريق موازٍ. ويسجل RFC 8749، الذي كتبه W. Mekking وDan Mahoney، أن توقيع الجذر اكتمل في يوليو 2010، وأن 1,389 من أصل 1,531 نطاقاً من المستوى الأعلى كانت لديها تفويضات آمنة من الجذر في مايو 2019. وفي 2020 أعاد تصنيف RFC 4431 وRFC 5074 ضمن الحالة التاريخية.

لكن تغيير حالة وثيقة معيارية لا يزيل إعداداً من خادم قديم. حذفت ISC مدخلات DLV في 30 سبتمبر 2017، لكنها أبقت dlv.isc.org منطقة موقّعة فارغة. وذكرت أن إزالة المنطقة بالكامل قد تدفع بعض محلّلات BIND القديمة التي ما زالت مهيأة لـDLV إلى إرجاع SERVFAIL على كثير من استعلامات العملاء. سمحت المنطقة الفارغة لتلك الإعدادات القديمة بالتوقف عن العثور على سجلات DLV صالحة من دون قطع فوري للخدمة في الحالات القديمة التي اختبرتها ISC. وهذا تقرير عن إعدادات محددة رصدتها ISC، وليس حكماً عاماً على كل محلّل أسماء.

يذكر RFC 8749 المكاسب والتكاليف معاً: خففت DLV الضغط على النطاقات الأبوية كي توقّع وعلى المسجّلين كي يقبلوا سجلات DS، لكنها زادت تعقيد شيفرة التحقق. ويشير مؤلفو RFC إلى وجود تطبيقات في BIND 9 وUnbound، وإلى أنهم لم يعرفوا استخداماً في الشركات الخاصة. يصف ذلك ما كان معروفاً لهم عند النشر في 2020، ولا يقدم إحصاءً للوضع في 2026. والاستنتاج الذي تسنده المصادر أضيق: سدّت DLV فجوة حين لم تكتمل السلسلة المعتادة، ثم تطلّب إنهاؤها مراعاة إعدادات بقيت بعد زوال سببها الأول.

تُستخدم المذكرة 64 لـHeng Lu هنا كزاوية تحريرية فحسب: هل بقيت الآلية المشتركة ضمن الحد اللازم، وهل يُقاس التغيير بالتبنّي الفعلي؟ ليست المذكرة دليلاً على سيرة Weiler أو وقائع DNSSEC.

المصادر