DNS over HTTPS: приватность и настройки браузера
Как DoH меняет транспорт DNS и что могут видеть прокси и резолверы.
Нужна структурированная документация по теме Сеть?
Эта статья относится к редакционной библиотеке. Для пошаговой настройки, справки и постоянных обновлений переходите сразу в соответствующий раздел docs.
DNS over HTTPS (DoH) отправляет DNS-запросы по HTTPS выбранному резолверу вместо обычного незашифрованного пути. Это может уменьшить доступ локальной сети к запросам, но не делает просмотр анонимным. Браузер, операционная система, прокси, резолвер, сайт и учётная запись видят разные части запроса.
Что меняет DoH
Обычный DNS часто использует UDP или TCP к резолверу, заданному системой или сетью. DoH помещает обмен DNS в HTTPS; конечную точку может выбрать браузер, система, администратор или пользователь. Руководство MDN по DNS описывает разрешение имён. DoH меняет транспорт и отношения с резолвером, но не политику сайта.
RFC 8484 описывает HTTP-представление сообщений DNS. Документ не требует одинаковых настроек во всех браузерах и не гарантирует DoH для каждого запроса. В зависимости от политики и доступности возможны системный, прокси- или резервный путь.
Настройки браузера и выбор пользователя
DoH является настройкой браузера или системы, а не разрешением веб-страницы. Браузер может предлагать автоматический режим, отключение или своего провайдера; корпоративная политика может управлять выбором; сеть может блокировать конечную точку. Страница не может надёжно определить или изменить этот выбор.
Документы Firefox и Chrome показывают настройки конкретных поставщиков. Значения по умолчанию меняются. Название провайдера не доказывает, что весь DNS, трафик и телеметрия идут одним путём. Не просите пользователя нарушать административную политику ради другой операции.
Границы прокси, резолвера и сайта
Прокси передаёт запросы приложения, а резолвер отвечает на запрос имени. Браузер может сначала разрешить имя через DoH, поручить разрешение прокси или использовать системный путь. Порядок зависит от реализации и политики.
Резолвер обычно видит имя и метаданные, нужные для ответа. Прокси видит передаваемое соединение и свои журналы. Сайт видит полученный запрос, включая заголовки и контекст учётной записи. HTTPS защищает участок между браузером и DoH, но не скрывает сайт от самого себя и не удаляет журналы сервиса. Ответ DNS не доказывает личность, местоположение или намерение.
Ограничения приватности и ошибки
DoH может уменьшить видимость запросов для локального наблюдателя, но резолвер всё ещё может знать запросы, прокси может знать соединения, а сайт может знать полученный запрос. Cookies, хранилище, аккаунты и телеметрия остаются отдельными поверхностями. Не объединяйте DNS-события с другими сигналами для профилирования.
Разрешение имени может не сработать из-за конечной точки, политики, сертификата, captive portal или несовместимой сети. Сохраняйте полезность задачи, показывайте понятный повтор и не переключайтесь молча на неодобренный резолвер. Событие resolver-unavailable обычно безопаснее, чем сохранение имени.
Практическая проверка
Запишите резолвер, ответственного владельца, заявленное хранение и проверенные версии браузера. Проверяйте прокси и резолвер на доменах команды. Тестируйте управляемый, пользовательский, недоступный и резервный режимы без истории настоящих запросов.
Укажите, относится ли настройка к браузеру, профилю или управляемому устройству. Административный выбор должен быть только для чтения. При использовании прокси сверяйтесь с конфигурацией прокси BotBrowser. Обещание должно быть точным: объяснять маршрут, сокращать журналы и сохранять рабочий путь при изменении политики.
См. также предотвращение утечек DNS и согласованность прокси, DNS и WebRTC.
Ответственный выбор резолвера
Выбор резолвера относится и к управлению. Сравните опубликованную политику провайдера, хранение данных и порядок реагирования на инциденты. Шифрование транспорта не скрывает имя запроса от самого провайдера.
Резервные пути и контролируемые тесты
Определите резервный путь до выпуска: одна повторная попытка, понятное сообщение и документированная альтернатива. Проверьте обычные, недоступные и управляемые точки с доменами команды без истории реальных запросов.
Выбирайте резолвер по назначению профиля: личная настройка, одобренная точка для управляемого профиля или контролируемый домен для теста.
Не доверяйте одному слову «приватный». Проверьте оператора, хранение, юрисдикцию и процесс инцидентов.
Выбор резолвера не должен быть частью идентичности приложения; страница не должна без причины требовать конкретный сервис.
Браузер может использовать DoH, системный путь или административное отключение; captive portal и ОС могут перехватить DNS.
Определите резервный путь заранее: повтор для публичной страницы, остановка до восстановления одобренного резолвера для чувствительного потока.
Не переключайтесь молча на неодобренную точку и объясняйте решение пользователю.
Обновление браузера, сертификат или политика способны изменить маршрут. Пересчитывайте его после перезапуска и изменения политики.
Web API не дает переносимого доказательства используемого резолвера или защиты DoH. Успешный запрос и задержка этого не доказывают.
Для поддержки достаточно браузера и версии, состояния профиля/политики, времени, видимой ошибки и контролируемого имени; не просите историю.
Разделяйте сбой прокси и DNS: прокси может разрешать имя за браузер, а соединение может упасть после успешного разрешения.
DoH лишь один контроль; cookies, хранилище, разрешения, referer, аккаунты, журналы и сторонние ресурсы сохраняют контекст.
Встроенный контент может использовать другой маршрут. Не называйте всю страницу «частным DNS» из-за одной настройки.
Отчет об ошибке, снимок или ссылка поддержки тоже раскрывают имя. Ограничьте поля, маскируйте имена и удаляйте данные.
Проверяйте исходы: рабочую и недоступную точку, управляемую политику, прокси с собственным разрешением и ошибочную цель.
Проверяйте точность сообщения, сохранение введенных данных и следующий шаг на поддерживаемых версиях.
Используйте домены команды, исключайте их из аналитики и удаляйте записи после теста.
Задержка не доказывает конкретный резолвер или сетевого участника.
Частые вопросы.
Запишите режим DoH, ответственную команду, одобренную точку и условия резервного пути.
Пересматривайте политику при изменении браузера, ОС, прокси или сети; не обещайте неизменное будущее поведение.
Четко различайте «безопасный DNS при доступности» и «только этот провайдер».
Управляемый выбор показывайте как доступный только для чтения и указывайте поддержку.
Ограничьте повторы, сохраните форму и предложите ручной или offline путь.
Документация должна использовать тестовые имена и скрытые этапы: DoH не защищает все сигналы браузера.
Скрывает ли DoH IP? Нет. Он шифрует DNS до резолвера, но прокси и цель видят последующее соединение.
Знает ли страница, включен ли DoH? Надежного переносимого Web API для этого нет.
Одинаковы ли прокси и DoH-резолвер? Нет: резолвер отвечает за имена, прокси переносит соединения и иногда разрешает их.
Должно ли приложение требовать резолвер? Только при документированном проверенном требовании; иначе уважайте управляемую политику.
При сбое DNS собирайте этап, версии, разрешенное состояние политики и время, но не полную историю запросов.
Настройка принадлежит браузеру или системе, а не странице; страница не может ее навязать.
Резолвер, прокси и цель являются разными наблюдателями и документируются отдельно.
Обещание приватности должно относиться только к защищенному маршруту, а не к полной анонимности.
Ответ DNS не доказывает личность, местоположение или намерение.
Диагностика должна хранить этап и результат, а не запрошенное имя.
Источники
Похожие статьи
Переведите BotBrowser из исследований в продакшн
Используйте эти руководства, чтобы понять модель, а затем перейти к кроссплатформенной валидации, изолированным контекстам и масштабируемому браузерному развертыванию.