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

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 هو إصدار بروتوكول مخطط البيانات لـ 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[Wi-Fi]
    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 المشفر. تدعم المتصفحات التي تعمل بنواة 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. تتطلب هذه القدرة التكيفية تنفيذ مقدم الخدمة، لكن مقدمي الخدمات الرئيسيين قاموا بتنفيذ ذلك بشكل عام.

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

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

• ←السابق
• التالي→