DNSSEC или VPN: что скрывает ваши DNS-запросы?

Два механизма получают одну и ту же задачу, и ни один из них её не выполняет. DNSSEC отвечает, действительно ли полученные данные пришли из зоны, которая их публикует, а VPN решает, какой путь пройдут ваши пакеты. Ни один из них не скрывает во всех случаях имя, которое вы запросили, а настройки, которые выглядят так, будто должны это делать, обычно касаются транспорта или маршрутизации, а не валидации. Если сначала назвать уровень, расплывчатый вопрос о приватности становится конкретным.

Три утверждения, сливающиеся в одно

Подлинность — это утверждение, что ответ именно тот, который опубликовала зона, и что он не был изменён по пути. Конфиденциальность — это утверждение, что никто на пути не может прочитать запрос или ответ. Маршрутизация — это утверждение, что пакеты идут выбранным вами путём, и именно это даёт туннель.

DNSSEC занимается первым и ничего не говорит о двух других. DoT и DoH занимаются вторым для участка до резолвера. VPN занимается третьим и может влиять и на второе, но только как побочный эффект того, куда идёт трафик.

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

Что может и чего не может валидация подписей

Валидирующий резолвер проверяет цепочку подписей от зоны до настроенного якоря доверия, а затем возвращает ответ с установленным флагом аутентифицированных данных, когда проверка проходит. Этот флаг — доказательство о данных, а не о соединении или намерениях пункта назначения.

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

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

Откуда на самом деле берётся конфиденциальность

Шифрованный транспорт до резолвера упаковывает обмен DNS в TLS, поэтому резолвер по-прежнему видит вопрос, а путь между вами и им — нет. Это переносит доверие, а не убирает его: вы больше доверяете резолверу и меньше — локальной сети.

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

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

Проверяйте валидацию и транспорт отдельно

Два теста снимают большую часть путаницы. Первый спрашивает, валидировал ли резолвер ответ; второй — был ли защищён транспорт. Они отказывают по-разному, и ни один не подразумевает другой.

Эти команды печатают флаги валидирующего запроса, повторяют запрос с отключённой проверкой и запускают локальную валидацию с помощью delv:

dig +dnssec example.com | grep flags
dig +cd example.com | grep status
delv example.com

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

Что делать, когда VPN ломает разрешение имён

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

Глобальное отключение валидации — неверный первый шаг, потому что оно убирает единственный механизм, сообщающий о подмене, и не исправляет недоступный резолвер. Сначала сузьте неисправность: разрешение, транспорт, валидация, затем политика. Только третье относится к DNSSEC, и только второе — к шифрованному транспорту.