DNS عبر HTTPS مقابل Enterprise Split-Horizon DNS: مواجهة لن تُحل من تلقاء نفسها

طوال معظم تاريخ الإنترنت، كانت استعلامات DNS تنتقل كنص صريح (cleartext) عبر المنفذ 53. وكان بإمكان أي شخص على مسار الشبكة قراءتها، وتسجيلها، وتعديلها. شكل هذا مشكلة تتعلق بالخصوصية عالجتها مجموعة هندسة شبكة الإنترنت (IETF) لاحقًا عبر بديلين مشفرين: DNS عبر TLS (DoT، RFC 7858) في عام 2016، وDNS عبر HTTPS (DoH، RFC 8484) في عام 2018.

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

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

ماذا يفعل DoH فعليًا

يرسل عميل DoH استعلامات DNS كطلبات HTTPS POST أو GET، وعادةً ما يكون ذلك إلى https://dns.google/dns-query أو https://cloudflare-dns.com/dns-query أو أي محلل (resolver) عام آخر. وتعود الاستجابة كجسم استجابة HTTPS طبيعي. هناك ثلاث خصائص هامة في هذا السياق:

مشفر أثناء النقل. لا يستطيع مراقبو الشبكة قراءة اسم الاستعلام أو إجابته.
خادم موثق. يتحقق العميل من شهادة TLS الخاصة بالمحلل، لذلك لا يمكن لأي هجوم رجل في المنتصف (man-in-the-middle) انتحال شخصيته.
لا يمكن تمييزه عن حركة مرور الويب. يستخدم المنفذ 443، وTLS 1.3، وأنماط SNI العادية. لا توجد حركة مرور بشكل DNS يمكن فلترتها أو تصفيتها.

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

ماذا يفعل Enterprise split-horizon DNS فعليًا

تعتمد معظم المؤسسات الكبيرة على تقنية split-horizon DNS. حيث يتم تحليل نفس الاسم (مثل vpn.example.corp، git.example.com، intranet.example.com) إلى عناوين IP مختلفة اعتمادًا على ما إذا كان الاستعلام قادمًا من داخل الشبكة أو خارجها.

داخل الشبكة:

المحلل (resolver) هو نظام DNS الداخلي للشركة، وغالبًا ما يكون متكاملًا مع الدليل النشط (Active Directory).
قد يُحلل git.example.com إلى عنوان RFC 1918 خاص مثل 10.0.4.7.
النطاقات الداخلية فقط (example.corp، example.internal) قد لا تكون موجودة على الإنترنت العام من الأساس.
ترى أدوات الأمان ومنع فقدان البيانات (DLP) كل استعلام، ويمكنها وضع علامة على استعلامات DNS الموجهة إلى النطاقات الخبيثة المعروفة.

خارج الشبكة (أو على جهاز شخصي عبر شبكة Wi-Fi منزلية):

يذهب نفس الاستعلام إلى محلل عام.
يُحلل git.example.com إلى موازن الحمل (load balancer) العام.
لا يتم تحليل الأسماء الداخلية فقط ببساطة.

هذا ليس أمرًا غريبًا؛ بل هو الوضع الافتراضي لجميع المؤسسات تقريبًا التي يزيد عدد موظفيها عن بضع مئات. ويعتمد ذلك على افتراض بالغ الأهمية: يستخدم الجهاز الطرفي (endpoint) المحلل الذي تمليه عليه الشبكة، وذلك من خلال بروتوكول DHCP، أو سياسات النشر (push policy)، أو إعدادات الشبكة الافتراضية الخاصة (VPN).

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

كيف حاولت المتصفحات وأنظمة التشغيل التعامل مع هذا الأمر

لم يكن الموردون غافلين عن هذه المشكلة. فالتسويات الموجودة اليوم تعتبر متعددة الطبقات وعشوائية بعض الشيء.

نموذج "الترقية التلقائية" في Chrome

