Система доменных имен (DNS) служит критической инфраструктурой интернета, преобразуя доменные имена в IP-адреса. На протяжении десятилетий основным транспортным протоколом для DNS-запросов остается UDP на порту 53. Хотя UDP минимизирует задержки за счет отказа от предварительного трехстороннего рукопожатия, его архитектура без установления соединения несет фундаментальную уязвимость: возможность подделки IP-адреса отправителя. Злоумышленники регулярно используют рекурсивные и авторитетные DNS-серверы для генерации отраженных распределенных атак типа «отказ в обслуживании» (DDoS) с высоким коэффициентом усиления (амплификации) и отравления кэша. Стандарты RFC 7873 («Domain Name System (DNS) Cookies») и RFC 9018 («Interoperable Domain Name System (DNS) Server Cookies») внедряют криптографический механизм в рамках расширения EDNS(0), подтверждающий подлинность транзакций между клиентами и серверами.

Классический UDP-запрос без аутентификации (уязвим к спуфингу):
Атакующий (подделывает IP жертвы) ─── Запрос ───> DNS-резолвер
Жертва <────── Усиленный отраженный ответ ────── DNS-резолвер

Транзакция с DNS Cookies (RFC 7873 / RFC 9018):
Клиент ──────── Запрос + Client Cookie (8 байт) ───────> DNS-сервер
Клиент <── Ответ + Client Cookie + Server Cookie ─────── DNS-сервер
(Двусторонняя доступность подтверждена; фиктивные пакеты отклоняются)

Кризис амплификации UDP: уязвимости классического DNS

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

Транспорт без сохранения состояния и подделка IP-адресов

Диспропорция между компактным объемом запроса и массивным криптографическим ответом создает высокий коэффициент усиления трафика. Запрос длиной 64 байта на получение записей ANY, подписей DNSSEC (RRSIG и DNSKEY) или объемных записей TXT нередко возвращает ответы размером более 3000 байт. Если вышестоящие операторы связи пренебрегают фильтрацией поддельных адресов (BCP 38 / RFC 2827), злоумышленники насыщают входящие каналы жертв лавиной отраженного трафика через открытые резолверы.

Отсутствие проверки источника также облегчает атаки с отравлением кэша (DNS cache poisoning). Угадав идентификатор транзакции (Transaction ID) и номер порта UDP, атакующий может успеть внедрить фиктивные ресурсные записи в память резолвера до прихода легитимного ответа. Протокол DNSSEC гарантирует неизменность данных в авторитетной зоне, однако он не аутентифицирует отправителя запроса и не защищает серверы от использования в качестве отражателей.

Издержки и недостатки ограничения частоты откликов RRL

Для смягчения последствий амплификации операторы внедрили механизм ограничения частоты ответов (Response Rate Limiting, RRL). RRL группирует клиентские запросы по префиксам сети (/24 для IPv4 или /56 для IPv6) и отбрасывает либо усекает (устанавливая флаг TC=1) ответы, превышающие допустимый порог.

Несмотря на снижение общего объема атак, RRL порождает эксплуатационные проблемы:

  • Клиенты, находящиеся за узлами операторского NAT (CGNAT), делят единый публичный префикс с зараженными устройствами и сталкиваются с потерей легитимных пакетов.
  • Принудительное усечение вынуждает клиентов переходить на протокол TCP, что приводит к задержкам на трехстороннее рукопожатие и расходу системных дескрипторов сокетов.
  • Высоконагруженные публичные резолверы испытывают ложные срабатывания при кратковременных всплесках пользовательской активности.

DNS Cookies устраняют необходимость эвристических догадок RRL, подтверждая двустороннюю связь без накладных расходов на сохранение сессионного состояния на сервере.

Архитектура RFC 7873: двойное рукопожатие через EDNS(0)

Стандарт RFC 7873 описывает механизм аутентификации, интегрированный в структуру расширений EDNS(0) (RFC 6891) под кодом опции Option Code 10.

+-------------------------------+-------------------------------+
|       OPTION-CODE (10)        |     OPTION-LENGTH (16-40)     |
+-------------------------------+-------------------------------+
|                    Client Cookie (8 октетов)                  |
+---------------------------------------------------------------+
|                    Server Cookie (8-32 октетов)               |
+---------------------------------------------------------------+

Протокол реализует двухэтапный обмен между DNS-клиентом (стаб-резолвером или рекурсивным сервером) и DNS-сервером (рекурсивным или авторитетным узлом).

Client Cookie представляет собой 8-байтный токен, формируемый клиентом. Он должен быть непредсказуем для стороннего наблюдателя, но воспроизводим самим клиентом при обращении к заданному серверу в пределах определенного временного окна. Расчет выполняется с помощью псевдослучайной функции с ключом:

$$\text{Client Cookie} = \text{PRF-64}(\text{Client IP}, \text{Server IP}, \text{Client Secret})$$

