“DNS, это механизм распределённого доверия. Он переводит имена в адреса, но делает это не по справочнику, а через цепочку делегирования полномочий. Его устойчивость условна — она держится на доверии к тысячам независимых операторов и на корректности их конфигураций. Сбой в одном звене, от корневого сервера до локального провайдера, может сделать невидимым целый сегмент сети.”
Как работает DNS: от запроса до ответа
Вы вводите имя сайта, но операционная система не понимает символов. Ей нужен числовой адрес. Запрос сначала попадает к резолверу — программе, часто встроенной в роутер или предоставляемой провайдером. Этот резолвер начинает итеративный или рекурсивный поиск.
Поиск идёт сверху вниз. Резолвер обращается к одному из корневых серверов. Эти серверы не знают ничего про конкретные домены, но хранят информацию о серверах доменов верхнего уровня — TLD. Для домена .ru корневой сервер отвечает адресами серверов, ответственных за всю зону .ru.
Резолвер запрашивает TLD-сервер. Тот, в свою очередь, не знает конечного IP-адреса, но знает авторитативные серверы для искомого домена. Он возвращает их адреса.
Финальный запрос уходит на авторитативный сервер домена. Именно он содержит искомую запись A или AAAA с IP-адресом. Этот адрес возвращается по цепочке обратно к вашему устройству.
Каждый шаг может кэшироваться. Ваша система, локальный резолвер провайдера, промежуточные серверы — все хранят полученные ответы на время TTL, указанное в записи. Это снижает нагрузку, но создаёт точку для атаки — отравления кэша.
Типы DNS-записей: не только адреса
Запись A — лишь верхушка айсберга. DNS, это распределённая база данных для конфигурации сетевых служб. Подмена разных типов записей ведёт к разным последствиям.
| Тип записи | Назначение | Практическое применение и риск |
|---|---|---|
| A / AAAA | Связывает имя с IPv4 или IPv6 адресом | Базовая маршрутизация веб-трафика. Подмена ведёт к фишингу или блокировке доступа. |
| MX | Указывает серверы для приёма почты домена | Определяет, куда отправлять письма на user@domain. Подмена позволяет перехватывать всю электронную почту организации. |
| CNAME | Создаёт алиас, перенаправляя одно имя на другое | Используется для CDN, поддоменов. Ошибка в CNAME ломает все подчинённые сервисы. |
| TXT | Произвольные текстовые данные | Критичны для безопасности: записи SPF, DKIM, DMARC для проверки отправителя почты; верификация владения доменом для SSL-сертификатов. |
| NS | Указывает авторитативные DNS-серверы для домена | Запись высшего приоритета. Подмена NS-записей у регистратора фактически передаёт управление всем доменом злоумышленнику. |
| PTR | Обратное сопоставление IP-адреса с именем | Используется для проверок отправителя почты и сетевой диагностики. Неправильные PTR-записи могут привести к блокировке почтового трафика. |
| SRV | Определяет хост и порт для специфичных служб | Используется для VoIP (SIP), LDAP, XMPP. Сбой нарушает работу этих прикладных протоколов. |
Уязвимости и атаки на DNS
Протокол проектировался для устойчивости, а не для секретности. Запросы и ответы передаются в открытом виде по UDP, что открывает возможности для вмешательства.
Отравление кэша (DNS Cache Poisoning)
Атакующий пытается подсунуть резолверу ложный ответ быстрее, чем придёт легитимный с авторитативного сервера. Успех закрепляет этот ложный IP-адрес в кэше резолвера на долгое время, перенаправляя всех его пользователей на фальшивый сервер. Классический метод — угадывание идентификатора транзакции в DNS-пакете.
Усиленные DNS DDoS-атаки (Amplification)
Атакующие отправляют небольшие DNS-запросы с поддельным адресом отправителя (жертвы) на серверы, поддерживающие рекурсивные запросы и отвечающие большими пакетами. Ответы в десятки раз превышают запрос по объёму. Трафик обрушивается на жертву, переполняя её канал. Используются записи типа ANY или EDNS0 для увеличения размера ответа.
Перехват и подмена на пути
В незащищённой сети злоумышленник может прослушивать DNS-трафик и вставлять свои ответы. Также возможна атака на резолвер внутри сети, если он сконфигурирован небезопасно и принимает запросы извне или использует уязвимое ПО.
Меры защиты: DNSSEC, DoT, DoH
Эти протоколы дополняют друг друга, решая разные задачи.
DNSSEC добавляет цифровые подписи ко всем записям в цепочке доверия, от корневой зоны до вашего домена. Резолвер с включённой валидацией проверяет эти подписи. Если запись изменена в пути, подпись не совпадёт, и ответ будет отвергнут. DNSSEC не шифрует трафик, а только гарантирует его целостность и аутентичность источника.
DNS over TLS (DoT) поднимает зашифрованное TLS-соединение с резолвером на специальном порту 853. Это защищает от прослушивания и манипуляций с запросами между клиентом и резолвером. Трафик выглядит как отдельный зашифрованный поток.
DNS over HTTPS (DoH) идёт дальше, упаковывая DNS-запросы в обычные HTTPS-сессии на порту 443. Для сетевого наблюдателя это неотличимо от другого веб-трафика. Это повышает конфиденциальность, но усложняет фильтрацию и мониторинг DNS на уровне сети, что вызывает вопросы у администраторов корпоративных сетей.
DNS в контексте российского регулирования
Работа DNS-инфраструктуры в России подпадает под требования устойчивости сегмента сети интернет. Операторы связи обязаны использовать специальные технические средства для фильтрации запросов к запрещённым ресурсам. Фактически это означает, что публичные и ISP-резолверы должны сверяться с актуальным реестром и блокировать обращение к указанным доменам.
Для организаций — субъектов персональных данных (152-ФЗ) и критической информационной инфраструктуры (КИИ) — настройка DNS переходит из разряда сетевой рутины в область обеспечения безопасности. Рекомендуется:
- Развёртывание внутренних, контролируемых DNS-серверов, исключающее зависимость от внешних недоверенных резолверов.
- Настройка фильтрации на этих серверах не только по реестрам, но и по категориям нежелательных ресурсов для снижения рисков заражения.
- Внедрение валидации DNSSEC на внутренних резолверах для гарантии целостности ответов, получаемых извне.
- Сбор и анализ DNS-логов. Аномалии в запросах (частые обращения к доменам с случайными именами, использование DGA — Domain Generation Algorithm) часто сигнализируют о наличии вредоносного ПО в сети.
Отказ DNS-сервиса внутри организации парализует современную инфраструктуру, построенную на микросервисах, облачных сервисах аутентификации (например, OAuth, Active Directory) и внешних API. Поэтому отказоустойчивая архитектура с резервированием серверов и грамотным кэшированием — обязательное требование.
Практические шаги для администратора
Следующие действия формируют базовый уровень защиты DNS в корпоративной среде.
- Контроль над резолверами. Жёстко настройте на всех конечных устройствах и серверах использование только доверенных внутренних DNS-серверов. Отключите возможность автоматического выбора резолвера.
- Принудительная валидация DNSSEC. Включите проверку подписей на ваших внутренних резолверах. Убедитесь, что корневые зонные ключи (trust anchors) актуальны.
- Мониторинг аномалий. Внедрите системы, которые отслеживают частоту и характер DNS-запросов. Обращайте внимание на:
- Попытки разрешения доменов, связанных с известными C&C-серверами.
- Массовые запросы к несуществующим доменам (NXDOMAIN), что может указывать на сканирование или работу вредоноса.
- Использование нестандартных портов или протоколов для DNS-трафика.
- Ограничение рекурсии. Сконфигурируйте ваши авторитативные DNS-серверы так, чтобы они не выполняли рекурсивные запросы для клиентов из интернета. Рекурсия должна быть разрешена только для доверенных внутренних сетей или отдельных резолверов.
- Актуальность ПО и конфигураций. Регулярно обновляйте DNS-серверное ПО (BIND, PowerDNS, Knot Resolver). Проводите аудит зонных файлов, удаляя устаревшие и потенциально уязвимые записи, проверяйте корректность TTL и NS-записей.
DNS, это фундамент, который обычно не виден, пока не даст трещину. Понимание его внутренней механики, векторов атак и современных средств криптографической защиты позволяет строить инфраструктуру, которая не просто работает, но и сопротивляется целенаправленным воздействиям.