Протягом десятиліть система доменних імен (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 через довірене сховище ОС v       |
|    +----------------------------------------------------------------+    |
|    |           АВТОМАТИЧНО ОНОВЛЕНИЙ ШИФРОВАНИЙ КАНАЛ 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. Зондування зарезервованого доменного імені

Після встановлення мережевого лінку клієнт надсилає звичайний DNS-запит до призначеного нешифрованого резолвера:

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

Домен _dns.resolver.arpa є спеціальною зоною, виділеною IANA. Локальний рекурсивний резолвер зобов'язаний самостійно й авторитетно відповідати на такий запит і не має права пересилати його вищестоящим кореневим серверам.

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): повністю визначене доменне ім'я для автентифікації TLS (dns.vpnrice.internal).
  • alpn: ідентифікатори узгодження протоколів прикладного рівня (h2, h3 для DoH, dot для DoT, doq для DoQ).
  • port: мережевий порт шифрованої служби.
  • dohpath: шаблон URI для формування запитів DoH.

3. Криптографічна валідація та захист від підміни

Зловмисник у локальній мережі може спробувати надіслати підроблену відповідь SVCB. Для запобігання атакам посередника RFC 9462 висуває суворі вимоги:

  1. Збіг IP-адреси: клієнт зобов'язаний встановлювати захищене з'єднання виключно на ту саму IP-адресу, до якої надсилався відкритий запит. Якщо зондувалася адреса 10.8.0.1, TLS-рукостискання має відбуватися тільки з 10.8.0.1.
  2. Перевірка сертифіката X.509: сертифікат сервера повинен містити ім'я ADN у розширенні SAN (Subject Alternative Name) та успішно перевірятися системним сховищем довірених кореневих сертифікатів.
  3. Крос-перевірка адрес: для публічних адрес сертифікат має містити відповідний запис 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, RFC 9463 (DNR) забезпечує позасмугове виявлення (out-of-band discovery) безпосередньо через протоколи конфігурації мережі:

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

Під час отримання мережевої адреси клієнт одразу одержує параметри ADN, пріоритети портів та IP-адреси шифрованого резолвера. Пристрій формує захищений канал ще до першого запиту, повністю оминаючи фазу початкового зондування через відкритий UDP.

Практична конфігурація Unbound з підтримкою DDR

На шлюзах під керуванням Linux активація DDR у сервері Unbound реалізується налаштуванням локальної зони та підключенням сертифікатів:

server:
    interface: 10.8.0.1@53       # Початковий відкритий порт 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

У ядрі мережевого тунелювання RiceGuard сервісу VPNRice впровадження RFC 9462 та RFC 9463 вирішує критичні завдання:

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

Експлуатаційні рекомендації та перспективи

При впровадженні стандартів у робоче середовище необхідно звернути увагу на:

  • Обслуговування сертифікатів: сертифікат ADN повинен бути виданий визнаним центром сертифікації або імпортований через MDM-системи.
  • Політику переходу: рекомендується використовувати суворий режим (Strict Mode), який забороняє автоматичне повернення до незашифрованого UDP при невдалому рукостисканні.

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