Сравнительный анализ технологий 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, то по сути DoH превращается в 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, но на транспортном уровне предоставляет orientated на соединение сервис. 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 over HTTP/2"]
        direction LR
        H1[TCP] --> H2[TLS]
        H2 --> H3[HTTP/2]
        H3 --> H4[DNS]
    end
    
    subgraph DoH3["DoH over 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. На самом деле сервис DoH может предоставляться на любом порту; на Android для этого требуются сторонние приложения, а iOS нативно поддерживает DoT на любом порту.

Масштабируемость — важное преимущество DoH. По сравнению с DNS, инкапсулированным в HTTP, и Plain DNS, HTTP имеет явно лучшую масштабируемость. Поставщики услуг могут предоставлять бесчисленное множество сервисов на порту 443, включая DoH, и удобно расширять функционал. DoT и DoQ обычно требуют монопольного использования порта, и их возможности расширения полностью базируются на Plain DNS. Это различие с точки зрения поставщика услуг; для обычных пользователей пока нет явной разницы.

С точки зрения скорости обработки DNS-запросов, HTTP действительно может быть медленнее Plain DNS на несколько тактов процессора, но в реальном использовании этой разницей можно пренебречь. В плане совместимости 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. Эта адаптивная способность должна быть реализована поставщиком услуг, однако основные поставщики обычно это делают.

Рекомендую попробовать 宁屏; он поддерживает DoT и DoH/3, а также имеет встроенные функции блокировки рекламы и разделения DNS-трафика. Если необходимо собственное развертывание, можно использовать его открытую библиотеку.

Выбор сетевого протокола требует комплексного учета множества факторов, включая качество сети оператора, поддержку поставщиком услуг и совместимость устройств. Для большинства пользователей DoH является отличным выбором, балансирующим производительность, совместимость и защиту конфиденциальности.

• ←Предыдущий
• Следующий→