يقوم تطبيق DoH في متصفح Chrome بترقية محلل النظام إلى DoH فقط إذا كان محلل النظام نفسه موجودًا في قائمة Chrome المسموح بها لمزودي خدمة DoH (مثل Google، وCloudflare، وQuad9، وغيرها). أما إذا كان النظام مهيأً لاستخدام محلل مؤسسي داخلي غير موجود في هذه القائمة، فإن Chrome لا يتدخل فيه. يمكن أيضًا لسياسات المؤسسة تعطيل DoH تمامًا عبر إعداد DnsOverHttpsMode الخاص بـ Chrome.

نموذج TRR (المحلل العودي الموثوق) في Firefox

كان نهج Firefox أكثر إثارة للجدل. في المناطق التي مكّنت فيها شركة Mozilla تقنية DoH افتراضيًا، يستخدم Firefox محللًا افتراضيًا مثل Cloudflare في الولايات المتحدة، ولكنه يقوم أيضًا بتشغيل استدلالات (heuristics) خاصة بالشبكة والمؤسسة قبل تفعيل DoH. إحدى الإشارات المهمة هي نطاق الاختبار (canary domain) use-application-dns.net: عندما يُرجع المحلل المحلي نتيجة سلبية، يقوم Firefox بتعطيل DNS على مستوى التطبيق للمستخدمين الذين تم تمكين DoH لديهم افتراضيًا. توثق Mozilla أيضًا فارقًا دقيقًا وهامًا في split-horizon: يمكن للأسماء الداخلية فقط التراجع (fall back) إلى DNS العادي في حال فشل تحليل DoH، ولكن الأسماء العامة التي تُحلل بشكل مختلف داخل الشبكة تتطلب سياسة مؤسسية لتعطيل DoH.

DNS المشفر من Apple (iOS 14+ وmacOS Big Sur+)

تتيح Apple للتطبيقات وملفات تعريف التكوين اختيار تفعيل DoH أو DoT للنظام بأكمله، ولكنها تحترم سياسات إدارة الأجهزة المحمولة (MDM) التي تفرض محللًا معينًا. تتصرف الأجهزة المدارة من قِبل المؤسسات بشكل صحيح وتلقائيًا دون الحاجة لتدخل إضافي.

دعم DoH الأصلي في Windows

بدءًا من Windows 11، وفي Windows Server 2022 والإصدارات الأحدث، يمكن لنظام التشغيل نفسه استخدام DoH لمحلل النظام. تتحكم سياسة المجموعة (Group Policy) فيما إذا كان DoH مسموحًا به أو مطلوبًا أو محظورًا، ولا يقوم Windows بتمكين DoH إلا مع خوادم DNS المُكوّنة والتي يُعرف أنها تدعمه. يمكن القول إن هذا هو النموذج الأكثر وضوحًا ونظافةً: فريق الأمان يختار السياسة، ونظام التشغيل يطبقها.

النمط هنا واضح: إن DoH الذي يقتصر على تطبيق واحد (المتصفح) يصعب على الشبكة التحكم فيه؛ بينما DoH الذي يدمج في محلل مستوى نظام التشغيل يمكن التحكم فيه من خلال قنوات MDM المعتادة. اتفقت مجموعة IETF وموردو أنظمة التشغيل إلى حد كبير على أن السياسة يجب أن تُطبق في طبقة نظام التشغيل.

الخيارات الواقعية للمؤسسة في عام 2026

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

الاستراتيجية أ: داخلي بالكامل، مع حظر DoH

نشر سياسة تعطل DoH في كل متصفح، وتحظر المنفذ 443 لنقاط نهاية DoH العامة المعروفة، وتجبر جميع استعلامات DNS على المرور عبر المحلل الداخلي. قد يستخدم المحلل الداخلي نفسه تقنية DoH للتواصل مع المحللات العامة العليا (upstream)، ولكن داخل الشبكة يمر كل شيء من خلاله.

هذا هو الخيار الأكثر حزمًا. فهو يحافظ على split-horizon بشكل مثالي ويمنح أدوات الأمان رؤية كاملة. وتكمن تكلفته في أنك مضطر للاحتفاظ بقوائم حظر لنقاط نهاية DoH الجديدة وتحديثها باستمرار، وأي تطبيق يثبته المستخدم ويدير DoH الخاص به (مثل بعض تطبيقات الدردشة وبعض شبكات VPN) قد يتعرض لخلل في الأداء.

الاستراتيجية ب: DoH داخلي

إعداد خادم DoH داخلي (مثل Cloudflared، أو AdGuard، أو Windows DNS Server مع تفعيل DoH)، وتهيئة الأجهزة الطرفية لاستخدامه، وتشغيل split-horizon على خادم DoH الداخلي. تحصل الأجهزة الطرفية على DNS مشفر دون أن تفقد الشبكة قدرتها على الرؤية والمراقبة.

يُعد هذا الخيار الأكثر تنظيمًا وهو الاتجاه الذي تسلكه معظم المؤسسات الكبيرة. فهو يحافظ على ميزة الخصوصية (تشفير الاستعلامات على الشبكة المحلية LAN) مع الحفاظ على ميزة الأمان (حيث لا يزال بإمكان المحلل الداخلي رؤية وتصفية كل استعلام). تدعم كل من Microsoft، وGoogle، وApple تكوين مستوى نظام التشغيل (OS-level) لهذا السيناريو.

الاستراتيجية ج: نطاق الاختبار (Canary domain) / إشارة الشبكة

نشر نطاق الاختبار (canary domain) الخاص بـ Mozilla. ودفع سياسات Chrome وEdge ذات الصلة. والاعتماد على المتصفحات لاكتشاف أنها متصلة بشبكة مدارة ومن ثم ترك القرار لمحلل النظام. يُعد هذا الخيار الأقل تدخلاً وهو كافٍ للعديد من المؤسسات الصغيرة والمتوسطة.

الاستراتيجية د (غير فعالة): "سنتجاهل DoH بكل بساطة"

الادعاء بعدم وجود المشكلة، وترك الإعدادات الافتراضية كما هي، وافتراض أن جميع استعلامات DNS لا تزال تتدفق عبر محلل الشركة. هذه هي الحالة الأكثر شيوعًا وتؤدي إلى إخفاقات يمكن التنبؤ بها: حيث يبلغ المطورون أن عناوين URL الداخلية فقط تعمل في Edge ولكنها لا تعمل في Firefox، وترى فرق الأمان فجوات في سجلات DNS، وتظهر أخطاء متقطعة في VPN-DNS تستغرق ساعات لتشخيصها. المشكلة لا تختفي؛ بل يصبح من الصعب فقط تحديد سببها.

الخصوصية ليست الشيء الوحيد الذي تتنازل عنه تقنية DoH

من التأثيرات الدقيقة لـ DoH هي مركزية المحلل (resolver centralization). عندما يتم تكوين متصفح أو نظام تشغيل لاستخدام محلل DoH عام، فقد يذهب جزء أكبر من تدفق DNS الخاص بهذا المستخدم إلى مشغل محلل واحد. صُمم الوضع التلقائي في Chrome خصيصًا للحفاظ على مزود DNS الحالي للمستخدم حيثما أمكن ذلك، كما أن الطرح الافتراضي لـ Firefox يعتمد على المنطقة الجغرافية والاستدلالات، لذلك فإن هذا لا يعني حرفيًا "كل استعلام" في كل عملية نشر. لكن تظل المقايضة المعمارية (architectural trade-off) قائمة: يمكن أن ينقل DNS المشفر الثقة من الشبكة المحلية أو مزود خدمة الإنترنت (ISP) إلى مجموعة أصغر من مشغلي المحللات المختارين.

تعتمد مقبولية هذه المقايضة على نموذج التهديد (threat model). بالنسبة لمستخدم على شبكة مقهى غير آمنة، يُعد تركيز الثقة مع Cloudflare تحسينًا واضحًا مقارنة بالثقة في المقهى. أما بالنسبة لمؤسسة لديها بالفعل علاقة تعاقدية مع مزود خدمة الإنترنت الخاص بها، فقد يكون ذلك تراجعًا. لطالما كتبت مؤسسة الحدود الإلكترونية (EFF) عن هذه المقايضة منذ الإصدارات الأولى لـ DoH.

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

ماذا يعني هذا لمالكي النطاقات (Domain owners)

إذا كنت تدير نطاقًا تستهلكه المؤسسات - مثل تطبيق كخدمة (SaaS)، أو أداة تطوير، أو واجهة برمجة تطبيقات (API) - فإن الحقائق ذات الصلة هي:

ستقوم نسبة معينة من المستخدمين بتحليل نطاقك من خلال نقطة نهاية DoH عامة، خاصة على الأجهزة غير المدارة أو المتصفحات المهيأة بشكل صريح. يجب أن تعمل سلاسل CNAME، وتفويضات النطاقات الفرعية (subdomain delegations)، وأي حيل ذكية في DNS تقوم بها من أجل التخصيص بشكل مماثل تمامًا عند تحليلها من محلل عام عشوائي كما هو الحال عند تحليلها من محلل داخلي لعميلك.
إن التحايل على الرقابة القائمة على DNS هو حالة استخدام حقيقية لـ DoH. إذا تم حظر نطاقك بواسطة مرشح (filter) DNS حكومي (كما حدث لعدة نطاقات للمراسلة المشفرة والشبكات الافتراضية الخاصة)، فسيتمكن المستخدمون من الوصول إليك عبر DoH من محلل عام. الآليات هي نفسها؛ لكن الرهانات السياسية مختلفة.
لا ينبغي أبدًا أن يحلل split-horizon الداخلي اسمًا موجهًا للجمهور (public-facing) إلى شيء ذو مغزى داخليًا فقط، بطريقة قد تتعطل إذا استعلم مستخدم عن طريق الخطأ عبر DoH. الفشل الكلاسيكي هو أن يعود النطاق الداخلي فقط app.example.com بـ IP خاص لا يمكن لأي مستخدم DoH الوصول إليه، ثم يجد موظف عن بُعد في فندق أن نفس اسم المضيف غير قابل للوصول ويقوم بالإبلاغ عن خطأ. استخدم نطاقًا داخليًا فقط ومنفصلاً بوضوح (مثل app.example.internal).

دور Namefi في هذا السياق

تتعامل Namefi مع DNS على أنه مستوى التحكم الموجه للجمهور (public-facing control plane) - وهو المكان الذي تلتقي فيه الأسماء العالمية بالسياسة المحلية. تفترض مسارات عمل DNS لدينا أن الاستعلامات يمكن أن تأتي من أي محلل، بما في ذلك نقاط نهاية DoH التي لا يمكننا حصرها، والأسماء التي ننشرها تعمل بشكل متسق بغض النظر عن ذلك. بالنسبة للعملاء الذين يديرون split-horizon داخليًا، فإننا نقف في الجانب العام: الإجابة الموثوقة (authoritative answer) لـ example.com هي ما نقدمه نحن، وما يتجاوزه المحلل الداخلي (overrides) للمستخدمين الداخليين هو شأن بينهم وبين سياسة الجهاز الطرفي الخاص بهم.

النقطة الأهم هنا: إن DNS المشفر وُجد ليبقى، وكذلك الحال بالنسبة لمراقبة الشبكات المؤسسية (enterprise visibility). والطريقة للتوفيق بينهما لا تتمثل في محاربة المعايير القياسية، بل في نقل نقطة فرض السياسات من الشبكة إلى نظام التشغيل. وقد اتفقت الهيئات المعنية بالمعايير القياسية، وشركات Microsoft وApple وGoogle وMozilla على هذا الحل. والعمل المتبقي هو في الغالب عمل تشغيلي.

المصادر وقراءات إضافية

IETF — DNS عبر HTTPS، RFC 8484 وDNS عبر TLS، RFC 7858.
Chrome Enterprise — عناصر التحكم في سياسة DoH.
Mozilla — برنامج المحلل العودي الموثوق (Trusted Recursive Resolver)، وسلوك نطاق الاختبار (canary domain)، وإرشادات التراجع عن split-horizon.
Chromium — نموذج الترقية التلقائية لـ DoH لنفس المزود في Chrome.
Microsoft — تكوين DNS عبر HTTPS في Windows.
EFF — يمكن أن يساعد DNS المشفر في سد واحدة من أكبر فجوات الخصوصية على الإنترنت.