DNS выступает телефонной книгой интернета, преобразуя удобные для человека имена в машинные IP-адреса. С точки зрения системного администратора, это просто механизм маршрутизации запросов. Для аналитика безопасности тот же самый механизм представляет собой подробный журнал перемещений, где каждый запрос фиксирует намерение пользователя до начала передачи зашифрованных данных
Механика преобразования имён и многоуровневое кэширование
Сеть устроена так, что маршрутизаторы и серверы общаются исключительно через числовые идентификаторы. Запоминать последовательности цифр неудобно, поэтому придумали систему доменных имён. Когда пользователь вводит адрес в браузере, операционная система отправляет запрос к локальному резолверу.
Процесс разрешения имени проходит по иерархии. Сначала запрос уходит к корневым серверам, которых в мире существует тринадцать логических кластеров, обозначаемых буквами от A до M. Корневой сервер не знает точного IP-адреса, но указывает на сервер верхнего уровня домена, например, .ru или .com. Тот, в свою очередь, направляет запрос к авторитативному серверу, который уже хранит точную запись для конкретного домена.
Чтобы не нагружать эту цепочку тысячами одинаковых запросов каждую секунду, повсеместно применяется кэширование. Браузер сохраняет ответ на несколько минут. Операционная система хранит его в своей таблице чуть дольше. Маршрутизатор в домашней или офисной сети держит кэш ещё дольше, а провайдер сохраняет записи на срок, указанный в параметре TTL самой записи. Такой подход ускоряет загрузку страниц и снижает нагрузку на глобальную инфраструктуру, но создаёт задержку при обновлении реальных IP-адресов на стороне владельца домена.
Типы записей и их реальное применение
База данных DNS состоит из множества типов записей, каждая из которых решает конкретную задачу. Понимание их назначения помогает не только настраивать инфраструктуру, но и выявлять аномалии в сетевой активности.
| Тип записи | Назначение | Практический пример использования |
|---|---|---|
| A | Сопоставление домена с IPv4-адресом | Основной адрес веб-сервера компании. |
| AAAA | Сопоставление домена с IPv6-адресом | Поддержка современных сетей без трансляции адресов. |
| CNAME | Псевдоним, указывающий на другое доменное имя | Привязка короткого адреса app.company.local к длинному имени ресурса в облачном провайдере xyz123.cloudprovider.net. |
| MX | Указание почтового сервера для домена | Маршрутизация входящей корпоративной почты на конкретный кластер обработки. |
| TXT | Произвольный текст для верификации | Размещение ключей SPF и DKIM для подтверждения подлинности отправителя писем. |
| SRV | Описание расположения конкретного сервиса с указанием порта и протокола | Настройка клиентов для автоматического поиска внутреннего сервера голосовой связи или игрового сервера на нестандартном порту. |
Использование CNAME стало стандартом при работе с облачными сервисами. Провайдер выдаёт длинное и сложное доменное имя для развёрнутого приложения. Администратор создаёт CNAME-запись, которая прозрачно перенаправляет запросы с короткого корпоративного адреса на целевой ресурс провайдера. При смене инфраструктуры провайдера достаточно обновить одну запись, не меняя настройки у тысяч конечных пользователей.
Записи SRV решают проблему, когда сервис работает не на стандартном порту. Клиентское приложение запрашивает SRV-запись домена и получает точные инструкции: подключаться по протоколу TCP к порту 8443 конкретного хоста. Такой подход избавляет пользователей от необходимости вручную вводить номера портов в настройках.
Форвардинг и уязвимость цепочки доверия
В корпоративных сетях локальный DNS-сервер часто не имеет прямых связей с корневыми узлами. Вместо этого он использует форвардинг. Получив запрос, который отсутствует в локальном кэше, сервер перенаправляет его вышестоящему резолверу, обычно принадлежащему интернет-провайдеру или специализированному публичному сервису.
Изначально протокол DNS разрабатывался для открытой и доверенной среды. Запросы и ответы передаются в открытом виде по порту 53 через UDP или TCP. Любой участник сети, через которую проходит трафик, может прочитать содержимое запроса. Более того, отсутствие криптографической защиты позволяет злоумышленнику, контролирующему участок сети, подменить ответ. Пользователь запрашивает адрес банковского портала, а в ответ получает IP-адрес фишингового ресурса. Операционная система слепо доверяет этому ответу и устанавливает соединение с поддельным сервером.
Шифрование канала через DoH и DoT
Для защиты от прослушивания и подмены ответов на уровне сети были разработаны протоколы шифрования DNS-трафика.
DNS over TLS (DoT) создаёт выделенный зашифрованный канал на порту 853. Операционная система или резолвер устанавливает TLS-соединение с доверенным сервером и передаёт запросы внутри этого туннеля. Сторонний наблюдатель видит факт соединения с DNS-сервером, но не может прочитать, какие именно домены запрашиваются.
DNS over HTTPS (DoH) использует другой подход. Запросы инкапсулируются в обычный HTTPS-трафик и отправляются на порт 443. Для сетевого оборудования такой трафик неотличим от посещения обычного веб-сайта. DoH часто применяется на конечных устройствах, так как позволяет обойти корпоративные системы фильтрации, которые пытаются контролировать DNS-запросы на уровне шлюза.
Оба метода эффективно защищают от атак человек-посередине в локальной сети и от сбора статистики провайдером на уровне DNS. Они скрывают содержимое запроса от любого, кто не является конечным резолвером.
Гарантия целостности данных через DNSSEC
Шифрование канала, обеспечиваемое DoH и DoT, защищает только путь передачи данных. Оно не гарантирует, что ответ, пришедший от авторитативного сервера, является подлинным. Если злоумышленник скомпрометирует сам DNS-сервер или внедрит поддельную запись в кэш вышестоящего узла, зашифрованный канал просто доставит пользователю корректно подписанный, но ложный ответ.
DNSSEC решает задачу аутентификации источника данных. Владелец домена криптографически подписывает свои DNS-записи закрытым ключом. Публичный ключ хранится в родительской зоне и так далее до корневого сервера, формируя цепочку доверия. При получении ответа резолвер проверяет цифровую подпись. Если подпись не совпадает или отсутствует, ответ отвергается как поддельный.
Внедрение DNSSEC требует значительных усилий по управлению криптографическими ключами и настройке оборудования, поэтому поддержка этой технологии варьируется в зависимости от доменной зоны и провайдера. Однако для критически важных сервисов проверка подписи остаётся единственным способом гарантировать, что полученный IP-адрес действительно принадлежит заявленному домену.
Почему открытый DNS раскрывает слишком много информации
Даже при использовании HTTPS для веб-трафика, стандартный DNS-запрос остаётся открытым текстом. Это создаёт серьёзную проблему конфиденциальности. Сетевой наблюдатель, анализирующий трафик, видит каждый запрос к доменному имени.
Возьмём типичный корпоративный сценарий. Сотрудник подключается к внутреннему порталу поиска работы или к внешнему сервису хранения файлов. Передача самих данных зашифрована, и содержимое файлов или введённые пароли перехватить невозможно. Однако сам факт обращения к конкретному домену фиксируется в открытом DNS-запросе.
Для систем мониторинга или злоумышленника, внедрившегося в сеть, эти метаданные представляют огромную ценность. По ним можно построить профиль интересов пользователя, выявить использование неавторизованных облачных сервисов или определить момент, когда сотрудник начинает искать новую работу. Перехват DNS-трафика требует минимальных вычислительных ресурсов по сравнению с попытками взлома шифрования, делая его одним из самых эффективных методов сбора разведывательных данных в корпоративной сети.
Переход на использование DoH или DoT на уровне конечных устройств или корпоративного шлюза закрывает этот вектор утечки метаданных. Аналитик безопасности должен проверить настройки резолверов в инфраструктуре и убедиться, что внешние запросы уходят через зашифрованный канал к доверенному провайдеру, поддерживающему проверку DNSSEC.