DNSSEC مقابل VPN: أيّهما يخفي استعلامات DNS؟

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

ثلاث دعاوى تُدمج في واحدة

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

يعالج DNSSEC الأولى ولا يقول شيئاً عن الأخريين. يعالج DoT وDoH الثانية بالنسبة للقفزة إلى المُحلِّل. ويعالج VPN الثالثة وقد يؤثّر أيضاً في الثانية، لكن كأثر جانبي لما يتّجه إليه المرور فقط.

مرور التطبيقات حالة رابعة: يحمي HTTPS ويصادق على التبادل الشبكي بين عميلك والموقع، ولا تحلّ أي طبقة DNS محلّه.

ما يمكن للتحقّق من التوقيع فعله وما لا يمكنه

يتحقّق المُحلِّل المُصادِق من سلسلة التوقيعات من النطاق وصولاً إلى مرساة ثقة مضبوطة، ثم يعيد إجابة مع ضبط علامة البيانات المُصادَق عليها عند نجاح التحقّق. تلك العلامة دليل على البيانات، لا على الاتصال ولا على نوايا الوجهة.

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

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

من أين تأتي السرّية فعلاً

يغلّف نقل المُحلِّل المشفّر تبادل DNS داخل TLS، فيظل المُحلِّل يرى السؤال لكن المسار بينك وبينه لا يراه. هذا ينقل الثقة بدل أن يزيلها: أنت تثق بالمُحلِّل أكثر وبالشبكة المحلية أقل.

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

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

اختبر التحقّق والنقل بشكل منفصل

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

تطبع هذه الأوامر العلامات من استعلام مُصادِق، وتكرّر الاستعلام مع تعطيل التحقّق، وتشغّل التحقّق المحلي باستخدام delv:

dig +dnssec example.com | grep flags
dig +cd example.com | grep status
delv example.com

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

ما العمل عندما يُعطّل VPN الاستعلامات

إذا كانت الاستعلامات تعمل قبل النفق وتتوقّف بعده، قارن المُحلِّل الذي يستخدمه كل مسار. التوجيه المنقسم، ومُحلِّل داخلي لا يُبلَغ إلا عبر النفق، وعميل يعيد كتابة إعدادات المُحلِّل، كلها تغيّر الإجابة دون أن تمسّ DNSSEC.

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