Система доменних імен (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), зловмисники перевантажують канали зв'язку жертви потоками відбитих пакетів через тисячі відкритих серверів.

Брак валідації джерела також уможливлює атаки з отруєнням кешу резолверів. Вгадуючи ідентифікатори транзакцій (Transaction ID) та порти UDP, нападник намагається впровадити підроблені ресурсні записи в кеш до надходження відповіді від авторитетного сервера. Технологія DNSSEC забезпечує цілісність даних у зоні, проте не верифікує відправника запиту і не захищає інфраструктуру від участі в ампліфікаційних атаках.

Витрати та обмеження регулювання частоти відповідей RRL

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

Попри зменшення обсягів паразитного трафіку, RRL має відчутні технічні недоліки:

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

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

Архітектура 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. Довжина опції становить 8.
  2. Обчислення на стороні сервера: Сервер визначає початковий етап рукостискання та формує Server Cookie, пов'язаний із Client 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{ секунд}$. Допуск у 60 хвилин компенсує мережеві коливання та різницю годинників, звужуючи вікно для повторного надсилання.
  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 годин) для успішної валідації токенів старого покоління.

Під час ротації новий ключ реєструється як майбутній, потім переводиться в статус основного, а колишній основний стає попереднім до повного оновлення кешу клієнтів.

Обробка помилок BADCOOKIE та механізм зворотної сумісності

Коли на сервер приходить запит із простроченим, пошкодженим або некоректним Server Cookie, виконується регламент відновлення за RFC 7873:

  1. Захист від посилення: Сервер відмовляється повертати повний масив запитуваних записів.
  2. Передача сигналу помилки: Формується пуста відповідь із кодом помилки RCODE=9 (BADCOOKIE) зі збереженням вихідного Transaction ID.
  3. Надання актуального Cookie: До запису EDNS(0) OPT додається переданий клієнтом Client Cookie разом із новоствореним дійсним Server Cookie.
  4. Повторна спроба: Клієнт фіксує код BADCOOKIE, оновлює локальний запис і негайно повторює початковий запит.

Якщо застарілі мережеві екрани видаляють поле EDNS(0), клієнт відстежує відсутність cookie у відгуках і переходить до традиційного режиму DNS, зберігаючи зв'язок.

Інтеграція з 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. Фальшиві пакети обмежуються або викликають виклик BADCOOKIE, не дозволяючи зловмисникам маніпулювати сервером.
  3. Захист рекурсивних запитів: Під час опитування зовнішніх авторитетних зон резолвери RiceGuard додають Client Cookies і перевіряють відповіді, надійно захищаючи кеш від підміни записів навіть для зон без підтримки DNSSEC.

Комбінація тунельного шифрування та протокольної валідації DNS Cookies гарантує надійність з'єднання у будь-яких мережевих умовах.

Практична перевірка: тестування DNS Cookies за допомогою Dig

Мережеві фахівці можуть перевірити коректність роботи DNS Cookies за допомогою системної утиліти dig.

Відправлення запиту з повною аутентифікацією

Сучасні версії dig здійснюють узгодження DNS Cookies автоматично:

# Надсилання тестового запиту до Anycast-резолвера
dig @1.1.1.1 vpnrice.com +cookie

Секція OPT PSEUDOSECTION показує стан обміну маркерами:

;; 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 на рекурсивній і авторитетній інфраструктурі нейтралізує загрозу ампліфікації на транспортному рівні, зберігаючи високу швидкість обробки запитів.

Для надійного захисту інтернет-з'єднання та маршрутизації DNS-запитів через стійку мережу Anycast-серверів скористайтеся можливістю Завантажити VPNRice.