DNS поверх TLS вместе с VPN: какая часть защищена

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

Четыре проверки решают, та ли у вас схема, о которой вы думаете.

Проверка 1: что покрывает шифрование

DoT заворачивает обмен DNS в TLS, поэтому наблюдатель на пути видит подключение к адресу и порту, а не имя в запросе. Сам резолвер расшифровывает и отвечает. Сравните с DNS поверх HTTPS: оба шифруют, и они используют разные транспорты, поэтому сеть, разрешающая веб-трафик, не разрешает автоматически соединение DoT.

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

Проверка 2: по какому маршруту идёт запрос

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

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

Проверка 3: внутренние имена

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

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

Проверка 4: поведение при сбое

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

Запасной вариант, который молча использует обычный DNS, — это решение политики, а не удобство. Решите, должен ли сбой быть видимым или должен приводить к чему-то более слабому, и запишите ответ.

Доверяйте сертификату, а не ответу

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

Ответ от резолвера, который вы не можете аутентифицировать, — это утверждение, а не результат.

Что это оставляет необъяснённым

DoT не скрывает имя от резолвера, не скрывает адрес назначения соединения от сети и не решает, шёл ли запрос через туннель. Это три отдельных вопроса с тремя отдельными ответами.

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