Широкое распространение стандартов шифрования доменных имен, таких как DNS-over-HTTPS (DoH, RFC 8484) и DNS-over-TLS (DoT, RFC 7858), стало важной вехой в борьбе за конфиденциальность пользователей. Эти технологии защитили канал между клиентским устройством и рекурсивным резолвером, лишив интернет-провайдеров и посторонних наблюдателей в открытых сетях Wi-Fi возможности перехватывать запросы DNS, передаваемые открытым текстом через порт UDP 53.

Тем не менее классический DoH породил новый парадокс конфиденциальности: критически важная информация оказалась сосредоточена в руках операторов публичных резолверов. При отправке запроса в централизованные сервисы (такие как Cloudflare, Google Public DNS или Quad9) одна организация одновременно узнает:

  1. Кто запрашивает: реальный публичный IP-адрес клиента.
  2. Что запрашивается: точное доменное имя посещаемого ресурса.

Чтобы решить эту проблему, инженерная группа IETF разработала спецификацию Oblivious DNS over HTTPS (ODoH, RFC 9230) и смежный стандарт Oblivious HTTP (OHTTP, RFC 9458). Несмотря на математическую изощренность разделения личности клиента и содержания запроса, вокруг ODoH возникло заблуждение, будто этот механизм способен полноценно заменить виртуальную частную сеть (VPN).

Глубокий разбор протокола показывает, почему разделение ролей на уровне резолвера защищает DNS, но оставляет беззащитным последующий веб-трафик при отсутствии туннеля сетевого уровня.

Архитектура Oblivious DoH: разрыв связи между адресом и запросом

Базовый постулат Oblivious DoH звучит просто: ни один сетевой субъект не должен обладать одновременно информацией о личности пользователя и об имени запрашиваемого домена.

Для разделения этих сведений RFC 9230 вводит трехстороннюю модель, включающую Клиента, Промежуточный узел (Relay) и Целевой резолвер (Target):

[ Клиентское устройство ]
           |
           | 1. Отправка HPKE-зашифрованного запроса
           v
[ Узел-ретранслятор ODoH Relay ] (Видит IP клиента, не может прочесть запрос)
           |
           | 2. Удаление IP клиента, пересылка шифротекста
           v
[ Целевой резолвер ODoH Target ] (Расшифровывает запрос, видит домен, не знает IP)
           |
           | 3. Разрешает DNS, шифрует ответ ключом сессии
           +-----> Возврат через Relay -----> Клиентское устройство

1. Гибридное шифрование с открытым ключом (HPKE)

Перед отправкой запроса клиент получает открытый конфигурационный ключ целевого сервера (odohconfig) через проверенные каналы обнаружения HTTPS.

С помощью стандарта HPKE (RFC 9180) клиент инкапсулирует бинарный запрос DNS в сессионный симметричный ключ, полученный на основе открытого ключа Target. Этот зашифрованный пакет направляется на узел Relay.

2. Функция слепой пересылки (Relay)

Узел Relay принимает зашифрованный пакет по протоколу HTTPS. Не имея закрытого ключа Target, Relay принципиально не способен расшифровать полезную нагрузку.

Его задача состоит в том, чтобы очистить сетевой пакет от исходного IP-адреса клиента, подставить свой собственный IP-адрес и направить непрозрачный блок данных на сервер Target.

3. Обработка на целевом резолвере (Target)

Сервер Target получает пакет с IP-адреса Relay и не имеет никаких сведений об исходном пользователе.

Используя свой закрытый ключ, Target расшифровывает запрос, выполняет стандартное рекурсивное разрешение имени, шифрует полученный ответ в рамках установленного криптографического контекста HPKE и отправляет его обратно через узел Relay.

В результате Relay знает, кто обратился, но не знает, куда; Target знает, какой домен запрашивается, но не знает, кем.

Ограничения ODoH в реальных сетевых условиях

Хотя ODoH безупречно решает проблему изоляции DNS-запроса, анализ полного сетевого стека выявляет существенные пробелы в общей модели безопасности:

1. Утечка IP-адреса при основном веб-соединении

Запрос DNS — это лишь подготовительный этап. Как только клиент получает IP-адрес сервера назначения через ODoH, операционная система устанавливает прямое TCP- или QUIC-соединение с веб-сайтом.

В этот момент реальный IP-адрес клиента без всяких искажений передается на сервер назначения. Более того, если целевой ресурс не настроил расширение Encrypted Client Hello (ECH), имя домена передается открытым текстом в поле SNI.

Таким образом, ODoH скрывает ваши намерения от резолвера DNS, но конечный веб-сервер, рекламные трекеры и местный провайдер по-прежнему фиксируют весь обмен данными.

