На протяжении десятилетий служба доменных имен (DNS) передавала запросы в открытом виде по протоколу UDP на порт 53. Отсутствие криптографической защиты позволяло провайдерам, операторам публичных точек Wi-Fi и промежуточным транзитным узлам перехватывать и протоколировать адреса сетевых ресурсов, к которым обращались пользователи.

Внедрение стандартов DNS-over-TLS (DoT, RFC 7858), DNS-over-HTTPS (DoH, RFC 8484) и DNS-over-QUIC (DoQ, RFC 9250) сформировало надежный фундамент для защиты транспортного уровня. Однако ранние схемы развертывания опирались на статическую ручную настройку IP-адресов публичных резолверов (например, 1.1.1.1 или 8.8.8.8).

Такая модель создает критические препятствия в корпоративных сетях и инфраструктурах виртуальных частных сетей (VPN). Жесткая привязка к внешним резолверам нарушает работу механизмов Split-Horizon для внутренних зон (intranet.internal, реестры разработки), провоцирует утечки DNS за пределы туннеля и не позволяет локальным сетевым шлюзам самостоятельно предоставлять шифрованное разрешение имен.

Для автоматического перехода на криптографические протоколы без нарушения локальной маршрутизации рабочая группа IETF Adaptive DNS Discovery (ADD) ратифицировала два взаимодополняющих стандарта: RFC 9462 (Discovery of Designated Resolvers, DDR) и RFC 9463 (Discovery of Network-designated Resolvers, DNR).

+--------------------------------------------------------------------------+
|            СХЕМА АВТОМАТИЧЕСКОГО ОБНАРУЖЕНИЯ РЕЗОЛВЕРА (RFC 9462 DDR)    |
+--------------------------------------------------------------------------+
|                                                                          |
|    +------------+      1. Запрос в открытом виде (UDP 53) +------------+ |
|    |            | --------------------------------------> | Локальный/ | |
|    |   Клиент   |   QNAME: _dns.resolver.arpa (Type SVCB) |  VPN DNS   | |
|    | (OS / Stub | <-------------------------------------- | Рекурсор   | |
|    |  Resolver) |        2. Ответ со структурой SVCB      |            | |
|    +------------+   TargetName: dns.vpnrice.internal      +------------+ |
|          |          Alpn: "h2,h3", Port: 443                     |       |
|          |          IPv4/IPv6 hints                              |       |
|          |                                                       |       |
|          | 3. Криптографическая проверка сертификата и TLS       |       |
|          |    Подключение к IP шлюза по TCP 443 / UDP 443        |       |
|          |    SNI: dns.vpnrice.internal                          |       |
|          v    Проверка сертификата X.509 через доверенное хранилище      |
|    +----------------------------------------------------------------+    |
|    |           ЗАЩИЩЕННЫЙ ШИФРОВАННЫЙ КАНАЛ DNS                     |    |
|    |            (DoH / DoT / DoQ поверх TLS 1.3 / QUIC)             |    |
|    |      Полная защита от утечек DNS и сохранение Split-Horizon    |    |
|    +----------------------------------------------------------------+    |
|                                                                          |
+--------------------------------------------------------------------------+

Механизмы RFC 9462: Discovery of Designated Resolvers (DDR)

DDR функционирует как внутриполосный протокол (in-band discovery). Он дает возможность клиентскому stub-резолверу, изначально подключенному к незашифрованному DNS-серверу (например, к адресу 10.8.0.1, выделенному в VPN-туннеле), выяснить, поддерживает ли данный узел защищенные протоколы.

Обнаружение выполняется на базе записей Service Binding (SVCB), регламентированных в RFC 9460:

1. Зондирование специального доменного имени

После активации интерфейса клиент направляет стандартный запрос к полученному от DHCP или VPN DNS-серверу:

  • QNAME: _dns.resolver.arpa
  • QTYPE: SVCB (код 64)
  • Транспорт: стандартный UDP/TCP порт 53

Домен _dns.resolver.arpa зарегистрирован IANA как специальная зона (Special-Use Domain Name). Локальный резолвер обязан отвечать на этот запрос авторитетно и категорически не имеет права пересылать его вышестоящим корневым серверам.

2. Структура ответа SVCB

При наличии поддержки шифрования резолвер возвращает параметры сервиса:

_dns.resolver.arpa. 3600 IN SVCB 1 dns.vpnrice.internal. (
    alpn="h2,h3"
    port=443
    dohpath="/dns-query{?dns}"
    ipv4hint=10.8.0.1
)
_dns.resolver.arpa. 3600 IN SVCB 2 dns.vpnrice.internal. (
    alpn="doq"
    port=853
    ipv4hint=10.8.0.1
)

Параметры записи содержат:

  • TargetName (Authenticated Domain Name, ADN): FQDN для аутентификации TLS (dns.vpnrice.internal).
  • alpn: идентификаторы протоколов прикладного уровня (h2, h3 для DoH, dot для DoT, doq для DoQ).
  • port: сетевой порт шифрованной службы.
  • dohpath: URI-шаблон для выполнения запросов DoH.

