Безопасный DNS: DNSSEC и DNS через HTTPS (DoH)

Система доменных имён (DNS) преобразует понятные человеку доменные имена в IP-адреса. Разработанный в 1980-х годах DNS создавался без средств защиты: запросы и ответы передаются через порт 53 UDP/TCP в открытом виде и без аутентификации. Это создаёт две основные уязвимости: отравление кэша DNS (внедрение поддельных ответов DNS для перенаправления пользователей на вредоносные серверы) и перехват запросов DNS (наблюдение за доменами, которые запрашивает пользователь, раскрывает его действия в интернете). Эти проблемы решают два стандарта: DNSSEC предотвращает подделку, а DNS over HTTPS (DoH) предотвращает перехват.

Отравление кэша DNS (атака Kaminsky) использует отсутствие аутентификации в протоколе DNS. Resolver отправляет запрос авторитетному DNS-серверу и кэширует ответ на время, определяемое TTL. Атакующий, способный угадать идентификатор транзакции (16-разрядный и предсказуемый) и исходный порт (используется как дополнительный источник энтропии согласно RFC 5452), может отправить поддельные ответы, которые Resolver сохранит в кэше, перенаправив всех пользователей этого Resolver на сервер атакующего. После отравления кэша пользователи направляются на поддельные серверы, даже если ввели правильный домен. DNSSEC предотвращает это, подписывая ответы DNS цифровой подписью.

DNSSEC добавляет к записям DNS криптографические подписи, позволяя Resolver проверять, что ответы поступили от легитимного владельца зоны и не были изменены. DNSSEC вводит новые типы записей: RRSIG (подпись записи ресурса, фактическая подпись набора записей), DNSKEY (открытый ключ, используемый для проверки подписей), DS (подписывающая запись делегирования, связывающая ключи родительской и дочерней зон) и NSEC/NSEC3 (аутентифицированное подтверждение отсутствия — доказывает, что имя не существует). DNSSEC создаёт цепочку доверия от корневой зоны (подписанной ICANN) через TLD до авторитетных зон.

DNSSEC использует два типа ключей подписи. Zone Signing Key (ZSK) подписывает отдельные наборы записей DNS (RRSIG) и часто заменяется (ежемесячно или ежеквартально) для гибкости эксплуатации. Key Signing Key (KSK) подписывает набор записей DNSKEY, обеспечивая якорь доверия для зоны. KSK заменяется реже (ежегодно), поскольку при каждом изменении KSK родительскую зону необходимо обновлять новой записью DS — этот процесс требует координации. KSK проверяет ZSK, а ZSK подписывает данные. Такая двухуровневая структура уравновешивает безопасность (частая замена ZSK) и эксплуатационные затраты (редкая замена KSK).

У DNSSEC есть важные ограничения. Он не шифрует запросы DNS — он лишь подписывает ответы для обеспечения целостности. Перехватчик по-прежнему может видеть все запросы DNS, но не может подделывать ответы. Перечисление зоны: записи NSEC (подтверждающие отсутствие имён) позволяют атакующим обходить зону и перечислять все доменные имена внутри неё; NSEC3 снижает этот риск с помощью хешированных имён, но не устраняет его полностью. Эксплуатационная сложность: управление ключами, истечение срока действия подписей и координация с родительской зоной создают значительные эксплуатационные затраты. Распространение DNSSEC остаётся неполным: многие TLD и регистраторы его поддерживают, но многие организации ещё не внедрили эту технологию.

DNS через HTTPS (DoH) шифрует DNS-запросы внутри HTTPS (RFC 8484), скрывая их содержимое от наблюдателей в сети. Запросы отправляются на совместимый с DoH распознаватель по стандартному URL HTTPS, благодаря чему DNS-трафик невозможно отличить от другого HTTPS-трафика. Это не позволяет интернет-провайдерам, работодателям и атакующим, перехватывающим трафик, видеть, какие домены запрашивает пользователь, — таким образом устраняется пробел в конфиденциальности, который оставляет DNSSEC. Однако DoH переносит доверие с DNS-распознавателя сети на поставщика DoH (обычно Google 8.8.8.8, Cloudflare 1.1.1.1 или собственный DoH-распознаватель организации). Теперь DoH изначально поддерживается большинством популярных браузеров.

