Зашифрованный DNS без VPN скрывает запрос, а не ваш адрес

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

Запишите цель до запуска любого теста.

Шаг 1: назовите защиту, которую вы действительно хотите

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

VPN служит третьей и, в зависимости от провайдера, первой. Ни один из инструментов не является надмножеством другого.

Шаг 2: выберите резолвер и проверьте его подлинность

DNS over TLS упаковывает запрос в сеанс TLS с резолвером, а DNS over HTTPS упаковывает его в HTTP-запрос; RFC 7858 и RFC 8484 описывают оба, и ни одному не нужен туннель. Операционно важно, чтобы сертификат проверялся по имени, которое вы настроили, потому что зашифрованный сеанс с неверной стороной хуже открытого текста с верной. Это означает строгий режим там, где платформа его предлагает, а не оппортунистический режим, который отступает при неудаче проверки. Проверьте сеанс напрямую, прежде чем доверять настройке: openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief.

Рукопожатие должно назвать настроенный вами резолвер и вернуть цепочку, которую можно проверить.

Шаг 3: решите, как вести себя при сбое

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

В systemd-resolved это означает DNSOverTLS=yes а не opportunistic; а в Android это означает режим имени хоста Private DNS вместо автоматического.

Проверьте, что действительно действует, с помощью resolvectl status | grep -i -A1 "dns over tls", потому что drop-in-файл, который ни разу не перезагружали, ничего не меняет.

Шаг 4: проверьте, следуют ли приложения системному резолверу

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

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

Шаг 5: читайте тест утечки в свете требования

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

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

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