3. Криптографическая валидация и защита от подмены

Злоумышленник в локальной сети Wi-Fi может попытаться внедрить фиктивный ответ SVCB. Для нейтрализации подобных атак RFC 9462 накладывает строгие требования:

  1. Совпадение IP-адреса: клиент обязан инициировать TLS-сессию ровно на тот же IP-адрес, куда отправлялся исходный незашифрованный запрос. Если опрашивался 10.8.0.1, защищенное соединение устанавливается строго на 10.8.0.1.
  2. Верификация сертификата X.509: предъявляемый сервером сертификат должен содержать указанное доменное имя ADN в поле Subject Alternative Name (SAN) и успешно проверяться по системному хранилищу доверенных центров сертификации.
  3. Кросс-проверка адреса: для публичных резолверов стандарт требует совпадения IP-адреса с записью SAN типа IPAddress либо корректного обратного разрешения (PTR).

Если проверка не проходит, клиент отвергает обновление и не использует предложенный зашифрованный канал.

+--------------------------------------------------------------------------+
|                   ПАРАМЕТРЫ ПРОТОКОЛОВ ПРИ ОБНОВЛЕНИИ DDR                |
+--------------------------------------------------------------------------+
| Протокол           | Токен ALPN | Порт по умолчанию | Транспортный уровень |
+--------------------+------------+-------------------+---------------------+
| DNS-over-HTTPS/2   | h2         | 443               | TCP + TLS 1.3       |
| DNS-over-HTTPS/3   | h3         | 443               | UDP + QUIC          |
| DNS-over-TLS       | dot        | 853               | TCP + TLS 1.3       |
| DNS-over-QUIC      | doq        | 853               | UDP + QUIC          |
+--------------------------------------------------------------------------+

RFC 9463: Discovery of Network-designated Resolvers (DNR)

Если DDR реализует обнаружение внутри протокола DNS, то RFC 9463 (DNR) определяет внеполосный механизм (out-of-band discovery) через протоколы конфигурации сети:

  • DHCPv4 Option 162 (OPTION_V4_DNR)
  • DHCPv6 Option 144 (OPTION_V6_DNR)
  • IPv6 Router Advertisement Option 144

Сервер DHCP или маршрутизатор передает имя ADN, приоритеты служб и IP-адреса резолвера непосредственно в момент выдачи сетевого адреса. Устройство получает все параметры шифрования еще до отправки первого DNS-запроса, полностью исключая первичный зондирующий обмен по незащищенному UDP.

Практическая реализация: настройка Unbound с поддержкой DDR

На шлюзах под управлением Linux с сервером Unbound активация DDR выполняется добавлением зоны _dns.resolver.arpa и привязкой TLS-сертификатов:

server:
    interface: 10.8.0.1@53       # Стандартный bootstrap UDP/TCP
    interface: 10.8.0.1@853      # DNS-over-TLS (DoT)
    interface: 10.8.0.1@443      # DNS-over-HTTPS (DoH)
    
    tls-service-key: "/etc/unbound/certs/dns.key"
    tls-service-pem: "/etc/unbound/certs/dns.crt"
    tls-port: 853
    https-port: 443

    local-zone: "_dns.resolver.arpa." static
    local-data: '_dns.resolver.arpa. 3600 IN SVCB 1 dns.vpnrice.internal. alpn="h2" port="443" dohpath="/dns-query{?dns}"'
    local-data: '_dns.resolver.arpa. 3600 IN SVCB 2 dns.vpnrice.internal. alpn="dot" port="853"'

    local-zone: "vpnrice.internal." transparent
    local-data: 'dns.vpnrice.internal. 3600 IN A 10.8.0.1'

Диагностика ответа резолвера с клиентской стороны:

delv @10.8.0.1 _dns.resolver.arpa SVCB

Архитектурные преимущества с RiceGuard и VPNRice

В высоконагруженных туннельных архитектурах на базе ядра Linux, таких как модуль RiceGuard в сервисе VPNRice, интеграция RFC 9462 и RFC 9463 решает ключевые инфраструктурные задачи:

  1. Гарантированная защита от утечек DNS: современные операционные системы отдают наивысший приоритет шифрованным резолверам, предотвращая параллельную отправку запросов через внешние физические интерфейсы Wi-Fi.
  2. Корректная обработка Split-Horizon: в отличие от сторонних резолверов, внутренний DNS-сервер шлюза обслуживает корпоративные домены инфраструктуры без сбоев.
  3. Стабильность в жестких сетевых условиях: инкапсуляция DoH и DoQ в порты 443 и 853 обеспечивает устойчивость разрешения имен даже при ограничении стандартного трафика UDP 53.

Эксплуатационные аспекты и перспективы

При внедрении стандартов в корпоративную среду следует учитывать:

  • Управление сертификатами: сертификат ADN должен быть заверен центром, присутствующим в доверенном хранилище ОС, либо развернут через профили MDM.
  • Режимы работы: RFC 9462 допускает как мягкий переход (Opportunistic), так и строгий режим (Strict Mode), предотвращающий намеренный откат соединения злоумышленниками.

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