Что именно проверяется
DNS отвечает на вопросы об именах, а не загружает саму страницу. Он может использовать другой компонент и настройки, чем соединение с сайтом. Поэтому проверка IP и проверка DNS решают разные задачи. Для полного VPN-туннеля ожидаемая политика одна, для корпоративного split DNS — другая. Сначала запишите, как должно быть в вашей конфигурации.
Пример: организация требует разрешать внутренние имена своим сервером, а публичные допускает через другой путь. Такой режим нельзя оценивать только лозунгом «все DNS должны принадлежать VPN». Напротив, личный full-tunnel клиент может обещать строго определённый резолвер. Утечкой следует называть нарушение понятного ожидания, а не любое отличие от картинки в инструкции.
Откуда берутся настройки
Резолвер может задаваться сетью, системой, VPN-клиентом или приложением. Браузер иногда использует DNS-over-HTTPS отдельно от системы. На телефоне может быть включён частный DNS. После сна, переключения сетей и восстановления туннеля приоритеты способны измениться, поэтому один тест сразу после установки не покрывает обычную эксплуатацию.
Не меняйте все источники одновременно. Запишите исходные значения и определите ответственный компонент. Если корпоративные имена перестали работать после включения публичного защищённого DNS, это может быть обычная несовместимость сценариев. Случайный резолвер из комментариев не обязан знать внутреннюю зону и не становится доверенным потому, что сайт после него открылся.
Что видит браузерный DNS-тест
Такой инструмент обычно создаёт специальные имена и смотрит, какие серверы запрашивают их разрешение. Он не читает полный список системных настроек и не отслеживает все приложения. Результат полезен как наблюдение, но у него есть границы. Разные проверки могут использовать разные имена, время ожидания и способы отображения операторов.
Сам тестовый сервис получает ваш запрос и сетевые сведения. Выбирайте известный инструмент и не вводите туда внутренние адреса, токены или личные поисковые фразы. Не нужно открывать десятки сайтов, сообщая каждому те же данные. Для сравнения до/после достаточно одного понятного метода, а системная диагностика помогает объяснить различие.
Пошаговое сравнение
Сначала проверьте исходный публичный адрес и DNS без VPN, если это безопасно и не нарушает вашу политику блокировки обхода. Включите клиент, дождитесь установленного соединения и повторите наблюдение тем же способом. Сохраните результат локально. Затем сверьте его с настройкой браузера и документацией клиента, не делая вывод только по названию компании в отчёте.
Если DNS идёт к стороннему DoH-резолверу, узнайте, как проходит HTTPS-соединение до него. Оно может находиться внутри VPN. Здесь есть два вопроса: кому доверен DNS и кто видит путь к резолверу. Они связаны, но не идентичны. Одно имя оператора отвечает на первый лишь частично и не устанавливает второй.
Проверка переходных состояний
Повторите тест после обычного сна и короткой смены сети. На телефоне сравните собственную Wi-Fi и мобильное подключение. Если используется split tunneling, проверьте приложения из разных групп. Браузерный тест не описывает программу, которую вы сознательно оставили вне туннеля.
При важном требовании запрета обхода отдельно испытайте Kill Switch на несекретной задаче. Не делайте это по единственной удалённой сессии. Переходное появление исходного резолвера требует повторной проверки и сопоставления со временем восстановления. Без этого легко спутать кэш, неполный тест и реальное нарушение политики.
Как исправлять подтверждённое несоответствие
Начните с поддерживаемых настроек клиента. Если документация требует согласованного системного DNS, настройте его штатным способом и проверьте результат. Если отдельный DoH конфликтует с корпоративными именами, согласуйте нужную политику с администратором. Не отключайте проверку сертификата и не устанавливайте неизвестный профиль ради одного успешного запроса.
Меняйте один компонент за раз и сохраняйте возможность возврата. На Linux ручная правка управляемого resolv.conf может исчезнуть после переподключения; на других системах тоже есть ответственный сетевой менеджер. Исправление должно переживать обычную смену сети и не ломать внутренние ресурсы. Временное улучшение без понимания причины — ещё не законченная настройка.
DoH, DoT и доверие
DNS-over-TLS и DoH защищают канал до выбранного резолвера. Они не скрывают вопрос от самого резолвера и не меняют автоматически IP выхода. Поэтому «зашифрованный DNS» не является синонимом «DNS строго следует VPN». Проверяйте конкретную цепочку и поведение при недоступности выбранного сервера.
Защищённый канал также не удостоверяет добросовестность оператора и не отменяет его политику хранения данных. DNSSEC решает ещё одну задачу — проверку подлинности DNS-данных, а не шифрование передачи. Разделение этих понятий помогает выбрать настройку по требованию, а не считать все технологии со словом secure взаимозаменяемыми.
Пример: в отчёте другой резолвер
Пользователь ожидает DNS оператора VPN, а тест показывает известный публичный сервис. Сначала он обнаруживает, что браузер настроен на DoH этого сервиса. Следующий вопрос — проходит ли HTTPS до резолвера через туннель и допустим ли такой получатель по выбранной политике. Это уже две конкретные проверки вместо автоматического вывода об утечке.
Если для рабочей задачи требуется корпоративный резолвер, даже защищённая передача к другому серверу может быть неподходящей. Если задача личная и политика допускает внешний DoH внутри VPN, оценка иная. Название компании в тесте не решает вопрос за пользователя. Нужно согласовать ожидаемого получателя, путь и поведение при недоступности сервера.
Что отправить в поддержку
Укажите систему, клиент, браузер, сеть и состояние защищённого DNS. Опишите результат до/после и после смены сети. Для публичного обсуждения уберите полный IP и внутренние имена; для ответственной поддержки передавайте только необходимый очищенный фрагмент. Не прикладывайте полный профиль, который может содержать секрет доступа к VPN.
Отметьте, воспроизводится ли результат несколько раз и какие настройки уже менялись. Если тест не получил ответа, так и напишите: это отличается от подтверждённого прямого DNS. Хорошее обращение помогает разработчику воспроизвести сценарий, не раскрывая лишние сведения и не выдавая неполный результат одного сайта за окончательную оценку всей системы.
Как сформулировать результат
Запишите резолверы до/после, источники настроек, сеть, версии и непроверенные сценарии. Корректный вывод выглядит ограниченно: «в этой конфигурации после смены сети наблюдаемый DNS соответствует выбранной политике». Он не означает доказанную анонимность или отсутствие журналов на сервере.
Если остаётся расхождение, передайте поддержке очищенный результат и точную последовательность действий. Для связанной проверки используйте IP, IPv6 и поведение приложений, а определение DNS Leak поможет не смешивать получателя и маршрут. Цель — предсказуемый DNS для нужных задач, а не отсутствие любого незнакомого названия в отчёте.
