Систему доменних імен (DNS) часто називають адресною книгою глобальної мережі: вона перетворює зрозумілі імена вебсайтів на числові IP-адреси. Коли на початку 1980-х років розроблялися початкові специфікації DNS, інтернет був академічною спільнотою з високим рівнем довіри. Запити передавалися відкритим текстом через стандартний порт UDP 53 без шифрування та цифрової автентифікації.

Зі зростанням кіберзагроз інженери розробили дві різні технології для вирішення проблем безпеки: протокол DNSSEC для криптографічної перевірки даних і сімейство зашифрованих протоколів транзиту (DoH, DoT і DoQ). У професійних колах і серед користувачів ці поняття нерідко плутають. Деякі фахівці вважають, що впровадження DoH усуває потребу у валідації DNSSEC, або що сам по собі DNSSEC приховує мережевий трафік від провайдерів.

Насправді ці технології вирішують абсолютно різні завдання. DNSSEC гарантує справжність джерела та цілісність записів у стані спокою, тоді як шифрований DNS захищає конфіденційність транзитного каналу від клієнта до рекурсивного резолвера.

Фундаментальні відмінності завдань: цілісність проти конфіденційності

Розмежування обов'язків між протоколами лежить у площині двох класичних вимог інформаційної безпеки:

  1. Автентичність та цілісність (DNSSEC): Відповідає на запитання «Чи належить ця IP-адреса саме цьому домену, і чи не була вона спотворена сторонніми особами під час передавання або кешування?».
  2. Конфіденційність транзиту (DoH / DoT / DoQ): Відповідає на запитання «Чи може локальний провайдер або зловмисник на Wi-Fi бачити, які саме домени я запитую?».

DNSSEC створює криптографічний ланцюжок довіри від глобального кореня DNS (.) до кінцевого авторитетного сервера зони. Проте корисне навантаження залишається відкритим: третя сторона може вільно перехоплювати пакети і фіксувати доменні імена.

Шифрований DNS упаковує запити клієнта в криптографічні сесії TLS або QUIC. Провайдер бачить лише підключення до рекурсивного резолвера. Проте шифрування нічого не повідомляє про достовірність отриманих відповідей, якщо сам резолвер не здійснює перевірку DNSSEC.

Критерій Класичний DNS (UDP 53) DNSSEC (RFC 4033) Зашифрований DNS (DoH/DoT/DoQ) Спільна модель (DoH/DoT + DNSSEC)
Шифрування каналу Відсутнє Відсутнє (відкритий текст) TLS 1.3 / QUIC TLS 1.3 / QUIC
Автентичність записів Відсутня (вразливий до Kaminsky) Криптографічний підпис RRSIG Довіра лише до каналу резолвера Наскрізна криптографічна валідація
Захист від стеження ISP Відсутній Відсутній Приховує імена доменів у каналі Приховує імена доменів у каналі
Захист від отруєння кешу Слабкий (рандомізація портів) Повний захист від маніпуляцій Лише на ділянці клієнт–резолвер Повний наскрізний захист
Стійкість до блокувань Нульова (легке перехоплення) Нульова Висока (злиття з HTTPS трафіком) Висока

Архітектура DNSSEC: ланцюжок цифрових підписів

DNSSEC (RFC 4033–4035) базується на асиметричній криптографії та запроваджує спеціальні типи ресурсних записів:

  • RRSIG (Resource Record Signature): Цифровий підпис набору записів RRset, створений закритим ключем зони (ZSK).
  • DNSKEY: Відкриті ключі, що зберігаються в зоні для перевірки підписів.
  • DS (Delegation Signer): Криптографічний геш відкритого ключа дочірньої зони, розміщений у батьківській зоні.
  • NSEC / NSEC3: Записи автентифікованого заперечення існування домену, що захищають від зонного сканування.

