Протягом тривалого часу традиційні протоколи шифрування DNS — DNS-over-TLS (DoT, RFC 7858) та DNS-over-HTTPS (DoH, RFC 8484) — відігравали ключову роль у захисті простого текстового трафіку портів UDP/TCP 53 від аналізу інтернет-провайдерів і локальних зловмисників. Проте обидва ці стандарти базуються на транспортному рівні TCP, що створює архітектурне обмеження: блокування початку черги (Head-of-Line Blocking, HoL).

У травні 2022 року Інженерна рада інтернету (IETF) затвердила стандарт RFC 9250: DNS over Dedicated QUIC Connections (DoQ). Цей протокол переносить резолвінг доменних імен безпосередньо на сучасний транспортний протокол QUIC поверх UDP, усуваючи затримки зв'язку та фундаментальні вади TCP.

+-------------------------------------------------------------+
|                ПОРІВНЯННЯ ТРАНСПОРТНИХ РІВНІВ DNS           |
+-------------------------------------------------------------+
| Do53: [ DNS Payloads ] -> UDP Port 53 (Відкритий текст)      |
| DoT:  [ DNS Payloads ] -> TLS 1.3 -> TCP Socket (Порт 853)   |
| DoH:  [ DNS Payloads ] -> HTTP/2 / HTTP/3 -> TLS -> TCP/QUIC |
| DoQ:  [ DNS Payloads ] -> Dedicated QUIC Streams (Порт 853)  |
+-------------------------------------------------------------+

Фундаментальні обмеження протоколів DoT та DoH на базі TCP

Щоб зрозуміти переваги DoQ, варто розглянути технічні недоліки протоколів попереднього покоління.

1. Блокування початку черги (Head-of-Line Blocking)

Протокол TCP гарантує сувору послідовність доставки байтів у межах з'єднання. Якщо клієнт надсилає 15 паралельних DNS-запитів через один DoT-канал, і пакет запиту №2 втрачається в каналі зв'язку, мережевий стек операційної системи зупиняє обробку всіх наступних запитів (з №3 по №15). Вони очікують повторної передачі (TCP Retransmission) втраченого сегмента, навіть якщо пакети інших запитів уже дійшли неушкодженими.

2. Затримка первинного рукостискання (Handshake Latency)

Встановлення з'єднання DoT вимагає класичного тристороннього рукостискання TCP (1 RTT), після чого відбувається узгодження сесії TLS 1.3 (ще 1 RTT). Сумарна затримка становить 2 RTT (від 80 до 300 мс) до моменту відправлення першого DNS-запиту:

Клієнт                                              DoT-сервер
  | --- TCP SYN ----------------------------------------> |
  | <-- TCP SYN-ACK ------------------------------------- | (1 RTT)
  | --- TCP ACK + TLS ClientHello ----------------------> |
  | <-- TLS ServerHello + EncryptedExtensions + Finished  | (2 RTT)
  | === Захищений канал готовий: відправка DNS Query ===  |

3. Розрив сесії при міграції мережі

Сокет TCP прив'язаний до фіксованого кортежу (Source IP, Source Port, Dest IP, Dest Port). Коли мобільний пристрій перемикається з домашнього Wi-Fi на стільникову мережу 4G/5G, локальна IP-адреса змінюється. З'єднання TCP скидається прапорцем RST, що змушує клієнт заново проходити рукостискання TCP і TLS.

4. Накладні витрати рівня HTTP в DoH

DoH використовує стандартний порт 443, але вимагає заголовків HTTP/2 або HTTP/3 (:method, :path, Content-Type: application/dns-message) та таблиць стиснення HPACK. Крім того, некоректна реалізація клієнта може випадково передавати метадані веб-сесій (куки, заголовок User-Agent).

Архітектурні інновації DNS-over-QUIC (RFC 9250)

Стандарт RFC 9250 усуває проміжні рівні TCP і HTTP, передаючи DNS-запити безпосередньо через незалежні потоки QUIC.

       QUIC Connection (Single UDP Datagram Session)
+-------------------------------------------------------+
|  Stream 0: DNS Query A (example.com)      - Active   |
|  Stream 4: DNS Query B (api.service.org)  - Packet 2  | <- Втрата пакету
|  Stream 8: DNS Query C (cdn.media.net)    - Відповідь | <- Доставлено без затримки
+-------------------------------------------------------+

