الخلاصة

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

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

كان المرجع مفيداً، لكنه أصبح أيضاً علامة مراقبة.

يقترح draft-ietf-dnsop-filtering-transparency-00 سياقاً لنتائج DNS التي تبدو عطلاً تقنياً بينما تكون تدخلاً قانونياً أو سياسياً. غير أن الشفافية لا تلغي الخصوصية. إنها تنشئ معاملة شبكة جديدة بعد الاستعلام الأول.

النسخة 00 مؤرخة في 1 أغسطس 2026 وتنتهي في 2 فبراير 2027. هي مسودة نشطة لمجموعة DNSOP مقصودها Standards Track، وليست RFC أو سجل IANA منجزاً أو سياسة متصفح أو تقرير نشر. كما تعتمد على مسودة الأخطاء المنظمة في DNS.

مرجعان لا رابط حر

يتكون إدخال قاعدة بيانات الترشيح من db لمشغل القاعدة وid للحادثة. وقد تحمل القائمة عدة إدخالات يجب أن تتعلق بالحادثة الأساسية نفسها.

لا يسمح التصميم للمحلل بوضع عنوان URL اعتباطي. فالمحلل قد يأتي من شبكة تضبطه آلياً، وقد تكون الاستجابة غير موثوقة. السماح بنص أو رابط حر يفتح واجهة التطبيق لهجوم من شبكة عامة.

يحتفظ التطبيق بنسخة محلية من سجل مقترح، ويستخدم قالب URI من المستوى الأول أو الثاني لإدخال المعرّف. بعد ذلك يقرر إن كان يعرض الإجراء.

المحلل يرشح المراجع، والسجل ينسق القالب، والتطبيق يختار الثقة، والمستخدم يختار الجلب. لا يملك طرف واحد السلسلة كاملة.

الرمز يمكن أن يكون خاصاً بكل شخص

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

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

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

ينبغي أن يعرف التطبيق هل الرمز للحادثة كلها أم للنطاق أم للشبكة أم للعميل أم للاستعلام. كما يحتاج حدوداً للاحتفاظ وإعادة الاستخدام. عبارة «مشغل موثوق» لا تجيب عن هذه الأسئلة.

فتح الشرح يكشف اهتماماً حساساً

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

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

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

ينبغي فصل بناء الرابط وعرضه والنقر واختيار الوكيل والطلب والتحويل والاستجابة. سجل واحد باسم «عُرض الشرح» لا يثبت أن الكشف جاء بعد الاختيار.

السجل لا يمنح شهادة ثقة

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

هذه آلية تنسيق أسماء. لا تفحص جودة الأدلة أو الاستقلال أو الاختصاص أو التصحيح أو مدة حفظ البيانات. وجود صف لا يلزم التطبيق بعرضه.

يجب أن يحتفظ التطبيق بنسخة محلية وألا يسأل IANA عند كل حادثة. يقل ذلك نقطة المراقبة المركزية لكنه يخلق نسخاً قديمة. يستطيع المشغل تحديث القالب فيما يبقى العميل على الوجهة السابقة.

إعادة بناء ما رآه المستخدم تحتاج بصمة نسخة السجل. حالة اليوم لا تثبت الطريق الذي استُخدم بالأمس.

الصفحة الحقيقية قد تُنسب إلى حادثة كاذبة

لا تصادق المسودة على أن الحادثة التي واجهها التطبيق مرتبطة بالمعلومة المعروضة. يمكن لمهاجم يسيطر على المحلل أن يدعي ترشيحاً لم يقع.

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

المحلل يدعي الصلة، والسجل يوفر الطريق، والقاعدة تنشر الوصف. نجاح HTTP يثبت الوصول إلى مورد ولا يثبت سبب نتيجة DNS.

يجب أن تميز الواجهة بين «أبلغه المحلل» و«مشغل معروف» و«صفحة جُلبت» و«حادثة موثقة». الحالة الأخيرة لا توفرها هذه السلسلة وحدها.

التفاصيل قد لا تصل إلى التطبيق

بعض أنظمة التشغيل لا تعرض تفاصيل استجابة DNS. قد يرسل المحلل fdbs صحيحاً، ثم يحول المضيف النتيجة إلى خطأ عام.

الإرسال والوصول وعرض المضيف والتحليل والتعرف والثقة والعرض والنقر والجلب مراحل مستقلة. لا يثبت الإرسال أن المستخدم أُبلغ، ولا يثبت غياب الزيارات أن المحلل لم يرسل.

تحتاج كل مرحلة مقاماً خاصاً في القياس. جمع البداية والنهاية في نسبة واحدة يخفي فقداناً تتحكم فيه جهات مختلفة.

تعدد القواعد لا يصنع تصويتاً

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

كونها عن الحادثة نفسها هو أولاً تصريح من المحلل. لا ينبغي دمج الصفحات في نص بلا مصدر أو اعتبار العدد أغلبية للحقيقة.

يمكن للتطبيق إظهار الخلاف أو تطبيق أولوية معلنة. الشفافية تعني إبقاء صاحب كل ادعاء مرئياً.

الشفافية تحتاج حق الرفض

قيمة التصميم في توزيع السيطرة. لا يختار المحلل وجهة اعتباطية، ولا يفرض السجل الثقة، ولا يحول التطبيق المرجع إلى إثبات، ويستطيع المستخدم رفض الجلب.

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

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

المصادر