الخلاصة
- تنقل مسودة DNS Filtering Transparency معرّف مشغّل قاعدة بيانات للترشيح ومعرّف حادثة. يقود الاقتران إلى سجل قابل للقراءة، لكنه لا يصادق على صلته بواقعة الترشيح التي اختبرها التطبيق، ولا يلزم المحلّل بإرسال مرجع بعينه.
- يتخذ التطبيق قراراً مستقلاً؛ فهو يحتفظ بنسخة محلية من السجل المقترح، ويحدد المشغّلين الذين يدعمهم أو يثق بهم، ثم يقرر عرض المرجع أو حجبه. التسجيل يربط المعرّف بقالب URI ولا يشهد بصحة الحادثة أو شرعية السياسة.
- قد يكشف فتح صفحة الحادثة عنوان IP واهتمام المستخدم باسم حساس. لذلك يمثل الفعل الصريح للمستخدم القرار الثالث، ويجب أن يفصل إيصال المساءلة بين الإرسال والعرض والاسترجاع.
الفائدة المتوقعة واضحة. بدلاً من خطأ DNS غامض، يستطيع المتصفح أن يبيّن أن الاستعلام خضع للترشيح وأن معلومات إضافية متاحة. يصبح من الممكن التمييز بين عطل تقني وتدخل قائم على سياسة، وربما العثور على وسيلة لتصحيح تصنيف خاطئ.
غير أن الجملة الظاهرة على الشاشة ليست نسخة آلية من قرار واحد. المحلّل ينتقي المراجع الخارجية. والمتصفح أو نظام التشغيل أو العميل الآخر يختار المراجع التي يعترف بها ويقبل عرضها. وبعد ذلك فقط يقرر المستخدم إن كان سيطلب الصفحة التي يشير إليها المرجع.
لكل جهة معلومات وسلطة وحوافز مختلفة. وإذا احتُفظ بلقطة الشاشة الأخيرة وحدها، بدت الاختيارات الثلاثة وكأنها تفسير موحد صدر عن DNS نفسه. لن تظهر المراجع التي لم يرسلها المحلّل، ولا تلك التي رفضها التطبيق، ولا الرابط الذي امتنع المستخدم عن فتحه حمايةً لخصوصيته.
معرّفان يحددان وجهة ولا يثبتان واقعة
نُشرت draft-ietf-dnsop-filtering-transparency-00 في 1 أغسطس 2026 بوصفها النسخة الأولى المعتمدة داخل مجموعة DNSOP. تضيف المسودة قائمة fdbs إلى بيانات الخطأ المهيكلة. يضم كل عنصر db لتعريف مشغّل قاعدة بيانات حوادث الترشيح، وid لتعريف سجل محدد. وإذا ورد أكثر من زوج، فيجب أن تتعلق الأزواج كلها بالحادثة الأساسية نفسها.
لا يحقن المحلّل عنواناً عشوائياً أو نصاً حراً في واجهة التطبيق. يبحث العميل عن db في نسخته المحلية من سجل تقترح المسودة إنشاءه لدى IANA، ويستخرج قالب URI من المستوى الأول أو الثاني، ثم يضع id في الموضع المخصص. تقلل هذه الوساطة قدرة محلّل مفروض من شبكة مجهولة على استعارة ثقة المتصفح لترويج أي وجهة يشاء.
لكن ضبط الصيغة لا يثبت صحة الربط. تقر المسودة في اعتبارات الأمان بأنها لا تصادق على أن واقعة الترشيح التي واجهها التطبيق مرتبطة فعلاً بالمعلومات المعروضة. ويمكن لمن يسيطر على المحلّل إعادة استخدام زوج صحيح يقود إلى صفحة حقيقية، ثم إلصاقه باستعلام لا علاقة له بتلك الصفحة.
إمكان الوصول إلى الصفحة يثبت وجود مورد في الوجهة فحسب. لا يثبت أن المحلّل اختار الحادثة الصحيحة، أو أن السجل كامل، أو أن أمراً قانونياً موجود وصالح وينطبق على المستخدم، أو أن القاعدة استهدفت النطاق المقصود دون أضرار جانبية. ينقل البروتوكول خيطاً قابلاً للتحقق؛ ولا يحوله إلى حكم نهائي.
ينبغي أيضاً ضبط وصف سلطة الوثيقة نفسها. النسخة 00 Internet-Draft نشطة تبنتها مجموعة DNSOP واستبدلت مقترحاً فردياً سابقاً. ليست RFC، ولا يعرض Datatracker حالياً حالة RFC مقصودة لها. يمكن التعامل معها كمقترح جاد من دون تقديمها كالتزام نهائي أقره IETF.
القرار الأول عند المحلّل: أي رواية تخرج
لا تشترط المسودة إيصال معلومة معينة. يختار المحلّل مشغّلي قواعد البيانات الذين يدعمهم، ويستخدم ما يراه مناسباً من آليات ليقرر هل يرفق مرجعاً ومتى يفعل ذلك. ومن ثم فإن القائمة الخارجة مجموعة منتقاة منذ البداية، لا جرداً كاملاً لكل تفسير محتمل.
قد توجد قاعدتان عامتان لحادثة واحدة ولا يدعم المحلّل إلا واحدة. وقد لا تكون القاعدة الداخلية مرتبطة بعد برقم حادثة خارجي. وقد تختلف سياسة الإفصاح بين حماية مؤسسية ورقابة أبوية وتنفيذ لطلب خارجي. وقد يمنع التزام آخر نشر بعض التفاصيل. لا تثبت أي فرضية وحدها إساءة. لكنها تمنع اعتبار القائمة شاملة تلقائياً.
غياب fdbs لا يثبت غياب الترشيح أو الأمر أو السجل أو سبيل التصحيح. يثبت فقط أن الاستجابة التي وصلت إلى التطبيق لم تتضمن مرجعاً صالحاً للاستخدام. وهناك انقطاع إضافي محتمل: بعض بنى الأنظمة لا تتيح لكل تطبيق تفاصيل استجابة DNS، فيضيع المرجع قبل الوصول إلى طبقة العرض حتى لو أرسله المحلّل.
يحتاج سجل المحلّل إلى وقت الرصد، وسياق العلاقة الموثقة بالمحلّل إن توافر، ورمز EDE، وأزواج المعرّفات المرسلة، وقاعدة الاختيار، ووجود بدائل معروفة لم تُرسل. ينبغي تقليل تخزين الأسماء الحساسة والهوية وحصر الوصول إليها. أما حقيقة وقوع الاختيار فلا يجوز محوها باسم تقليل البيانات.
القرار الثاني عند التطبيق: من يملك حق الوصول إلى الشاشة
بعد وصول الاستجابة يصبح العميل موزّعاً للتفسير. تفترض المسودة أن التطبيقات ستدعم مجموعات مختلفة من مشغّلي قواعد البيانات، وتطلب منها ممارسة حكم بشأن الرسائل التي تعرضها. قد يؤثر في ذلك محلّل الاستجابة وهوية مشغّل القاعدة والإعداد المحلي.
وهكذا يمكن لجهازين تلقيا البتات نفسها أن يعرضا نتيجتين مختلفتين. يتعرف أحدهما إلى db ويكوّن الرابط، بينما لا يملك الآخر القيد بعد. يقبل تطبيق رسالة المشغّل إذا جاءت من محلّل مضبوط صراحة، في حين يشترط تطبيق آخر قائمة ثقة إضافية. وقد يمرر نظام التشغيل الحقول المهيكلة إلى المتصفح أو يحجبها عنه.
لا تكشف الشاشة النهائية موضع الاختلاف. عدم ظهور رابط قد يعود إلى عدم إرسال المحلّل أو قِدم نسخة السجل أو رفض سياسة الثقة أو حدود النظام المضيف. وظهور الرابط لا يثبت أن التطبيق تحقق من الأمر أو السياسة خلفه؛ بل يثبت فقط أنه قرر توزيعه.
تضيف النسخة المحلية بعداً زمنياً. يستطيع مسؤول قيد في السجل تغيير قالب URI في أي وقت، وتحذر المسودة من تأخر طويل محتمل قبل تحديث التطبيقات لنسخها. إعادة بناء الوجهة التي عُرضت يوم الحادثة تحتاج إلى لقطة السجل الموجودة آنذاك، وليس إلى القيد الحالي وحده.
ولا يمثل التسجيل ختم جودة. تقترح المسودة سياسة الأسبقية في الطلب، مع السماح لـ IANA برفض التسجيلات الخادعة أو الزائفة. يوضح RFC 8126 أن هذه السياسة لا تتضمن عادة مراجعة موضوعية، بل تتحقق من الشكل وعدم التكرار وبعض البيانات الإدارية. يجيب السجل عن سؤال القالب المرتبط بالمعرّف؛ ولا يجيب عن صحة قصة الحادثة.
لذلك يجب أن يحفظ إيصال التطبيق تاريخ نسخة السجل أو بصمتها، والقالب الذي جرى توسيعه فعلاً، وإصدار قوائم الدعم والثقة، والعناصر المقبولة والمرفوضة، وفئة السبب، ونوع الرسالة المعروضة. ومن دون ذلك قد يبدو رفض التطبيق صمتاً من المحلّل، أو يبدو فشل قالب قديم دليلاً على عدم وجود السجل.
القرار الثالث: طلب التفسير يخلق إفصاحاً جديداً
تفاصيل الحادثة ليست داخل رسالة DNS. قراءتها تتطلب اتصالاً بمشغّل قاعدة البيانات. وقد يرى المشغّل عنوان IP ويستنتج أن شخصاً عند ذلك العنوان حاول حل اسم خاضع للترشيح. وفي القضايا الحساسة يمكن أن يصبح السعي إلى معرفة السبب معلومة خطرة بحد ذاته.
لهذا ترسم المسودة حداً واضحاً. إذا لم يستخدم التطبيق آلية تحفظ الخصوصية مثل الوكيل، فلا يجوز له جلب صفحة الحادثة تلقائياً من دون فعل صريح من المستخدم. وتحذر أيضاً من تعاون المحلّل ومشغّل القاعدة، أو كون الجهة نفسها تؤدي الدورين، واستخدام معرّفات حوادث فريدة لربط النشاط عبر الطلبات.
يستطيع التطبيق إبلاغ المستخدم بوجود معلومات إضافية من دون تحميلها مسبقاً. يمكنه تعريف الجهة المستقبلة، والتفريق بين المسار المباشر والمسار المحمي، وتأخير الاتصال حتى يأتي الاختيار. ولا يتطلب إثبات الامتثال إنشاء سجل دائم بمن فتح أي اسم؛ يكفي إثبات تعطيل الجلب التلقائي، وسبق الفعل الصريح، ونوع المسار، ونتيجة الطلب.
هذا التقليل جزء من الحوكمة. فآلية صُممت لتفسير تدخل ما يجب ألا تنشئ في المقابل قاعدة أدق عن الأشخاص الذين حاولوا فهمه. ينبغي أن يحفظ التدقيق ترتيب القرار، لا أن يعيد إنتاج التعرض الذي يفترض أنه يحد منه.
البنية والتشفير والتسجيل ضمانات منفصلة
تعتمد الآلية على مسودة Structured Error Data for Filtered DNS. تجعل تلك المسودة حقولاً مثل جهة الاتصال والتبرير والمنظمة ونوع الخطأ قابلة لمعالجة الآلة، لكنها تشترط ألا تُوثق أو تُعرض تلقائياً وألا تؤثر في قرارات الأمان من دون تحقق ملائم. كما تشترط نقل DNS مشفراً لهذا التبادل المهيكل.
قابلية المعالجة لا تساوي الحقيقة. التشفير يحمي الطريق من المراقبة السلبية، لكنه لا يصادق على صحة كلام الطرف النهائي. وتسجيل اسم JSON أو معرّف قاعدة يثبت اصطلاحاً وعنواناً، ولا يمنح سلطة مؤسسية. كل طبقة تحل مشكلة محددة ولا يجوز استعارة ضمانها لحل مشكلة أخرى.
يمد RFC 7754 السلسلة إلى ما قبل التنفيذ التقني. فقد تختلف الجهة التي تضع سياسة الحجب عن الجهة التي تنفذها، ويمكن أن تتغير النية أثناء انتقالها من قانون إلى قاعدة إدارية ثم سياسة مشغّل فتصميم وتنفيذ. يساعد الإخطار السريع على تصحيح الأخطاء والأضرار الجانبية، لكنه لا يحسم قانونية إجراء بعينه أو أخلاقيته.
إيصال سلسلة الإفصاح
يقترح Daniel Kade إيصالاً من ثلاثة أقسام مترابطة. يحفظ قسم المحلّل الرصد وحالة التوثيق وEDE والأزواج المرسلة وقاعدة الاختيار وحالة البدائل المعروفة. ويثبت قسم التطبيق لقطة السجل والقالب المستخدم وإعدادات الدعم والثقة وقرار العرض وفئة الرسالة. ويسجل قسم المستخدم ما إذا عُرض الاسترجاع، وهل سبقه فعل صريح، وهل حماه وكيل، وما كانت النتيجة.
تبقى المجهولات مجهولة. هوية المحلّل غير الموثقة لا تُستكمل لاحقاً. وسبب الحذف غير المعروف لا يحصل على رواية مخترعة. والنسخة القديمة لا تُستبدل بالقيد الحالي. والصفحة التي تغيرت لاحقاً لا تُقدّم باعتبارها محتوى الأمس. وإذا توافر أمر أو سياسة من مصدر مستقل، يربط بالإيصال مع مصدره الخاص ولا يُستنتج من db وid.
لا يضفي الإيصال شرعية على الترشيح. إنه يجعل طريق التفسير قابلاً للمساءلة: يحدد أين اختفى المرجع، ولماذا لم يعرضه التطبيق، وما التعرض الإضافي الذي كان سيخلقه فتحه. وبذلك لا تستطيع رسالة أنيقة أن تتنكر في صورة اتفاق موحد لم يصدر في الواقع عن أي من أصحاب القرارات الثلاثة.
المصادر
- DNS Filtering Transparency، نسخة مجموعة العمل 00
- حالة الوثيقة في Datatracker
- سجل المراجعات
- ميثاق مجموعة DNSOP
- Structured Error Data for Filtered DNS، المراجعة 27
- حالة Structured Error Data
- RFC 8914 — Extended DNS Errors
- RFC 7754 — الاعتبارات التقنية للحجب والترشيح
- RFC 6570 — URI Template
- RFC 8126 — إرشادات أقسام IANA
- Lu Heng — الحد الأدنى للمواصفات ومستقبل تنسيق الإنترنت
- Lu Heng — The Policy Mirror
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات
