تحليل مقارنة تقنيات DoH و DoT

تحليل متعمق للتنفيذ التقني واختلافات الأداء وسيناريوهات الاستخدام لـ DNS over HTTPS و DNS over TLS من منظور بروتوكولات الشبكة

DNS over HTTPS (DoH) و DNS over TLS (DoT) هما طريقتان شائعتان لنقل DNS المشفر، حيث تحققان النقل الآمن لاستعلامات DNS عبر أكوام بروتوكولية مختلفة. تم تحديد معيار DoT بواسطة RFC 7858، بينما تم توحيد DoH بواسطة معيار DNS Queries over HTTPS (DoH). لفهم الفروق الجوهرية بين هاتين التقنيتين، يجب البدء من تحليل هيكل طبقات بروتوكول الشبكة.

هيكل طبقات بروتوكول الشبكة

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

طبقة التطبيق (L7) تحتوي على بروتوكولات مثل HTTP/1.1 و HTTP/2 و HTTP/3 و FTP و DNS. تجدر الإشارة إلى أن دلالات HTTP/3 لا تزال في طبقة التطبيق، بينما يعمل QUIC كنقل حمل. تقع طبقة الأمان بين طبقة التطبيق وطبقة النقل، وتشمل بشكل أساسي TLS ومتغيراته. يعمل TLS عادةً فوق TCP، مثل HTTPS و DoT. DTLS هو إصدار Datagram الخاص بـ TLS ويمكن أن يعمل فوق UDP. بروتوكول QUIC خاص نسبيًا، حيث يدمج مصافحة TLS 1.3 واشتقاق المفاتيح مباشرة داخل البروتوكول.

يمكن اعتبار QUIC بروتوكول طبقة L4.5، فهو يمتد بناءً على UDP ويوفر قدرات طبقة النقل التقليدية. تحتوي طبقة النقل (L4) على TCP و UDP و QUIC. على الرغم من أن QUIC مبني على UDP من منظور التنفيذ الهندسي، إلا أنه يتميز بالموثوقية والتحكم في الازدحام والتعدد المتعدد ومصافحة التشفير، لذا يتم التعامل معه هندسيًا كبروتوكول طبقة نقل مستقل. تستخدم طبقة الشبكة (L3) بروتوكول IP (IPv4/IPv6) المسؤول عن توجيه وإعادة توجيه الحزم. تشمل طبقة وصل البيانات (L2) تقنيات مثل Ethernet و Wi-Fi (802.11).

يعمل TLS كوسيلة تشفير بين طبقة التطبيق وطبقة النقل. إذا تمت إزالة تشفير TLS من DoT، فإن DoT يتحول جوهريًا إلى DNS over TCP. يسمح هذا التصميم المتعدد الطبقات بأن يكون التشفير خيارًا، وليس قيدًا إلزاميًا للبروتوكول نفسه.

خصائص Plain DNS

يُطلق على أبسط أنواع DNS اسم Plain DNS، ويمكن أن يعمل عبر UDP أو TCP. UDP هي طريقة النقل الأكثر شيوعًا بسبب بساطة إنشاء الاتصال وسرعة الاستعلام الأول. ولكن ضعف UDP هو عدم الموثوقية، حيث يسهل فقدان الحزم في الشبكة. على الرغم من أن TCP يتطلب عددًا أكبر من المصافحات وسرعة الاتصال الأولي أبطأ بحوالي 30% من UDP، إلا أن سرعة الاستجابة تصبح مماثلة لـ UDP بعد إنشاء اتصال طويل.

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

تداخل طبقة التطبيق

يعمل كل من DNS و HTTP كبروتوكولات طبقة تطبيق، و DoH هو في جوهره بروتوكول طبقة تطبيق متداخل داخل بروتوكول طبقة تطبيق آخر. DoH ليس بالضرورة DNS over HTTPS؛ استخدام HTTP العادي ممكن أيضًا، ولكن DoH غير المشفر هو طلب بنص واضح ولا يقدم أي ميزة مقارنة بـ Plain DNS، وتستخدمه سوى عدد قليل جدًا من سيناريوهات المتطلبات الخاصة.

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

