DNS المشفَّر: DoH وDoT

وصف الدرس السابق بحث DNS العادي بأنه بطاقة بريدية: قابلة للقراءة من قِبل أي شخص يتعامل معها في الطريق. يوجد معياران من IETF لوضع تلك البطاقة البريدية داخل مغلَّف: DNS عبر TLS (DoT، وفق RFC 7858) وDNS عبر HTTPS (DoH، وفق RFC 8484). يشفّر كلاهما البحث نفسه؛ ويختلفان أساسًا في طريقة حمله.

DNS عبر TLS

ينص RFC 7858 على هدفه مباشرة: «التشفير الذي يوفره TLS يزيل فرص التنصت والتلاعب أثناء المسار باستعلامات DNS»، معالجًا حقيقة أن «كل استعلامات DNS تقريبًا تُرسَل دون تشفير، مما يجعلها عرضة للتنصت من قبل مهاجم.» يستخدم DoT منفذه الخاص المخصص، 853، بدلًا من المنفذ 53 المعتاد. ويوضح RFC السبب: «هذه التوصية بعدم استخدام المنفذ 53 لـ DNS عبر TLS تهدف إلى تجنب التعقيد في اختيار استخدام TLS أو عدمه، وتقليل خطر هجمات التخفيض (downgrade).»

DNS عبر HTTPS

يسلك RFC 8484 طريقًا مختلفًا: «يُخطَّط كل زوج من استعلام واستجابة DNS إلى تبادل HTTP»، يُحمَل عبر المنفذ 443 نفسه الذي تستخدمه حركة HTTPS العادية. ويشير RFC إلى فائدة جانبية لذلك: «منفذ HTTPS الافتراضي 443 والقدرة على مزج حركة DoH مع حركة HTTPS أخرى على الاتصال نفسه يمكن أن يردعا الأجهزة غير المخوَّلة الموجودة على المسار عن التدخل في عمليات DNS»، لأن عزل بحث ما وحجبه يصبح أصعب حين يبدو كأي طلب ويب آخر.

ما يخفيه التشفير، وما لا يزال لا يخفيه

يمنع كلا المعيارين مشغّل الشبكة أو المتنصت عبر Wi-Fi من قراءة عمليات بحثك أثناء انتقالها. لكن لا يخفيها أي منهما عن المُحلِّل الذي أرسلتها إليه. يوضح RFC 8484 بجلاء أن DoH لا يغيّر ما يستطيع الخادم نفسه رؤيته: فهو يشير إلى أن «وسائل نقل مختلفة لاستعلامات واستجابات DNS توفر فعلًا بيانات يمكن استخدامها للربط بين الطلبات»، وأن آليات الويب العادية مثل عناوين IP للعميل، وملفات تعريف الارتباط، ومعلومات جلسة TLS تعني أن «DoH لا يُعرف عنه أنه يُدخل مخاوف جديدة تتجاوز تلك المرتبطة بـ HTTPS» على طرف الخادم. وبالمثل، يشير RFC 7858 إلى أن DoT «لا يعالج مسائل أمنية أخرى في DNS» وأنه «حتى مع الرسائل المشفَّرة، قد يتمكن طرف في موضع جيد من استخلاص تفاصيل معينة من تحليل توقيت الرسائل وأحجامها.» باختصار: DNS المشفَّر ينقل من يرى عمليات بحثك إلى مشغّل المُحلِّل الذي اخترته، لكنه لا يزيل الرؤية كليًا.

هناك فجوة ثانية تستحق المعرفة. فتشفير بحث DNS لا يخفي بذاته الموقع الذي تتصل به بعد ذلك: فمصافحة TLS التي تليه تتضمن عادةً اسم المضيف بشكل ظاهر وصريح. وكما يوضح شرح Cloudflare لميزة الإشارة إلى اسم الخادم (SNI): «تُدرج SNI اسم المضيف في رسالة Client Hello، وهي الخطوة الأولى في مصافحة TLS» — تُرسَل قبل بدء التشفير. ويشرح المصدر نفسه أن امتدادًا يُسمى SNI المشفَّر (ESNI) «يضيف إلى امتداد SNI عبر تشفير جزء SNI من رسالة Client Hello»، وهو ما «يمنع أي طرف يتنصت بين العميل والخادم من رؤية الشهادة التي يطلبها العميل.» ولا يزال دعم إخفاء SNI يعتمد على موافقة كل من المتصفح والموقع عليه، وليس بعد الطريقة التي يعمل بها كل اتصال.

كيف يدعمه macOS

توثّق Apple إعداد "DNS Settings" لأجهزة Mac وiPhone وiPad الذي يقوم بهذا بالضبط: فهو يتيح للجهاز «توجيه استعلامات DNS الخاصة به عبر خادم DNS مشفَّر باستخدام DNS عبر HTTPS أو DNS عبر TLS.» يُقدَّم كملف إعداد (configuration profile)، يمكنه حصر المُحلِّل المشفَّر بنطاقات معيّنة عبر «نطاقات مطابقة تكميلية»، أو تطبيقه فقط على شبكات معيّنة باستخدام «قواعد عند الطلب» يمكن أن تطابق أشياء مثل اسم شبكة SSID.