الخلاصة

  • لا ينشأ ExtSupportLifetime غير الصفري إلا بعد التحقق من سلسلة TLSA ومطابقتها لسلسلة شهادة الخادم ونجاح مصادقة DANE للاسم والمنفذ. يحدد TTL صلاحية السجل الحالي، بينما يحدد الدبوس مدة استمرار توفير الدليل.
  • يمحو الدبوسَ نفيٌ موثق لوجود TLSA، أو إثبات تفويض غير آمن، أو انتقال متحقق إلى مدة صفرية. أما غياب الامتداد مع بقاء الدبوس فليس نفياً، وقد يفرض إنهاء الاتصال.

خدمة DNS التي تحتاج إلى إثبات قبل استخدامها

يحتاج عميل DNS over TLS إلى سجل TLSA وسلسلة DNSSEC كي يصادق محلّل DNS بواسطة DANE. غير أن المسار الطبيعي لجلب تلك السلسلة يمر عبر خدمة DNS نفسها التي لم تُصادَق بعد. يقترح RFC 9102 امتداداً تجريبياً اسمه dnssec_chain: يضع الخادم داخل مصافحة TLS مجموعة السجلات والتواقيع اللازمة للتحقق من TLSA انطلاقاً من trust anchor معدّ مسبقاً لدى العميل.

يحمل الرد شيئين مختلفين. السلسلة تجيب عن الحالة الحالية للاسم الوارد في SNI والمنفذ المطلوب. أما ExtSupportLifetime، وهو عدد من الساعات، فيعلن المدة التي يتعهد فيها الخادم أو العنقود الذي يخدم الاسم نفسه بالاستمرار في دعم الامتداد. وجودهما في رسالة واحدة لا يوحّد ساعتيهما.

شارك Shumon Huque في تأليف RFC 9102 مع Viktor Dukhovni وWillem Toorop وPaul Wouters وMelinda Shore، وينسب النص الفكرة الأصلية إلى Adam Langley. يصف ملفه في IETF وسيرته المنشورة عمله في بنية DNS والشبكات وبروتوكولات الأمن، حالياً في Salesforce وبعد خبرة في Verisign وجامعة بنسلفانيا. يثبت ذلك صلة مساهمته بالموضوع، ولا يحوّل RFC تجريبياً جماعياً إلى اختراع فردي.

الرقم وحده لا يصنع دبوساً

لا يجوز للعميل اعتماد قيمة غير صفرية لمجرد رؤيتها. يجب أن يتضمن الامتداد سلسلة مصادقة TLSA صحيحة تطابق certificate chain المقدمة، وأن تكتمل المصافحة بمصادقة DANE. نجاح PKIX وحده أو استلام سجلات لم تُفحص تواقيعها أو مجرد صحة البنية النحوية لا ينشئ تعهداً مستقبلياً.

النطاق محدد أيضاً. يحمل الطلب منفذ TCP، ويأتي اسم الخدمة من SNI الذي أرسله العميل. لا يوسّع الخادم CNAME لذلك الاسم عند بناء السلسلة المضمنة. لذلك يرتبط الدبوس بزوج الاسم والمنفذ، ولا يمتد تلقائياً إلى كل خدمة على عنوان IP أو كل مستأجر لدى مزوّد واحد.

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

ساعة للسجل وأخرى للقناة

يمكن تخزين TLSA المتحقق حتى نهاية TTL. ما دام صالحاً يستطيع العميل استخدامه من دون طلب الامتداد في كل اتصال. بعد انتهاء TTL لا تبقى البايتات القديمة دليلاً حالياً، حتى لو ظل دبوس الامتداد حياً؛ عندها يلزم جلب سلسلة جديدة عبر الامتداد أو بطريقة DNSSEC أخرى.

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

واستئناف جلسة TLS حالة ثالثة. لا يُرسل dnssec_chain عند الاستئناف، وفي TLS 1.3 لا تُعاد أيضاً رسالة Certificate التي يحمل عليها الامتداد. لذا فإن عدّ كل مصافحة بلا امتداد هجوماً سيصنع إنذارات كاذبة. ينبغي للوصل أن يسجل: مصافحة كاملة أم مستأنفة، انتهاء TLSA المخزن، انتهاء الدبوس، والدليل المستخدم فعلاً.

النفي الموثق ليس صمتاً

إذا حذف مالك النطاق TLSA، يستطيع الخادم تقديم سلسلة NSEC أو NSEC3 تثبت بصورة موثقة عدم وجود السجل للاسم والمنفذ. بعد التحقق منها يُمحى الدبوس. ويمكن لإثبات التفويض غير الآمن أن يمحوه أيضاً. عندها تقرر السياسة المحلية إن كان الانتقال إلى PKIX مقبولاً أو إن كان الاتصال سيغلق.

لكن حذف الامتداد من الرد لا يحمل السلطة نفسها. إذا كان الدبوس حياً ولا يوجد TLSA غير منتهٍ في الذاكرة، يجب على العميل طلب امتداد يحتوي TLSA صحيحاً أو إثبات عدم وجود صحيحاً. إن لم يصل، يؤخر العميل الاتصال أو يوقفه حتى يجلب دليلاً خارج المسار؛ وإذا فشل، يُنهي TLS. بذلك لا يستطيع خادم مزيف يحمل شهادة مقبولة في PKIX إخفاء DANE وإجبار العميل على تخفيض صامت.

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

التقاعد يبدأ بالصفر ثم الانتظار

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

تتوزع المسؤولية في الاستضافة. يملك صاحب النطاق DNS وقرار الانتقال، بينما قد يدير المزوّد الشهادات وعقد TLS وبناء السلسلة. لذلك يوصي RFC بألا تُفعل مدة غير صفرية إلا باتفاق متبادل. يكفي أن تعجز عقدة واحدة في العنقود عن الوفاء حتى يحوّل موازن الحمل التعهّد إلى فشل متقطع.

ولا تمنح السلسلةُ الخادمَ سلطة اختيار جذر الثقة. يبدأ العميل من DNSSEC trust anchor مُعد مسبقاً، ويتابع تغييره، ويحافظ على وقت دقيق بما يكفي لفحص RRSIG. الامتداد يغيّر طريق نقل الدليل، ولا يغيّر مصدر سلطته.

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

المصادر