سجلات محلّل DNS مقابل سجلات اتصال VPN: ماذا يحتفظ كل منهما

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

سجلان، حدثان

تُجيب مدخلة المحلّل عن سؤال يتعلق بالتسمية: هذا العميل طلب هذا الاسم في هذا الوقت، وكان الجواب هو هذا. وتُجيب مدخلة الـ VPN عن سؤال يتعلق بالاتصال: هذا النظير أنشأ نفقًا أو فقده، وأُسند إليه هذا العنوان، ونقل قرابة هذه الكمية من البيانات قبل أن يختفي. وليس أي منهما سجلًا لما فعله المستخدم داخل جلسة HTTPS، ولا يغني أحدهما عن الآخر.

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

تتبّع الاستعلام قبل قراءة أي من السجلين

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

resolvectl status
dig @127.0.0.53 build.corp.example +qr
journalctl -u systemd-resolved -n 20 --no-pager

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

ما يمكن أن يُظهره كل سجل وما لا يمكنه

الربط بينهما هو موضع العمل الحقيقي، والربط بينهما ليس ممكنًا دائمًا. فمحلّل يسجّل عناوين العملاء يمكن مقارنته بـ VPN يُسند عناوين من مجموعة معروفة، وتُنتج تلك المقارنة صلة معقولة بين اسم مستعلم عنه ونفق، وهي تبقى صلة بين سجلين لا سجلًا لشخص.

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

حيث يخلط DNS المنقسم وذاكرات التخزين المؤقت القصة

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

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

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

اطرح أسئلة الاحتفاظ منفصلة

لكل نظام، اطرح ثلاثة أسئلة: من يجمع، وما الذي يُجمع، وإلى متى يُحتفظ به. ثم اسأل من يمكنه قراءته وبأي إجراء. ونقاش RFC 8484 حول DNS over HTTPS تذكير جيد بأن النقل المشفّر لا يزيل نقطة النهاية، ووثائق المشغّل نفسه هي البيان الموثوق الوحيد عمّا تحتفظ به تلك النقطة.

حين يُقال ادّعاء عن الخصوصية بشأن “الـ VPN”، فقسّمه إلى مكوّنات قبل قبوله: مشغّل النفق، والمحلّل الذي يقدّمه النفق، وأي محلّل أعلى تصل إليه تلك الاستعلامات، والتطبيقات على الجهاز. ولكل منها جوابه، والادّعاء الصحيح لواحد منها يُكرَّر عادةً كأنه يغطي الأربعة.

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