flowchart TD
    subgraph L7["طبقة التطبيق"]
        A[DNS]
        B[HTTP]
        C[FTP]
    end
    
    subgraph Security["طبقة الأمان"]
        D[TLS]
        E[DTLS]
    end
    
    subgraph Transport["طبقة النقل"]
        F[TCP]
        G[UDP]
        H[QUIC]
    end
    
    subgraph L3["طبقة الشبكة"]
        I[IP]
    end
    
    subgraph L2["طبقة وصل البيانات"]
        J[Ethernet]
        K[WiFi]
    end
    
    A --> D
    B --> D
    C --> D
    D --> F
    E --> G
    H --> G
    F --> I
    G --> I
    H --> I
    I --> J
    I --> K
    
    style A fill:#e1f5ff
    style B fill:#e1f5ff
    style C fill:#e1f5ff
    style D fill:#fff4e1
    style E fill:#fff4e1
    style F fill:#ffe1e1
    style G fill:#ffe1e1
    style H fill:#e1ffe1

تداخل طبقة النقل

بروتوكول QUIC مبني على UDP ويوفر خدمات موجهة نحو الاتصال في طبقة النقل في نفس الوقت. يحقق QUIC قدرات طبقة النقل مثل الاتصال الموجه، والتحكم في الازدحام، وإعادة الإرسال، والتحكم في التدفق، والتقسيم والتجميع الموجودة في TCP. مقارنة بـ TCP، يكون لـ QUIC تأخير أقل. مقارنة بـ UDP، QUIC أكثر تقدمًا وموثوقية.

علاقات تركيب البروتوكول

لا توجد علاقة قيود حتمية بين طبقة التطبيق وطبقة النقل، ويمكن إضافة التشفير أو عدمه. يمكن لـ HTTP العمل عبر TCP، كما يمكنه العمل عبر QUIC. يمكن لـ DNS العمل عبر TCP، أو عبر UDP، أو عبر QUIC.

بناءً على هذه الاحتمالات، يمكن تلخيص علاقات التركيب التالية. Plain DNS يساوي UDP أو TCP بالإضافة إلى بروتوكول DNS. HTTP/2 يساوي TCP بالإضافة إلى TLS 1.2 أو TLS 1.3 ثم بروتوكول HTTP. HTTP/3 يساوي QUIC بالإضافة إلى TLS 1.3 ثم بروتوكول HTTP.

DoH (DNS over HTTPS) يساوي HTTP/2 أو HTTP/3 بالإضافة إلى بروتوكول DNS. DoT (DNS over TLS) يساوي TCP بالإضافة إلى TLS 1.2 أو TLS 1.3 ثم بروتوكول DNS. DoQ (DNS over QUIC) يساوي QUIC بالإضافة إلى TLS 1.3 ثم بروتوكول DNS.

flowchart LR
    subgraph DoT["DoT DNS over TLS"]
        direction LR
        T1[TCP] --> T2[TLS]
        T2 --> T3[DNS]
    end
    
    subgraph DoH2["DoH عبر HTTP/2"]
        direction LR
        H1[TCP] --> H2[TLS]
        H2 --> H3[HTTP/2]
        H3 --> H4[DNS]
    end
    
    subgraph DoH3["DoH عبر HTTP/3"]
        direction LR
        Q1[QUIC] --> Q2[TLS 1.3]
        Q2 --> Q3[HTTP/3]
        Q3 --> Q4[DNS]
    end
    
    subgraph DoQ["DoQ DNS over QUIC"]
        direction LR
        D1[QUIC] --> D2[TLS 1.3]
        D2 --> D3[DNS]
    end
    
    style T1 fill:#e3f2fd
    style T2 fill:#fff3e0
    style H1 fill:#e3f2fd
    style H2 fill:#fff3e0
    style Q1 fill:#e8f5e9
    style Q2 fill:#fff3e0
    style D1 fill:#e8f5e9
    style D2 fill:#fff3e0

تحليل الأداء والتوافق

بعد فهم هيكل طبقات البروتوكول، يمكن تحليل مزايا وعيوب DoH و DoT.

