Почему шифрованный DNS всё ещё можно заблокировать

Представьте, что вы купили дорогой замок, но ключ к нему спрятан там, где его может перехватить кто угодно. Именно так обстоит дело с современными протоколами защищённого DNS.

DoH и DoT действительно шифруют запросы к DNS-серверам. Это должно было защитить пользователей от подмены ответов и слежки со стороны провайдеров. Но шифрование бесполезно, если пользователь не может получить сам ключ для установления защищённого соединения.

Как цензура эволюционировала

Раньше блокировали сайты напрямую. Теперь цензоры поняли, что проще помешать получить ключ к шифрованию, чем ломать само шифрование.

В 2021 году пользователи из Китая заметили странное поведение: DoH-запросы то проходили, то отваливались на несколько минут. Серверы были доступны, но соединение периодически рвалось. Оказалось, что файрвол научился временно блокировать IP-адреса известных DoH-провайдеров. Одного запроса хватало, чтобы триггернуть блок на пару минут — и так по кругу. В итоге сервис становился непригодным для использования.

При этом разные типы DNS трактуются по-разному:

• обычный DNS травят фейковыми IP-адресами,
• DoT на порту 853 блокируют полностью,
• DoH на 443 просто «душат» короткими блокировками.

Архитектурная проблема

Чтобы использовать ECH и скрывать SNI в TLS-запросе, браузеру сначала нужно получить публичный ключ через DNS. Получается замкнутый круг: чтобы зашифровать DNS-запрос, нужно сначала сделать DNS-запрос, который могут перехватить.

Мы построили систему, где ключи лежат в DNS, но доступ к DNS можно контролировать на уровне сети. И тогда вся защита рассыпается.

Что это значит для разработчиков

Если вы управляете инфраструктурой и используете DNS-записи, важно понимать три вещи:

1. Ваши записи могут быть недоступны в некоторых регионах.
2. Шифрование защищает только сам запрос, но не решает проблему доставки ключей.
3. Современная цензура редко отключает сервис полностью — ей достаточно создать неудобства.

Как пытаются решить проблему

Сейчас обсуждают несколько подходов:

• децентрализованную дистрибуцию ключей через DNSSEC или блокчейн,
• маскировку DoH-трафика под обычный HTTPS,
• anycast-сети, чтобы усложнить точечные блокировки,
• встраивание ключей прямо в приложение.

Ни один из этих методов не идеален. Все они добавляют сложности, влияют на скорость или требуют дополнительных настроек.

Главный вывод

Защита приватности не работает в вакууме. Она зависит от того, кто контролирует сеть между пользователем и сервером. Поэтому при проектировании доменной инфраструктуры или API нужно думать не только о шифровании, но и о том, как пользователь вообще получит доступ к ключам.