Секретный ключ клиента содержит 128 бит энтропии, хранящейся исключительно в оперативной памяти. Периодическая ротация секрета (обычно каждые 24 часа) аннулирует старые токены без необходимости записи на диск. Привязка к IP-адресам клиента и сервера исключает возможность перехвата и повторного использования cookie на других направлениях.

При получении запроса, содержащего Client Cookie, сервер выполняет следующую процедуру:

  1. Первичный запрос: Клиент передает только свой 8-байтный Client Cookie. Длина опции Option Length равна 8.
  2. Вычисление на сервере: Сервер фиксирует начальный запрос и вычисляет собственный Server Cookie, привязанный к полученному токену клиента, его IP-адресу и локальному секретному ключу.
  3. Ответ с двумя токенами: Сервер возвращает в записи EDNS(0) OPT исходный Client Cookie и сгенерированный Server Cookie (длиной от 8 до 32 байт).
  4. Кэширование на клиенте: Клиент проверяет совпадение возвращенного Client Cookie и сохраняет Server Cookie в памяти, связывая его с IP-адресом сервера.
  5. Последующие запросы: Все дальнейшие запросы содержат оба маркера (суммарная длина от 16 до 40 байт). Сервер моментально валидирует запрос повторным вычислением хеша.

Поскольку атакующий со сгенерированным чужим адресом не может получить ответ от сервера, он не может узнать Server Cookie, что полностью исключает возможность проведения амплификационной атаки.

Хотя RFC 7873 сформировал базовую логику взаимодействия, внутренний бинарный формат Server Cookie оставался на усмотрение разработчиков ПО. В гетерогенных сетях Anycast, где параллельно эксплуатируются узлы под управлением BIND, NSD, Knot DNS и PowerDNS, серверы не могли распознавать токены, сформированные другими реализациями.

RFC 9018 решил эту проблему, жестко зафиксировав 16-байтовую структуру Server Cookie.

+---------------+---------------+-------------------------------+
| Version (0x01)|       Reserved (0x000000)                     |
+---------------+---------------+-------------------------------+
|                      Timestamp (4 октета)                     |
+---------------------------------------------------------------+
|                      Hash (8 октетов)                         |
+---------------------------------------------------------------+

Назначение полей:

  • Version (1 байт): Идентификатор версии алгоритма; зафиксирован на значении 0x01.
  • Reserved (3 байта): Поле зарезервировано, передается как 0x000000 и игнорируется при приеме.
  • Timestamp (4 байта): 32-битное беззнаковое целое число, представляющее системное время UNIX в секундах.
  • Hash (8 байт): 64-битный усеченный криптографический код аутентификации.

Конструкция SipHash-2-4 и 64-битный усеченный хеш

Стандарт RFC 9018 предписывает использование алгоритма SipHash-2-4 для вычисления 8-байтного поля Hash. SipHash-2-4 обеспечивает высокое быстродействие на коротких входных блоках, защиту от атак коллизиями и оптимизирован для современных 64-битных процессоров.

Вычисление выполняется по формуле:

$$\text{Hash} = \text{SipHash-2-4}(\text{Server Secret}, \text{Client Cookie} ,|, \text{Version} ,|, \text{Reserved} ,|, \text{Timestamp} ,|, \text{Client IP})$$

Сервер осуществляет проверку двух условий:

  1. Актуальность временной метки: Проверяется условие $|T_{\text{текущее}} - T_{\text{cookie}}| \le 3600 \text{ секунд}$. Интервал в 1 час сглаживает возможную рассинхронизацию часов и сетевые задержки, ограничивая окно для атак повторного воспроизведения.
  2. Проверка подлинности хеша: Сервер пересчитывает SipHash-2-4 с активным секретным ключом и выполняет сравнение 64-битного значения в константном времени для предотвращения тайминг-атак.

При успешной проверке запрос признается аутентифицированным: сервер освобождает клиента от ограничений RRL и возвращает полные ответы в пределах согласованного буфера EDNS.

Топология Anycast-резолверов и плановая ротация ключей

Современные распределенные DNS-сети строятся на базе технологии BGP Anycast, анонсируя общий IP-адрес из сотен точек присутствия (PoP) по всему миру. Из-за динамической маршрутизации и балансировки ECMP последовательные пакеты от одного клиента могут поступать на разные физические серверы.

Для обеспечения непрерывности проверки все узлы внутри кластера Anycast должны синхронизировать единый секретный ключ. Операторы используют схему с двумя симметричными ключами:

  • Основной ключ ($K_{\text{active}}$): Служит для генерации новых Server Cookie в исходящих ответах и валидации входящих запросов.
  • Предыдущий ключ ($K_{\text{previous}}$): Сохраняется на период смены ключей (от 2 до 24 часов) для валидации токенов, сформированных предыдущим поколением секрета.

При ротации новый ключ объявляется перспективным, затем переводится в статус основного, а старый основной ключ становится предыдущим. Это предотвращает потерю запросов при миграции маршрутов между узлами Anycast.

Обработка ошибок BADCOOKIE и механизм обратной совместимости