1. Повна ліквідація блокування черги (Stream Multiplexing)

Усередині одного з'єднання QUIC кожен DNS-запит передається в окремому двонаправленому потоці (Bidirectional Stream). Якщо пакет у потоці №4 губиється через перешкоди на радіоканалі Wi-Fi, це жодним чином не блокує доставку або обробку потоків №0 і №8. Резолвер негайно повертає IP-адреси для решти запитів.

2. Прискорене рукостискання та режим 0-RTT

QUIC інтегрує криптографічний протокол TLS 1.3 безпосередньо у транспортні заголовки транспортного рівня UDP:

  • Первинне з'єднання (1-RTT): Обмін параметрами транспорту та криптографічними ключами відбувається одночасно за 1 RTT.
  • Повторне підключення (0-RTT): Завдяки механізму TLS 1.3 Early Data та записам session tickets клієнт надсилає DNS-запит у першому ж пакеті UDP без очікування відповіді сервера.
Клієнт                                              DoQ-сервер
  | --- QUIC Initial [Crypto ClientHello + 0-RTT Query] -> |
  | <-- QUIC Handshake [ServerHello] + 0-RTT Response --- | (Відповідь за 0 RTT!)

3. Безперервна міграція з'єднання (Connection Migration)

З'єднання QUIC ідентифікується 64-бітним маркером Connection ID (CID), а не IP-адресою чи портом. Якщо користувач виходить із зони дії Wi-Fi на мобільний інтернет, клієнт відправляє наступний пакет QUIC із нової IP-адреси зі збереженням ідентифікатора CID. Сесія шифрування не переривається, не потребує повторних рукостискань і зберігає внутрішній стан черги запитів.

4. Криптографічне доповнення довжини (RFC 8467 Padding)

Зловмисник, що спостерігає за зашифрованим каналом, може аналізувати точний розмір пакетів (Traffic Analysis), визначаючи, до якого саме домену звертається клієнт. Відповідно до стандарту RFC 8467, протокол DoQ застосовує блокове доповнення пакетів нульовими байтами (Padding Frame) до кратних блоків (наприклад, 128 або 468 байтів), що повністю нівелює відбитки розмірів повідомлень.

Практична конфігурація та тестування DoQ

Резолвери нового покоління, зокрема AdGuard Home, CoreDNS та BIND 9.18+, мають нативну підтримку протоколу RFC 9250.

1. Тестування за допомогою утиліти q

Для виконання діагностики DoQ зручно застосовувати інструмент командного рядка q:

# Прямий запит DoQ до публічного резолвера NextDNS/AdGuard на порт 853
q A example.com @quic://dns.adguard-dns.com:853

# Виведення детальної інформації про версію QUIC та час встановлення потоку
q A example.com @quic://dns.adguard-dns.com:853 -v

2. Налаштування CoreDNS з плагіном QUIC

Приклад конфігураційного блоку Corefile для авторизованого резолвінгу через протокол DoQ:

quic://.:853 {
    tls /etc/coredns/certs/fullchain.pem /etc/coredns/certs/privkey.pem
    forward . 1.1.1.1 8.8.8.8 {
        prefer_udp
    }
    cache 300
    log
}

Інтеграція DoQ в архітектуру захисту VPNRice RiceGuard

У системі захисту приватного інтернет-доступу VPNRice шифрування DNS функціонує як багатошаровий захисний екран:

[Пристрій клієнта]
       |
       v (DoQ / RFC 9250 через порт UDP 853)
[Локальний DNS-фільтр RiceGuard]
       |
       v (Внутрішній захищений тунель WireGuard / Anycast)
[Рекурсивні DNS-резолвери з RAM-диском без логування]
  • Ізоляція від шпигунських розширень провайдерів: Усі запити додатків та операційної системи направляються через власний DoQ-сервер вузла Anycast, запобігаючи витокам через локальні сервери провайдера (DNS Leaks).
  • Нульове збереження метаданих: Резолвери RiceGuard працюють виключно в оперативній пам'яті (RAM-only), не зберігаючи записів доменів і не передаючи розширення EDNS Client Subnet (ECS) зовнішнім авторитативним серверам.
  • Стабільність під час мобільного використання: Завдяки поєднанню Connection Migration у QUIC і безсесійного роумінгу WireGuard, пристрої користувачів миттєво перемикаються між стільниковими вишками без затримок у завантаженні сайтів.