يجب مناقشة مقارنة TCP و QUIC بالاقتران مع بيئة الشبكة الفعلية للمزود. QUIC هو بروتوكول أحدث يحل بعض مشاكل الشبكات القديمة، لكنه مبني على UDP في النهاية. من منظور زمن الشبكة، يكون التأخير للبروتوكولات المبنية على QUIC أقل بحوالي 35% من TCP، لذا فإن DNS over HTTP/3 و DoQ (DNS over QUIC) يعتبران نظريًا أداءً أفضل من DNS over HTTP/2 و DoT.

ومع ذلك، في بيئة الشبكة الفعلية، توجد مشكلة تأخير إعادة الإرسال الناتجة عن فقدان الحزم. قد تختار مزودات الخدمة إسقاط حزم UDP عندما تكون الشبكة مشغولة، وسيتم تحديد QUIC كـ UDP وإسقاطه. على الرغم من أن QUIC يدعم إعادة الإرسال، إلا أن التأخير الناتج عن إعادة الإرسال قد يؤدي إلى أن يكون التأخير الفعلي لـ QUIC أعلى من TCP.

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

القابلية للتوسع هي ميزة مهمة لـ DoH. مقارنة بـ DNS المغلف بـ HTTP و Plain DNS، يتمتع HTTP بقدرة توسع أفضل بكثير. يمكن لمقدمي الخدمات توفير عدد لا يحصى من الخدمات على المنفذ 443، بما في ذلك DoH، ويمكنهم توسيع الوظائف بسهولة. تتطلب DoT و DoQ عادة منافذ حصرية، وقدرة التوسع تعتمد كليًا على Plain DNS. هذا هو الفرق من منظور مقدم الخدمة، ولا يوجد إدراك واضح للمستخدمين العاديين في الوقت الحالي.

من حيث سرعة معالجة طلبات DNS، قد تكون سرعة معالجة HTTP أبطأ فعليًا بعدة دورات ساعة وحدة المعالجة المركزية مقارنة بـ Plain DNS، ولكن هذا الاختلاف يمكن إهماله في الاستخدام الفعلي. من حيث التوافق، قد يكون DoH هو التيار الرئيسي لأن قابلية التوسع لـ DoH جيدة لمقدمي الخدمة.

تختلف دعم المنصات السائدة حاليًا لـ DNS المشفر. متصفحات kernel Chromium تدعم DoH. نظام Windows 11 يدعم DoH بشكل أصلي. نظام Android 8 وما فوق يدعم DoT بشكل أصلي. نظام Android 11 وما فوق يدعم DoT و DoH بشكل أصلي. نظام macOS يدعم DoT و DoH بشكل أصلي. نظام iOS يدعم DoT و DoH بشكل أصلي.

توصيات الاختيار الفعلي

بالنسبة للمستخدمين العاديين، استخدام DoH سيكون أقل إزعاجًا من DoT. مقارنة بـ DoT، يوفر DoH تأخيرًا أفضل معظم الوقت، وتأخيرًا مماثلاً لفترات قليلة. مقارنة بـ DoQ، يتمتع DoH بتأخير مماثل معظم الوقت، ويوفر تأخيرًا أفضل لفترات قليلة.

شرط هذا الاستنتاج هو أن مقدم الخدمة يوفر خدمة DNS over HTTP/3. إذا لم يوفر مقدم الخدمة HTTP/3، فلا يوجد فرق واضح بين DoH و DoT. عندما تكون جودة الشبكة جيدة، سيستخدم DoH تلقائيًا DoH/3 للحصول على تأخير أقل، وعندما تكون جودة الشبكة رديئة، سينخفض تلقائيًا إلى HTTP/2. تتطلب هذه القدرة التكيفية التنفيذ من قبل مقدم الخدمة، على الرغم من أن مقدمي الخدمات السائدين قد حققوها بشكل عام.

يُنصح بتجربة 宁屏، فهو يدعم DoT و DoH/3، ويأتي مع حظر الإعلانات ووظيفة تقسيم DNS بشكل أصلي. إذا كنت بحاجة إلى النشر الذاتي، يمكنك استخدام مكتبتها المفتوحة المصدر.

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