الخلاصة

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

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

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

هذه هي الحدود التي يوضحها RFC 8932، «توصيات لمشغّلي خدمات خصوصية DNS». نُشر النص في أكتوبر 2020 بوصفه BCP 232، ويحمل أسماء Sara Dickinson وBenno Overeinder وRoland van Rijswijk-Deij وAllison Mankin. تسجل صفحة Dickinson في IETF ثمانية RFC، من بينها RFC 8932 وRFC 9250 الخاص بـDNS عبر QUIC، وتذكر أنها ترأس مجموعة أبحاث تحسينات الخصوصية وتقييمها. وتعرّفها RIPE Labs بأنها شريكة في تأسيس Sinodun IT. تثبت هذه السجلات مساهمة جماعية مستمرة؛ ولا تجعل منها المخترعة الوحيدة لـDNS المشفّر أو المشغّلة لأي خدمة يختارها المستخدم.

يجمع RFC 8932 بين توصيات تشغيلية وإطار للإفصاح يسمى Recursive operator Privacy Statement، واختصاره RPS. ليس المقصود فرض سياسة واحدة، بل ترتيب الموضوعات بطريقة تمكّن القارئ من مقارنة ما يعلنه المشغّلون بما يمكن قياسه. نشر البيان لا يمنح شهادة تلقائية، والنص نفسه ليس مشورة قانونية.

الدليل الأول يخص النقل من العميل إلى المحلّل. يمكنه تسجيل عنوان الخدمة واسم التوثيق والبروتوكول ونتيجة الشهادة وإصدار TLS أو QUIC والحشو والتوافر وسلوك الرجوع عند الفشل. يعالج RFC 8310 ملفات استخدام DNS over TLS، ويعرّف RFC 8484 DNS over HTTPS، ثم يعرّف RFC 9250 اتصالات QUIC المخصصة. تحمي هذه المواصفات ذلك الجزء من المسار، لكنها لا تفرض حذف السؤال بعد فكّه.

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

الدليل الثاني يخص المعالجة داخل الخدمة. أي نمط تحقق عمل؟ هل جاءت الإجابة من الذاكرة المؤقتة؟ هل عدّلتها قاعدة أمنية أو استثناء أو قائمة حجب؟ هل جُمعت جلسات مختلفة بواسطة عنوان IP أو استئناف الجلسة أو رؤوس HTTP أو سمات TLS أو نمط الأسئلة؟ يبين RFC 9076 أن حركة DNS المشفّرة الداخلة قد تُربط زمنياً بالأسئلة غير المشفّرة الخارجة من المحلّل.

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

وترشيح الإجابات قرار معالجة أيضاً. يطلب RFC 8932 من RPS بيان التغييرات التي تُجرى لأمن الشبكة، أو استجابة لأمر قانوني ملزم، أو وفق سياسة طوعية لتقليل المخاطر القانونية، أو لسبب تجاري، أو لأي سبب آخر. كما يطلب توضيح مصادر قوائم الترشيح وإدارتها. قد تكون القناة سرية بينما تكون الإجابة معدّلة؛ وعبارة «DNS آمن» وحدها لا توضح الحالتين.

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

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

الدليل الرابع يتبع ما يغادر المحلّل. يحتاج الحل التكراري إلى سؤال خوادم أخرى. يوصي RFC 8932 بتقليل QNAME كي لا ترى كل طبقة إلا الجزء اللازم، ويحدّث RFC 9156 هذه الطريقة. كما يوصي بتجنب EDNS Client Subnet أو استخدام أقصر بادئة ممكنة تشغيلياً مع إعلان السياسة الفعلية عند الحاجة إليه.

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

لذلك يطلب إطار RPS إجابات محددة: هل تعد عناوين IP بيانات شخصية؟ ما الذي يُجمع ويُحتفظ به ويُشارك أو يُباع أو يُؤجر؟ ما شروط النقل وطرق التقليل؟ ما الاستثناءات والجهات المرتبطة ومصادر التمويل؟ هل تُربط أسئلة DNS بمعلومات شخصية أخرى؟ كيف تُرشح الإجابات؟ ويضيف قسم الممارسة نقاط الاتصال الحالية ووسائل التوثيق وقدرات المنبع والانحرافات المؤقتة والدعم.

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

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

قيمة عمل Dickinson وشركائها أنه أعطى هذه القرارات الخفية لغة عامة. لم يعد السؤال المهني ينتهي عند «هل الاتصال مشفّر؟»، بل يستمر: من يملك القرار بعد وصول السؤال، وما السجل الذي يشهد عليه، ومتى تنتهي صلاحية ذلك الدليل؟

المصادر