Кратко

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

Представим гипотетическую ситуацию. Два управляемых ноутбука подключаются к одной офисной сети. Операционная система первого обнаруживает и проверяет зашифрованную точку подключения к резолверу, предложенному сетью; имя внутренней службы продолжает разрешаться. На втором браузер выбирает публичный DoH-сервис. TLS работает, но внутреннее имя больше не разрешается, а сетевой DNS-фильтр выпадает из пути запроса. Шифрование исправно в обоих случаях. Различаются компонент, выбравший резолвер, и связанная с этим выбором политика.

RFC 8484 помещает каждую пару DNS-запроса и ответа в обмен HTTPS. TLS обеспечивает конфиденциальность и целостность канала. В том же документе сказано, что локальная политика и split DNS могут приводить к разным ответам разных серверов на один запрос. Средства проверки, полагающиеся на открытый DNS, не видят трафик DoH. Таким образом, защита транспорта выводит на первый план управленческий вопрос: какой компонент выбирает отвечающий сервис.

RFC 9462 задаёт рамки обнаружения. DDR позволяет перейти от известного незашифрованного резолвера к зашифрованной службе того же или сотрудничающего оператора. Verified Discovery требует действительной цепочки сертификатов и записи subjectAltName с IP-адресом исходного резолвера. При Opportunistic Discovery зашифрованная и незашифрованная службы используют один IP-адрес; такой режим рекомендуется только для частных или локальных адресов. Он шифрует транспорт, но не подтверждает личность резолвера по имени в сертификате. Эти два способа дают разный уровень гарантий и не отменяют политику выбора на стороне клиента.

RFC 9463 даёт сети возможность назначать шифрованные резолверы через DHCPv4, DHCPv6 или Router Advertisement IPv6. Объявление может содержать домен аутентификации, адреса, сведения о протоколах и приоритет. Назначение остаётся предложением: система или приложение способны принять его, сравнить с другой настройкой либо отклонить. Ответственность распределяется между сетью доступа, платформой, приложением и оператором резолвера.

Перемещается и управление данными. RFC 8932 рекомендует минимизировать сбор, сокращать операционное хранение до практически необходимого срока, ограничивать доступ сотрудников и прозрачно описывать практики. Смена резолвера может одновременно изменить место обработки, срок хранения, юрисдикцию и доказательства для расследования.

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

Источники