2. Зависимость от отсутствия сговора между узлами

Криптографическая стойкость RFC 9230 строится на предположении, что операторы Relay и Target действуют независимо и не обмениваются служебными журналами.

Если оба узла принадлежат одной телекоммуникационной группе или координируют метаданные, сопоставление временных меток и размеров пакетов позволяет мгновенно деанонимизировать пользователя.

3. Рост задержки и географическая дезориентация

Маршрутизация через два независимых сетевых узла увеличивает время кругового обращения (RTT). Обычный запрос DoH требует одной сетевой транзакции, тогда как ODoH проходит через две автономные системы.

Кроме того, поскольку целевой резолвер видит только IP-адрес узла Relay, он не может использовать расширение EDNS Client Subnet (ECS) без нарушения конфиденциальности. В результате авторитетные серверы могут возвращать IP-адреса CDN, оптимизированные для дата-центра Relay, а не для физического местоположения клиента, что снижает скорость загрузки сайтов и потокового видео.

Техническое сравнение протоколов DNS и туннелирования Layer 3

Разница между прикладным проксированием (Layer 7) и полной инкапсуляцией сетевого уровня (Layer 3) представлена в таблице:

Критерий оценки Открытый DNS (UDP 53) Стандартный DoH (RFC 8484) Oblivious DoH (RFC 9230) Туннель VPN Layer 3 (RiceGuard)
Перехват местным провайдером Открытый текст Зашифровано Зашифровано Защищено внутри туннеля
Резолвер видит IP клиента Да (прямой IP) Да (прямой IP) Нет (только IP Relay) Нет (только IP шлюза VPN)
Резолвер видит текст запроса Да (открыто) Да (в памяти сервера) Да (после расшифровки) Только внутренний Loopback
Защита основного веб-трафика Нет (только DNS) Нет (только DNS) Нет (только DNS) Да (полная защита всех пакетов)
Веб-сайт видит реальный IP Да (реальный адрес) Да (реальный адрес) Да (реальный адрес) Нет (скрыт шлюзом VPN)
Накладные расходы по задержке Минимальные (1 UDP) Низкие (1 TLS) Заметные (2 автономных узла) Минимальные (прямой Layer 3)
Стойкость к локальному DPI Отсутствует Только запросы DNS Только запросы DNS Полная маскировка трафика

Почему настоящая приватность требует изоляции третьего уровня

Попытки выстроить сетевую защиту путем соединения разрозненных протоколов прикладного уровня (DoH, ODoH, браузерные прокси) оставляют множество уязвимостей. Вспомогательные системные пакеты — широковещательный трафик, сообщения ICMP, служебные обновления ОС и сессии приложений — продолжают транслироваться в открытом виде.

Полноценная виртуальная частная сеть третьего уровня Layer 3 решает задачу комплексно:

  1. Единая маскировка сетевых пакетов: Все исходящие данные — от запросов доменных имен до загрузки тяжелых файлов — упаковываются в новые зашифрованные пакеты, направляемые исключительно к шлюзу VPN.
  2. Локальное разрешение имен на узле выхода: В инфраструктуре RiceGuard рекурсивное разрешение DNS происходит на внутреннем интерфейсе loopback выходного шлюза VPN. Запросы DNS не покидают защищенный контур и не передаются сторонним сервисам, что исключает утечки и устраняет задержки двухзвенных схем.
  3. Защита на уровне всей операционной системы: В отличие от ODoH, требующего специальной поддержки в отдельных программах, туннель Layer 3 перехватывает трафик через виртуальный сетевой адаптер ядра (tun/tap), гарантируя безопасность системных утилит, фоновых служб и мобильных приложений.

Интеграция передовых стандартов в VPNRice

Протоколы класса ODoH являются важным технологическим достижением, однако практическая конфиденциальность в интернете строится на системной изоляции всего сетевого стека.

Архитектура VPNRice объединяет сетевую безопасность и криптографическую защиту:

На физическом уровне протокол RiceGuard инкапсулирует пользовательский трафик с использованием стойкого шифрования ChaCha20-Poly1305. Местные провайдеры и наблюдатели в сетях Wi-Fi видят только однородный зашифрованный поток UDP-пакетов к защищенным серверам Anycast.

Все системные запросы DNS автоматически направляются внутрь туннеля и обрабатываются собственными рекурсивными резолверами VPNRice без ведения логов. Маскируя IP-адрес пользователя как для этапа разрешения DNS, так и для всех последующих веб-соединений, VPNRice обеспечивает защиту данных на уровне всей сетевой инфраструктуры. Скачать VPNRice.