DoH добавляет семантику HTTP, включая методы и кэширование, к защите TLS. DoT передаёт DNS по другому транспортному договору; диагностировать один по признакам другого недостаточно.
DNS и разрешение имён
DNS через HTTPS — DoH
Определение
DNS через HTTPS (DoH) — это передача DNS-запросов и ответов по HTTPS: клиент отправляет GET или POST на настроенный URI, а сервер отвечает сообщением application/dns-message. Код HTTP и код внутри DNS-ответа относятся к разным уровням: успешный ответ HTTP может нести отказ DNS.
Также ищут: DoH · DNS через HTTPS · DNS over HTTPS
Зачем это знать
Защищённое соединение с сервером DoH не гарантирует успешное разрешение нужного имени. Нужно разбирать оба уровня ответа и понимать, какое пространство DNS выбрано приложением.
Связи из словаря
Карта понятия
DNS через HTTPS — DoH
Доказательная часть
Что подтверждено
Сервер DoH принимает DNS-запрос через HTTPS GET или POST и возвращает сетевое DNS-сообщение как application/dns-message.
Граница применимости: Соответствие запросов и ответов DoH по RFC 8484.
HTTPS проверяет сервер DoH и защищает канал, но подлинность конечного набора записей требует доверия резолверу или проверки DNSSEC.
Граница применимости: Безопасность транспорта DoH и проверка происхождения ответа DNS.
Клиент DoH использует настроенный URI-шаблон службы. Сам факт, что сервер принимает HTTPS на порту 443, не означает наличие у него DoH по произвольно выбранному пути.
Граница применимости: Конфигурация URI-шаблона и запросов RFC 8484; стандарт не задаёт один обязательный путь для всех операторов.
Успешный HTTP-ответ может нести DNS-сообщение с отрицательным исходом или ошибкой. Код HTTP и код результата внутри DNS относятся к разным уровням и проверяются отдельно.
Граница применимости: Разделение ошибок HTTP и DNS по RFC 8484; HTTP 200 не трактуется как наличие адресной записи.
При GET DNS-сообщение кодируется в параметре URI по правилам DoH, а при POST передаётся в теле запроса. Выбор метода меняет размещение данных, но не скрывает сам вопрос от сервера DoH.
Граница применимости: Форматы GET и POST RFC 8484; свойства хранения журналов конкретным оператором здесь не утверждаются.
Получатель кэшированного HTTP-ответа DoH учитывает его возраст при вычислении оставшегося TTL содержащихся DNS-данных. HTTP-кэш не должен делать прежний DNS-ответ заново свежим.
Граница применимости: Согласование HTTP-кэширования и DNS TTL по RFC 8484, §5.1; дополнительные сроки DNSSEC проверяются отдельно.
Для приложения, выбирающего собственный DoH, предлагаем проверить внутренние имена и поведение через VPN. Защита канала к внешнему резолверу не доказывает доступность нужного частного представления.
Граница применимости: Редакторский сценарий приёмки из архитектуры приложений DNS и DoH; стандарт не описывает настройки конкретного браузера или ОС.
Граница терминов
Не путать
DoH описывает перенос запроса, раздельный DNS — выбор представления имён. Публичный шифрованный резолвер может корректно отвечать иначе, чем корпоративный.
Перед спецификацией
Что проверить
- Сверьте точный URI-шаблон и поддержанные методы сервера DoH.
- Проверьте аутентификацию HTTPS и выбранного оператора резолвера.
- Разбирайте HTTP-исход и код DNS внутри сообщения отдельно.
- При кэшированном HTTP-ответе учитывайте возраст и оставшийся DNS TTL.
- Проверьте, совпадает ли DoH приложения с ожидаемой корпоративной политикой разрешения.
- Испытайте внутренние имена при подключённом и отключённом VPN.
- DNSSEC и полезную операцию службы проверяйте отдельно от успешного HTTP-обмена с DoH.
Открытые основания
Первоисточники
- DNS Security Introduction and Requirements
Определяет DNSSEC goals, resolver security states, trust anchors и границы защиты.
Утверждения: 02
- Architectural Considerations on Application Features in the DNS
Разбирает application use DNS, private namespaces и split-horizon operational boundaries.
Утверждения: 07
- Specification for DNS over Transport Layer Security
Определяет DNS over TLS transport, privacy profiles и server authentication requirements.