DNS через TLS (DoT) (RFC 7858) шифрует DNS-запросы с помощью TLS через выделенный TCP-порт 853, а не туннелирует их через HTTPS. DoT обеспечивает те же преимущества конфиденциальности, что и DoH, — скрывает содержимое запросов от перехватчиков, — но администраторам сети проще его обнаруживать и фильтровать (порт 853 вместо порта 443). Это палка о двух концах: DoT виден в сети, и корпоративные межсетевые экраны могут его блокировать, тогда как DoH сложнее заблокировать, не затронув обычный HTTPS-трафик. Локальные распознаватели (на уровне OS) чаще используют DoT, а браузеры — DoH.

Зашифрованный DNS создаёт проблему для сред Enterprise, зависящих от фильтрации на основе DNS и sinkhole-механизмов. Когда браузеры используют внешние распознаватели DoH, внутренние средства управления DNS обходятся. Меры защиты Enterprise: развернуть внутренний распознаватель DoH/DoT (Cisco Umbrella, Pi-hole с DoH) и настроить все устройства на его использование; заблокировать IP-адреса внешних распознавателей DoH на межсетевом экране (Google 8.8.8.8, Cloudflare 1.1.1.1) на порту 443; использовать Group Policy для отключения DoH на уровне браузера на управляемых конечных устройствах; а также настроить правила прозрачного прокси, перехватывающего DNS через TLS на порту 853. Цель — направлять весь DNS-трафик через контролируемый распознаватель, не блокируя зашифрованный DNS полностью.

Полная стратегия безопасности DNS объединяет несколько средств контроля. DNSSEC для авторитетных зон предотвращает подмену записей в кэше вашего домена. Фильтрация на основе DNS (Cisco Umbrella, Cloudflare Gateway) блокирует вредоносные домены на уровне распознавателя. DoH/DoT к контролируемому распознавателю обеспечивает конфиденциальность запросов без потери видимости фильтрации. Ведение журналов DNS в SIEM сохраняет все запросы для поиска угроз — журналы DNS раскрывают C2-трафик, извлечение данных через DNS-туннелирование и активность алгоритма генерации доменов (DGA) вредоносных программ. Телеметрия DNS — один из наиболее ценных доступных источников данных для безопасности.

DNS-туннелирование кодирует данные внутри DNS-запросов и ответов, чтобы извлекать данные или устанавливать каналы C2 через сети, где другой исходящий трафик заблокирован. Такие инструменты, как iodine, DNScat и dnscat2, кодируют полезную нагрузку в метках поддоменов (запрос к EXFILTRATEDDATA.evil.com) или записях TXT. Обнаружение: необычно длинные имена DNS-запросов (более 100 символов), большой объём запросов с одного узла, запросы к несуществующим родительским доменам, необычные типы записей (TXT, NULL) и анализ энтропии меток домена (закодированные данные имеют высокую энтропию Шеннона). Платформы аналитики безопасности DNS автоматически выявляют шаблоны туннелирования.

Зоны политик ответов DNS (RPZ) позволяют распознавателям DNS применять локальные политики переопределения к ответам DNS, фактически создавая локальный sinkhole на уровне распознавателя без изменения глобальной инфраструктуры DNS. Когда клиент запрашивает известный вредоносный домен, политика RPZ возвращает NXDOMAIN, перенаправляет запрос на IP-адрес sinkhole или пропускает ответ без изменений. Каналы RPZ доступны у поставщиков аналитики угроз (Spamhaus, SURBL) и могут напрямую импортироваться в распознаватели BIND или Unbound. RPZ — мощный инструмент защиты, поскольку применяет фильтрацию на уровне DNS ко всем устройствам в сети без настройки на стороне клиента.

Проверьте понимание концепций CompTIA Security+ (SY0-701) из этого урока.

В этом уроке Вы узнали следующее: DNSSEC добавляет к записям DNS криптографические подписи с помощью пар ключей KSK/ZSK, предотвращая отравление кэша, но не шифрует запросы; DNS через HTTPS (DoH) шифрует DNS-запросы внутри HTTPS, предотвращая перехват, но создаёт риски обхода корпоративной фильтрации; DNS-туннелирование кодирует данные в DNS-запросах и обнаруживается по длине и объёму запросов, а также с помощью анализа энтропии. Далее мы рассмотрим IPsec, протоколы VPN и безопасность удалённого доступа.