DNS в обходе блокировок: первый шаг и первая утечка

Разрешение имени происходит до соединения и рассказывает о намерении раньше, чем начнётся защита. Три роли DNS, тихий откат к открытым запросам и где разрешать имя.

2026-08-31 GIGATAP Team #vpn
#vpn#anticensorship#dns#doh#privacy#leaks

DNS в обходе блокировок: первый шаг и первая утечка

У любого соединения по имени есть шаг, который делается до самого соединения: превращение имени в адрес. Разберём три роли, которые этот шаг играет одновременно, где именно должно происходить разрешение имени и почему тихий откат к открытым запросам обесценивает настройку в самый неподходящий момент.

Этот шаг обычно не рассматривают как часть защиты. Зря: он происходит раньше, чем включается всё остальное, и потому способен рассказать о намерении до того, как появится что скрывать.

Три роли, которые DNS играет одновременно#

Их полезно разделять, потому что защищаются они по-разному.

Утечка намерения. Запрос имени говорит, куда вы собираетесь, за доли секунды до того, как пойдёте.

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

Точка отказа. Если разрешение имени не работает, не работает ничего — независимо от того, насколько хорош транспорт.

имя ──► [ DNS ] ──► адрес ──► [ соединение ] ──► данные
         ↑                        ↑
    видно, подменяемо        защищено
    происходит первым        происходит потом

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

Что даёт шифрование запросов?#

Шифрование DNS убирает первую роль — содержимое запроса перестаёт быть видимым посреднику — и сильно осложняет вторую: подменить зашифрованный ответ нельзя.

Но появляются новые свойства, о которых говорят реже.

Свойство Открытый DNS Зашифрованный DNS
Имя видно посреднику да нет
Ответ можно подменить да нет
Виден адрес резолвера да да
Резолвер видит все запросы да да
Резолвер можно заблокировать да да

Три строки не изменились. Шифрование переносит доверие с сети на резолвер, а не устраняет его. И адрес резолвера остаётся видимым — то есть виден сам факт обращения к нестандартному разрешению имён, даже когда содержимое закрыто.

Тихий откат — главная практическая проблема#

Здесь класс ошибок, который встречается чаще остальных вместе взятых.

Большинство клиентов при недоступности защищённого резолвера переключаются на обычный — молча, без уведомления, чтобы «не сломать интернет пользователю».

НОРМА                      ПРИ ПОМЕХЕ
клиент ──► защищённый DNS  клиент ──► защищённый DNS  ✗
             │                          │
             ✓ имя скрыто               └──► обычный DNS  ✓
                                              │
                                              └── имя открыто
                                                  пользователь не уведомлён

Свойство приватности исчезает ровно тогда, когда оно нужнее всего: помеха, из-за которой не отвечает защищённый резолвер, чаще всего и есть та самая помеха, от которой защищались.

Проверка, которую стоит сделать один раз: заблокировать защищённый резолвер и посмотреть, продолжает ли работать разрешение имён. Если продолжает — откат есть, и он тихий.

Где должно происходить разрешение#

Отдельный вопрос, специфичный для туннелей, и он определяет, есть ли утечка вообще.

Схема Кто разрешает имя Что видит локальная сеть
Разрешение на устройстве клиент до туннеля имя назначения
Разрешение на выходе сервер на той стороне только адрес сервера

В первой схеме соединение идёт через туннель, но имя было запрошено раньше и снаружи. Защита есть, утечка тоже.

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

Утечка мимо туннеля#

Смежный и очень частый случай: часть запросов уходит мимо, даже когда всё настроено.

Причины типичны: системный резолвер прописан жёстко на уровне сети; отдельное приложение использует собственный резолвер; корпоративная политика перенаправляет запросы; при переключении сети настройки восстанавливаются к стандартным.

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

Числовой пример#

Одно подключение к одному ресурсу. Смотрим, что видит наблюдатель в локальной сети при четырёх конфигурациях.

Конфигурация Видит имя Может подменить Видит адрес
Открытый DNS, разрешение локально ✗ да ✗ да ✗ да
Зашифрованный DNS, разрешение локально ✓ нет ✓ нет ✗ да
Зашифрованный DNS с тихим откатом, помеха ✗ да ✗ да ✗ да
Разрешение на выходе туннеля ✓ нет ✓ нет ✓ только сервер

Третья строка — та же конфигурация, что и вторая, в условиях помехи. Она даёт результат первой. Это и есть цена тихого отката: настройка выглядит защищённой и перестаёт быть таковой ровно под нагрузкой.

Четвёртая строка — единственная, где не видно ни имени, ни адреса назначения.

Связь с шифрованием имени в рукопожатии#

Стоит отметить зависимость, которую легко упустить.

Механизм, шифрующий имя сайта внутри TLS-рукопожатия, берёт ключ из DNS. Значит, при незащищённом или подменяемом разрешении имён он либо утекает через запрос ключа, либо тихо не включается.

Это делает порядок внедрения однозначным: сначала защищённое разрешение имён, потом всё, что на него опирается. Обратный порядок даёт видимость свойства без самого свойства.

Практический список проверок#

Куда реально уходят запросы. Не что написано в настройках, а что уходит по проводу.

Есть ли тихий откат. Заблокировать защищённый резолвер и посмотреть, что произойдёт.

Где разрешается имя при активном туннеле. Локально или на той стороне.

Совпадают ли ответы. Разные адреса на одно имя при разных способах проверки — признак подмены или утечки.

Что происходит при смене сети. Переключение часто восстанавливает системные настройки.

Вывод#

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

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

Термины#

  • Резолвер - служба, превращающая имя в адрес; при шифровании запросов доверие переносится именно на неё.
  • Тихий откат - молчаливое переключение на открытые запросы при недоступности защищённого резолвера.
  • Разрешение на выходе - схема, при которой имя превращается в адрес на дальней стороне туннеля, а не на устройстве.

FAQ: частые вопросы#

Убирает ли шифрование DNS необходимость доверия?#

Нет. Оно переносит доверие с сети на резолвера, а адрес самого резолвера остаётся видимым.

Как проверить наличие тихого отката?#

Заблокировать защищённый резолвер и посмотреть, продолжает ли работать разрешение имён. Если продолжает — откат есть.

Где должно происходить разрешение имени?#

Там, где начинается доверенный участок. Разрешение на устройстве раскрывает имя назначения до того, как заработает туннель.

Что читать дальше#