ملف تعريف ارتباط DNS ليس مصادقةً للعميل

الخلاصة

• رموز DNS Cookie حالة خفيفة لمعاملات DNS صُممت لزيادة صعوبة هجمات التضخيم والتزوير وتسميم الذاكرة المؤقتة الصادرة من خارج المسار.
• يمنح Server Cookie الصحيح الخادم ضماناً محدوداً بأن الطلب جاء من عنوان المصدر المرصود ويحمل Client Cookie شوهد في تبادل سابق.
• لا يقاوم النظام مراقباً على المسار ولا يحدد مستخدماً أو مشتركاً أو مالك جهاز أو هوية مستخدم أو خدمة موثقة خلف محلّل أو NAT.
• تحتاج فرق التشغيل إلى سجل أدلة لطلب DNS يفصل بين التحقق من الرمز، وملاحظة الشبكة، وهوية المحلّل، وقرار التفويض.

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

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

يحمل الطلب الأول Client Cookie بطول ثمانية بايتات. وبعد رد الخادم، تستطيع الطلبات اللاحقة إرسال Client Cookie مع Server Cookie الذي تلقته. وبذلك يمكن للخادم رفض الحركة التي تعجز عن إعادة الحالة التي أصدرها أو تقييدها. تقبل الآلية النشر التدريجي، وتعمل مع NAT وanycast، ولا تتطلب اعتماداً متفقاً عليه مسبقاً لكل عميل على الإنترنت.

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

يحدد RFC 9018 طريقة متوافقة لإنشاء Server Cookie. تجمع النسخة الأولى Client Cookie وحقلي النسخة والمحجوز والطابع الزمني وعنوان IP للعميل تحت Server Secret. يدخل العنوان في الحساب مع أنه لا يظهر داخل قيمة الرمز، ويتحقق الخادم من النتيجة بالسر نفسه.

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

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

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

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

المقارنة الأقوى هي RFC 8945 الذي يعرّف TSIG. يصادق TSIG على معاملة DNS برمز مصادقة بين كيانين يتشاركان سراً أُعد مسبقاً. ويمكنه إثبات أن تحديثاً ديناميكياً أو رداً جاء من طرف معتمد يملك المفتاح. يتطلب ذلك توزيع المفتاح وحمايته وعلاقة ثقة مسماة تتجنبها رموز DNS Cookie عمداً.

حتى TSIG له حد: فهو يصادق على النقل بين طرفين يشتركان في سر، لا على حقيقة كل بيانات DNS أو مصدرها الأول. ولا ترث رموز DNS Cookie مصادقة الطرف الأقوى لمجرد أن الآليتين تستخدمان حساباً بمفتاح. الأولى حالة خفيفة لمقاومة التزوير وقابلة للنشر الواسع؛ والثانية مصادقة معاملة داخل علاقة ثقة منشأة مسبقاً.

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

يسجل سجل أدلة مفيد Client Cookie، ونسخة Server Cookie وطابعه الزمني ونتيجة التحقق، وعنوان المصدر المرصود، وعضو anycast الذي رد، وحقبة Server Secret، والنقل والتعرض على المسار، ونسخة تشغيل المحلّل إن عُرفت، وأي هوية مستخدم أو خدمة جرى توثيقها بصورة منفصلة، وسياسة التفويض، ووقت الإجراء. ولا يسجل السر نفسه أبداً.

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

المصادر

RFC 7873 — Domain Name System (DNS) Cookies; RFC 9018 — Interoperable DNS Server Cookies; RFC 8945 — Secret Key Transaction Authentication for DNS.