Если на сервер поступает запрос с истекшим, искаженным или недействительным Server Cookie, запускается процедура восстановления RFC 7873:

  1. Блокирование усиления: Сервер отказывается отправлять полный набор запрашиваемых ресурсных записей.
  2. Сигнализация ошибки: Формируется пустой ответ с кодом RCODE=9 (BADCOOKIE) с сохранением исходного Transaction ID.
  3. Обновление токена: В запись EDNS(0) OPT помещается переданный Client Cookie и свежесгенерированный Server Cookie.
  4. Повторная отправка: Клиент извлекает актуальный токен, обновляет кэш и немедленно повторяет исходный запрос.

Если устаревший сетевой экран на маршруте удаляет опцию EDNS(0), клиент фиксирует отсутствие cookie в ответах и переходит на классические запросы, сохраняя сетевую доступность.

Интеграция с RiceGuard: архитектура Zero-Trust DNS и защита трафика

Сетевой стек RiceGuard в сервисе VPNRice задействует спецификации DNS Cookies на всех уровнях взаимодействия клиентов и серверных узлов, формируя модель доверия Zero-Trust.

Архитектура Zero-Trust DNS в инфраструктуре RiceGuard:
Клиентское устройство (VPNRice)
  │
  ├── Зашифрованный туннель WireGuard / IPsec (ChaCha20-Poly1305 / AES-256-GCM)
  ▼
Пограничный шлюз Anycast RiceGuard
  │  - Проверяет RFC 9018 Server Cookies на всех входящих UDP-пакетах
  │  - Отсекает нелегитимные попытки амплификации на периметре
  │  - Синхронизирует ключи SipHash-2-4 по всей глобальной сети
  ▼
Защищенный рекурсивный резолвер
  │  - Добавляет Client Cookie при обращении к корневым и TLD серверам
  │  - Валидирует Server Cookie в ответах вышестоящих авторитетных зон
  │  - Обеспечивает криптографическую валидацию DNSSEC
  ▼
Глобальная авторитетная инфраструктура DNS
  1. Изоляция в туннеле: Пользовательские DNS-запросы направляются внутри туннелей WireGuard или IPsec напрямую к резолверам Anycast RiceGuard, исключая перехват на уровне локального Wi-Fi и провайдера.
  2. Периметральная защита шлюзов: Публичные интерфейсы проверяют Server Cookies по стандарту RFC 9018 для внешнего UDP-трафика. Пакеты без валидных токенов подвергаются жесткому лимитированию или проверке через BADCOOKIE.
  3. Безопасность рекурсивных запросов: При обращении к серверам зон рекурсивные узлы RiceGuard генерируют собственные Client Cookies и валидируют ответы, защищая кэш от отравления даже для зон без DNSSEC.

Сочетание сквозного шифрования туннелей и протокольной аутентификации DNS Cookies обеспечивает надежность передачи данных в любых сетевых средах.

Практическая проверка: тестирование DNS Cookies с помощью Dig

Сетевые инженеры могут протестировать поддержку DNS Cookies на резолверах и авторитетных серверах с помощью утилиты dig.

Выполнение запроса с полной аутентификацией

Современные версии dig автоматически задействуют механизм DNS Cookies:

# Запрос к резолверу Anycast с согласованием cookie
dig @1.1.1.1 vpnrice.com +cookie

Секция OPT PSEUDOSECTION содержит поле COOKIE:

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 5a8e2b109c3d4f8a 01000000672c8410d9f82e14a7c3b901 (good)
;; QUESTION SECTION:
;vpnrice.com.			IN	A

;; ANSWER SECTION:
vpnrice.com.		300	IN	A	104.21.48.12

Расшифровка данных:

  • 5a8e2b109c3d4f8a — 8-байтный Client Cookie, созданный утилитой dig.
  • 01000000672c8410d9f82e14a7c3b901 — 16-байтный Server Cookie RFC 9018:
    • Версия: 01
    • Резерв: 000000
    • Метка времени: 672c8410 (шестнадцатеричный формат UNIX)
    • Хеш: d9f82e14a7c3b901 (результат SipHash-2-4)
  • Метка (good) подтверждает успешную криптографическую верификацию.

Моделирование ошибки и повторного согласования

Для проверки реакции сервера можно отправить поврежденный токен:

# Отправка фиктивного 16-байтного Server Cookie
dig @1.1.1.1 vpnrice.com +cookie=5a8e2b109c3d4f8a0100000000000000ffffffffffffffff

Сервер с поддержкой RFC 9018 вернет status: BADCOOKIE, не приложит записи ответа и предоставит в блоке OPT новый Server Cookie, стимулируя клиент к моментальному повторному запросу.

DNS Cookies устраняют противоречие между низкими задержками UDP и требованиями строгой аутентификации сетевых пакетов. Внедрение RFC 7873 и RFC 9018 на рекурсивных и авторитетных серверах нейтрализует векторы амплификации на транспортном уровне, сохраняя высокую скорость обработки запросов.

Для защиты сетевого трафика и надежного разрешения доменных имен через серверы Anycast с поддержкой современных криптографических стандартов доступно решение Скачать VPNRice.