Ланцюжок довіри працює за ієрархічним принципом: кореневий ключ KSK валідує ключ TLD (наприклад, .com), який через запис DS підтверджує відкритий ключ цільового домену. Якщо зловмисник намагається підробити IP-адресу, валідуючий резолвер фіксує невідповідність підпису і повертає статус SERVFAIL, запобігаючи перенаправленню на фішинговий вузол.

Протоколи шифрованого транзиту: DoT, DoH та DoQ

Шифрований DNS зосереджений на захисті лінії зв'язку між клієнтом і рекурсивним резолвером. Кожен із сучасних стандартів оптимізує певний транспортний рівень:

DNS over TLS (DoT - RFC 7858)

DoT відокремлює стандартний вебтрафік і працює через фіксований TCP-порт 853. Це забезпечує сувору автентифікацію сервера через сертифікати X.509 і захищає від аналізу вмісту запитів. Проте фіксований порт 853 може легко виявлятися мережевими фільтрами корпоративних систем.

DNS over HTTPS (DoH - RFC 8484)

DoH передає бінарні запити DNS всередині сесій HTTP/2 або HTTP/3 через стандартний порт TCP 443. Запити зливаються зі звичайним вебтрафіком, що ускладнює їхню ізольовану фільтрацію. Крім того, DoH підтримує функцію Server Push для оптимізації попереднього завантаження ресурсів.

DNS over QUIC (DoQ - RFC 9250)

DoQ функціонує поверх протоколу QUIC (UDP), комбінуючи нульовий час встановлення з'єднання (0-RTT), стійкість до втрати пакетів без блокування черги (head-of-line blocking) та вбудоване шифрування TLS 1.3. Це робить DoQ ефективним вибором для мобільних пристроїв, що часто змінюють точки підключення до мережі.

Чому шифрований DNS не замінює DNSSEC

Шифрований тунель захищає лише відрізок мережі між вашим пристроєм і сервером резолвера. Якщо ви звертаєтеся до публічного резолвера, що не виконує валідацію DNSSEC, цей сервер може отримати підроблену відповідь від скомпрометованих проміжних маршрутизаторів. Шифрований канал сумлінно доставить вам підроблений результат, забезпечивши фальшиве відчуття захищеності.

Правильна архітектура вимагає, щоб резолвер підтверджував ланцюжок DNSSEC для авторитетних зон і передавав клієнту прапорець автентифікованих даних (AD — Authenticated Data).

Продуктивність та фрагментація пакетів

Звичайний пакет DNS має розмір 60–100 байт. Увімкнення DNSSEC додає підписи RRSIG та відкриті ключі, що збільшує обсяг відповіді до 1200–1800 байт. У класичному UDP це спричиняло фрагментацію IP-пакетів або вимагало переходу на повільний TCP.

Використання DoH, DoT або DoQ повністю усуває цю проблему: транспортні рівні TLS та QUIC ефективно сегментують великі криптографічні дані всередині повнорозмірних кадрів без втрати продуктивності.

Комплексний підхід до захисту DNS у системі VPNRice

Для максимального захисту конфіденційності потрібна синергія безпечного локального каналу та автентифікації віддалених записів. Саме такий підхід реалізовано у VPNRice.

Під час увімкнення VPNRice усі запити на визначення доменних імен спрямовуються безпосередньо у захищений тунель RiceGuard третього рівня Layer 3. Це виключає витоки DNS та унеможливлює аналіз мережевих дій оператором зв'язку.

На вихідних вузлах рекурсивні резолвери VPNRice, налаштовані без збереження журналів активності, проводять строгу валідацію DNSSEC за глобальним кореневим ланцюжком. Фальшиві записи та спроби отруєння кешу своєчасно відсікаються на серверній стороні. Поєднуючи надійне тунельне шифрування із перевіркою справжності DNSSEC, VPNRice забезпечує цілісність та конфіденційність кожного з'єднання. Завантажити VPNRice.