الخلاصة

  • ألحق RFC 2065 دليل التصديق بسجلات موارد DNS، بحيث يحكم المحلّل على البيانات الموقّعة من دون اعتبار كل خادم في مسار التسليم سلطة أمنية موثوقة.
  • أمكن للخادم العادي حفظ سجلات KEY وSIG وNXT وإعادتها، لكن إرفاق التواقيع تلقائياً ومعالجة CNAME والتفويض ومعاني AD وCD احتاجت إلى قدرات إضافية.
  • حمى التصميم منشأ البيانات العامة وسلامتها، ولم يحم سرية السؤال أو يميز حقوق السائلين أو يثبت هوية المضيف الذي يصل إليه التطبيق بعد حل الاسم.

لنتخيل أن محلّلاً طلب عنواناً فتسلّم الجواب من خادم تخزين مؤقت لا يستطيع فحص التوقيع. قد يوحي موقع الخادم في سلسلة التسليم بأنه سبب الثقة بالجواب. قدّم RFC 2065 ترتيباً أدق: يحمل الخادم الجواب ودليله المشفّر، ويقرر المحلّل الواعي بالأمن إن كانت السجلات أصلية وما زالت صالحة زمنياً.

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

ثلاث خدمات لا هالة أمنية واحدة

فصل RFC 2065 بين توزيع المفاتيح العامة، وتصديق منشأ البيانات وسلامتها، والتصديق الاختياري للمعاملة أو الطلب. نجاح تبادل DNS واحد لا يثبت اكتمال هذه الخدمات جميعاً.

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

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

عالج NXT سؤالاً آخر: إثبات أن اسماً غير موجود، أو أن نوعاً معيناً لا يوجد تحت اسم قائم. تغيرت الآلية في الأجيال اللاحقة من DNSSEC، لكن المبدأ كان واضحاً سنة 1997: البيانات الإيجابية وإثبات الغياب يحتاجان إلى دليلين مختلفين. الصمت ليس نفياً موقّعاً.

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

الخادم العادي ناقل مفيد، لا حكم خفي

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

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

لكن التوافق لم يكن شفافاً دائماً. كانت معالجة CNAME استثناء مسمى، لأن سلوك الخادم القديم قد يتبع الاسم المستعار قبل أن يعيد سجلات الأمن عند الاسم الأصلي. لذلك عرّف RFC امتثالاً أدنى وامتثالاً كاملاً للخادم. الأدنى يعني حفظ KEY وSIG وNXT واسترجاعها ونقلها مع المنطقة. أما الكامل فأضاف بناء الأجوبة الصحيح، والإرفاق التلقائي، ومعالجة الأسماء المستعارة ونقاط التفويض، والبِتَّين AD وCD.

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

للذاكرة المؤقتة والتوقيع ساعتان مختلفتان

ينخفض TTL في ذاكرة DNS بمرور الوقت، بينما يفسد تغيير قيمة موقّعة توقيعها. عالج RFC 2065 التوتر بتوقيع TTL الأصلي، مع حمل وقت بدء التوقيع وانتهائه. يستطيع المحلّل إنقاص TTL التشغيلي، لكنه لا يمدده فوق الأصل الموقّع، ولا يعتبر توقيعاً منتهياً دليلاً لمجرد بقاء السجل في الذاكرة.

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

الموثوقية العامة لا تعني السرية أو الإذن

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

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

مواصفة أولى لا DNSSEC النهائي

كان RFC 2065 من فئة Proposed Standard، وليس دليلاً على انتشار شامل. يحفظ IETF Datatracker مراجعات المسودة من 1994 إلى 1996 ونشر يناير 1997، لكنه لا يثبت عدد المشغلين الذين طبقوه. حل RFC 2535 محله في مارس 1999، وقال صراحة إن المراجعة أدخلت خبرة التنفيذ المبكر وطلبات المستخدمين المحتملين. ثم حلت RFC 4033 و4034 و4035 محل ذلك الجيل سنة 2005.

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

ومن منظور Lu Heng اللاحق حول «المواصفة الابتدائية الدنيا»، يمكن قراءة RFC 2065 بوصفه تركيزاً للحد الأدنى المشترك في كائنات قابلة للفحص محلياً، مع السماح بتبنٍّ متفاوت عند الأطراف. هذه قراءة تحريرية لاحقة، وليست دليلاً على نية Eastlake وKaufman التاريخية. فائدتها عملية: يمكن للطبقة المشتركة أن تنشر قواعد صحة دقيقة من دون أن تخوّل كل ناقل أن يقرر ما يجب على الجميع تصديقه.

المصادر