مقدمة

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

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

ما هو DNS التقليدي ولماذا احتاج إلى التشفير؟

عند كتابة عنوان موقع في المتصفح، يحتاج الجهاز أولاً إلى معرفة عنوان الخادم المرتبط بذلك الاسم. يرسل الجهاز استعلاماً إلى محلّل DNS، وهو خادم قد يتبع مزود خدمة الإنترنت أو المؤسسة أو مزوداً عاماً مثل Cloudflare أو Google. يستعلم المحلّل، إن لم تكن الإجابة مخزنة لديه، من خوادم الجذر ثم خوادم النطاقات العليا والخادم الموثوق للنطاق، ويعيد في النهاية عنواناً مثل 203.0.113.10.

في DNS التقليدي، تُرسل هذه العملية غالباً عبر UDP، وأحياناً عبر TCP، على المنفذ 53. وعلى الرغم من أن محتوى الموقع نفسه قد يكون مشفراً عبر HTTPS، فإن اسم النطاق المطلوب قد يبقى ظاهراً في حركة DNS. على سبيل المثال، يستطيع مراقب شبكة عامة معرفة أن جهازاً ما استعلم عن bank.example أو medical-service.example، حتى لو لم يتمكن من قراءة صفحات الموقع أو بيانات تسجيل الدخول.

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

كيف يعمل DNS عبر HTTPS من الناحية التقنية؟

يستخدم DoH بروتوكول HTTPS، أي HTTP فوق TLS، لنقل طلبات واستجابات DNS. بدلاً من إرسال حزمة DNS مكشوفة إلى المنفذ 53، ينشئ العميل اتصالاً آمناً بخادم DoH، عادة عبر المنفذ 443. وبهذا تبدو الاستعلامات، من منظور الشبكة الوسيطة، جزءاً من حركة ويب مشفّرة عادية متجهة إلى مزود الخدمة المختار.

يعرّف المعيار القياسي لـ DoH، RFC 8484، طريقتين شائعتين لإرسال الطلبات: طلب HTTP من النوع GET يحمل رسالة DNS مشفّرة بترميز مناسب ضمن عنوان الطلب، أو طلب POST يحمل الرسالة الثنائية في جسم الطلب. وفي الحالتين يكون نوع المحتوى المعتاد هو application/dns-message. بعد إتمام مصافحة TLS والتحقق من شهادة الخادم، يرسل العميل رسالة DNS ويستقبل الإجابة ضمن جلسة HTTPS المشفّرة.

يمكن تصور التسلسل العملي كما يلي: يطلب المتصفح النطاق www.example.com، فيتحقق أولاً مما إذا كانت الإجابة موجودة في ذاكرة التخزين المؤقت. فإن لم تكن موجودة، يرسل الاستعلام إلى نقطة نهاية DoH مثل https://resolver.example/dns-query. يقوم الخادم بتحليل الاسم وإعادة سجل العنوان، ثم يستخدم المتصفح العنوان للاتصال بالموقع المطلوب. وقد يستمر الاتصال مع خادم DoH نفسه باستخدام HTTP/2 أو HTTP/3، ما يسمح بتجميع طلبات متعددة داخل جلسة واحدة أكثر كفاءة.

curl -H "accept: application/dns-json" \
"https://cloudflare-dns.com/dns-query?name=example.com&type=A"

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

أثر DoH في خصوصية المستخدمين

الفائدة المباشرة لـ DoH هي تقليل قدرة الأطراف الواقعة بين المستخدم والمحلّل على قراءة أسماء النطاقات التي يستعلم عنها. ففي شبكة واي فاي عامة، أو لدى مزود خدمة إنترنت، أو في شبكة محلية غير موثوقة، لا يستطيع المراقب عادة رؤية محتوى استعلام DNS عندما يكون محمياً بطبقة TLS سليمة. كما يصعب عليه تعديل الإجابة من دون اكتشافه بسبب آليات التحقق المرتبطة بشهادات HTTPS.

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

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

لذلك تعتمد الخصوصية الفعلية على سياسة مزود DoH في الاحتفاظ بالسجلات، وموقعه القانوني، وآلية اختياره في المتصفح أو نظام التشغيل. كما أن الجمع بين DoH وDNSSEC وHTTPS للمواقع وتقنيات تقليل البصمة الرقمية يمنح حماية أشمل من الاعتماد على DoH وحده.

لماذا يربك DoH أدوات مراقبة الشبكات والحماية؟

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

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

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

ولا يقتصر الأثر على الحماية؛ إذ تتأثر أيضاً أدوات الامتثال، والتحقيقات الجنائية الرقمية، وتقارير استخدام الإنترنت، وخدمات التصفية الأبوية أو التعليمية. كما قد يؤدي استخدام متصفح لخادم DoH مختلف عن خادم المؤسسة إلى تجاوز سياسات DNS الداخلية، مثل توجيه أسماء النطاقات الخاصة أو بوابات الدخول المقيدة.

استراتيجيات الكشف والتعامل المؤسسي مع حركة DoH

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

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

فيما يلي مثال تصوري لسياسة مؤسسية في متصفح مُدار، تُحدد نقطة نهاية DoH داخلية:

{
  "DnsOverHttpsMode": "secure",
  "DnsOverHttpsTemplates": "https://doh.corp.example/dns-query{?dns}"
}

أما في طبقة الشبكة، فيمكن مراقبة اتصالات العملاء إلى مزودي DoH المعروفين، وتحليل سمعة عناوين IP، والاعتماد على سجلات نقاط النهاية EDR، وسجلات الوكيل، وتحليل سلوك العمليات. فإذا بدأت عملية غير معتادة على جهاز موظف بإنشاء اتصالات مشفّرة متكررة إلى وجهات غير مألوفة، فقد يكون ذلك مؤشراً يستحق التحقيق حتى لو كان محتوى DNS غير مرئي.

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

الموازنة بين الخصوصية والأمن وأفضل ممارسات النشر

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

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

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

أما المستخدمون الأفراد، فينبغي لهم اختيار مزود موثوق، وقراءة سياسة الاحتفاظ بالسجلات، وتحديث المتصفح والنظام باستمرار، وعدم الخلط بين تشفير DNS وحماية كل جوانب التصفح. استخدام HTTPS للمواقع، وتفعيل التحقق متعدد العوامل، والحذر من روابط التصيد، تبقى إجراءات ضرورية حتى مع تشغيل DoH.

خاتمة

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

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