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

Спустя десятилетия для устранения этих фундаментальных уязвимостей появились две независимые концепции: система расширений безопасности DNSSEC и протоколы шифрованного DNS (включая DNS-over-HTTPS, DNS-over-TLS и DNS-over-QUIC). Однако на практике между ними нередко возникает путаница. Многие администраторы полагают, что активация DoH или DoT делает валидацию DNSSEC избыточной, либо ошибочно считают, что развертывание DNSSEC обеспечивает тайну переписки.

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

Две стороны безопасности DNS: подлинность против конфиденциальности

Чтобы сопоставить зоны ответственности обеих технологий, проследим путь доменного запроса. Устройство пользователя (клиентский резолвер) направляет запрос рекурсивному серверу провайдера. Тот поочередно опрашивает корневые серверы (Root), серверы доменных зон верхнего уровня (TLD) и, наконец, авторитетные серверы домена, после чего возвращает готовый IP-адрес клиенту.

Функциональное разделение контуров безопасности выглядит следующим образом:

  • Шифрованный DNS (DoH, DoT, DoQ): Защищает исключительно отрезок сети между клиентским устройством и рекурсивным резолвером. Инкапсуляция трафика в TLS 1.3 или QUIC предотвращает перехват данных в публичных сетях Wi-Fi, блокирует сбор аналитики операторами связи и не дает сетевым шлюзам модифицировать ответы на лету. Однако данный протокол не способен подтвердить, являются ли полученные сервером данные подлинными.
  • DNSSEC (RFC 4033, RFC 4034, RFC 4035): Гарантирует целостность и подлинность записей, опубликованных владельцем зоны. Используя асимметричную криптографию, DNSSEC подтверждает, что пришедший ответ исходит именно от легитимного держателя домена и не был сфальсифицирован при атаках на кэш (cache poisoning). При этом сам трафик DNSSEC идет в открытом виде; цифровые подписи удостоверяют подлинность, но не скрывают факт обращения к домену.

Криптографическая цепочка доверия в архитектуре DNSSEC

DNSSEC формирует неразрывную иерархическую цепь криптографических подписей, берущую начало от глобального якоря доверия в корневой зоне ICANN.

Архитектура опирается на четыре ключевых типа ресурсных записей:

  • Подпись набора записей (RRSIG): Содержит электронную цифровую подпись для конкретной группы записей (например, записей A или AAAA). Резолвер проверяет эту подпись с помощью открытого ключа доменной зоны.
  • Открытые ключи зоны (DNSKEY): Публикует открытые криптографические ключи домена. Как правило, зона использует ключ подписи зоны (ZSK) для регулярных записей и ключ подписи ключей (KSK) для заверения набора DNSKEY.
  • Подтверждение делегирования (DS): Размещается в родительской зоне для удостоверения дочерней. Запись DS содержит криптографический хэш ключа KSK дочерней зоны. При проверке домена резолвер сверяет хэш в реестре верхнего уровня, убеждаясь, что ключ не был подменен.
  • Подтверждение отсутствия имени (NSEC и NSEC3): Стандартный DNS при отсутствии имени возвращает пустой ответ NXDOMAIN. DNSSEC криптографически доказывает факт отсутствия записи с помощью подписанных интервалов (RFC 5155), исключая возможность генерации ложных сообщений об ошибках.

Если злоумышленник пытается отравить кэш резолвера фиктивным IP-адресом, криптографическая валидация проваливается: подделка не содержит валидной подписи, согласованной с родительской записью DS. Рекурсивный сервер фиксирует нарушение целостности и возвращает код ошибки SERVFAIL, блокируя подключение к подставному ресурсу.

Протоколы шифрованного DNS: защита транзитного участка

Несмотря на гарантированную аутентичность записей в DNSSEC, сами запросы остаются абсолютно прозрачными для внешнего наблюдения. Провайдеры интернета могут логировать открытые пакеты на порту 53, а инспекционные шлюзы используют открытый текст для выборочного вмешательства в маршрутизацию.

Протоколы шифрования устраняют уязвимость транзитного участка с помощью трех стандартов:

  • DNS-over-TLS (DoT, RFC 7858): Передает стандартные пакеты DNS по каналу TLS через выделенный порт TCP 853. DoT отличается минимальными накладными расходами, однако выделенный порт может выборочно блокироваться администраторами корпоративных сетей.
  • DNS-over-HTTPS (DoH, RFC 8484): Помещает запросы DNS внутрь сессий HTTP/2 или HTTP/3 через стандартный порт 443. Внешне трафик DoH неотличим от обычного защищенного веб-серфинга, что не позволяет промежуточным устройствам избирательно блокировать DNS без отключения всего веб-трафика.
  • DNS-over-QUIC (DoQ, RFC 9250): Реализует отправку запросов поверх независимых потоков QUIC. Это исключает задержки очереди при потере пакетов и обеспечивает нулевое время задержки (0-RTT) при переключении между вышками сотовой связи.

Опасность слепого доверия шифрованному DNS без валидации DNSSEC

Распространенным заблуждением является уверенность в том, что использование шифрованного DoH-канала само по себе обеспечивает защиту от подделки адресов. В действительности шифрование без криптографической проверки источника создает защищенную трубу к неизвестному содержимому.

Уязвимый сценарий выглядит следующим образом:

  • Клиент устанавливает защищенную сессию DoH с публичным сервером имен через порт 443.
  • Транзитный канал надежно защищен от перехвата и локальной модификации.
  • Однако если авторитетный сервер зоны скомпрометирован или кэш резолвера отравлен на вышестоящем участке, сервер сохраняет поддельный IP-адрес.
  • Резолвер упаковывает сфальсифицированную запись в защищенный ответ DoH и отправляет клиенту.
  • Устройство проверяет сертификат TLS резолвера, считает полученный адрес надежным и переходит прямо на фишинговый сервер атакующих.

Без валидации DNSSEC защищенный канал лишь надежно доставляет скомпрометированную информацию. Надежная схема требует, чтобы резолвер проверял всю цепочку подписей DNSSEC и выставлял флаг проверенных данных (AD) только после успешной верификации.

Оптимизация производительности и устранение фрагментации пакетов

Совместное использование DNSSEC и шифрования требует внимания к размеру передаваемых пакетов. Обычный ответ DNS занимает около 60–100 байт. Однако при добавлении подписей RRSIG и открытых ключей DNSKEY объем данных возрастает до 1200–1800 байт.

В традиционном протоколе UDP пакеты крупнее 512 байт требовали расширений EDNS0 (RFC 6891), часто подвергались фрагментации на уровне IP или принудительно переключались на медленный TCP. Перенос трафика в DoH и DoT решает проблему фрагментации: сессии TLS и QUIC без труда передают большие криптографические структуры внутри единого окна передачи.

Единая архитектура разрешения имен в инфраструктуре VPNRice

Защита конфиденциальности в сети требует сбалансированного сочетания шифрования локального канала и валидации вышестоящих данных. VPNRice объединяет эти требования непосредственно в сетевом стеке.

При активации VPNRice все запросы на разрешение доменных имен мгновенно направляются внутрь туннеля RiceGuard третьего уровня Layer 3. Это исключает утечки DNS и не позволяет операторам связи отслеживать посещаемые ресурсы.

На выходных узлах сети выделенные рекурсивные серверы VPNRice, функционирующие без ведения системных журналов, выполняют полную криптографическую проверку подписей DNSSEC по глобальному корневому ключу. Фальшивые записи и попытки отравления кэша пресекаются до отправки клиенту. Совмещая сквозное шифрование туннеля с проверкой подлинности DNSSEC, VPNRice гарантирует конфиденциальность и надежность ваших сетевых подключений. Скачать VPNRice.