Каждый раз, когда пользователь открывает сайт, его устройство отправляет DNS-запрос для преобразования доменного имени в IP-адрес. Чтобы не выполнять один и тот же поиск заново при каждом запросе, DNS использует кеширование: рекурсивные резолверы временно сохраняют результаты предыдущих запросов.

При отравлении DNS-кеша (DNS cache poisoning) злоумышленники вмешиваются в этот процесс, подсовывая резолверу поддельную DNS-запись. Из-за этого пользователи начинают попадать не на настоящий сервер сайта, а в инфраструктуру атакующего. При этом домен в строке браузера остается корректным — меняется только IP-адрес, на который уходит трафик.

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

Вот как обычно происходит преобразование доменного имени в IP-адрес. Когда пользователь вводит адрес сайта в браузере, операционная система сначала проверяет локальный DNS-кеш. Если нужной записи там нет, запрос отправляется рекурсивному резолверу. Он последовательно обращается к DNS-иерархии от имени пользователя: сначала к корневым DNS-серверам, затем к серверам доменов верхнего уровня (TLD), а после — к авторитетному DNS-серверу нужного домена. Авторитетный сервер возвращает правильный IP-адрес, а резолвер сохраняет этот результат в кеше на указанное в ответе время хранения (TTL, time to live). До истечения TTL все последующие запросы к этому домену получают ответ из кеша без необходимости заново проходить весь процесс поиска.

Атака DNS cache poisoning использует промежуток между отправкой DNS-запроса и получением ответа. Пока резолвер ожидает ответ от настоящего DNS-сервера, злоумышленник отправляет большое количество поддельных DNS-ответов, каждый из которых связывает запрашиваемый домен с IP-адресом, находящимся под его контролем. Если один из таких ответов приходит раньше настоящего и совпадает с ожидаемыми значениями 16-битного ID транзакции и UDP-порта источника, резолвер принимает его за настоящий. После этого поддельная DNS-запись попадает в кеш и начинает выдаваться всем последующим пользователям в течение всего времени хранения ответа (TTL).

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

1. Классическая подмена DNS-ответов

Самый простой вариант DNS cache poisoning основан на переборе значений. ID транзакции имеет размер всего 16 бит — это 65 536 возможных комбинаций. В старых конфигурациях резолверов, где порты источника были фиксированными или предсказуемыми, злоумышленник мог подобрать оба значения с достаточно высокой вероятностью успеха. Современные резолверы используют рандомизацию портов источника, однако сама проблема гонки между настоящим и поддельным ответом по-прежнему может использоваться в более сложных сценариях атак.

2. Атака Камински

Впервые продемонстрированная в 2008 году атака Камински вывела DNS cache poisoning на новый уровень. Вместо подмены отдельной записи злоумышленник заставляет резолвер выполнить запрос к случайному несуществующему поддомену. Поскольку такого ответа нет в кеше, резолвер вынужден обратиться к авторитетному DNS-серверу.

В этот момент злоумышленник отправляет поддельный ответ, включающий фальшивый раздел полномочий (authority section), в котором DNS-сервер под его контролем указывается как ответственный за всю доменную зону. Если поддельный ответ приходит раньше настоящего, злоумышленник получает возможность контролировать DNS-ответы для всех записей данного домена.

3. SAD DNS — определение порта через сторонний канал

После публикации атаки Камински стандартным механизмом защиты от отравления кеша DNS стала рандомизация портов источника. Однако в 2020 году была представлена техника SAD DNS (Side-channel AttackeD DNS), которая показала, что эту защиту можно обойти.

Атака использует особенности механизма ограничения частоты обработки ICMP-пакетов (ICMP rate limiting) в ядре Linux, чтобы определить, какой временный порт использует резолвер для конкретного DNS-запроса. Отправляя специально сформированные UDP-пакеты и анализируя ICMP-ответы «port unreachable», злоумышленник может сократить количество возможных вариантов порта источника с десятков тысяч до нескольких значений. В сочетании с перебором ID транзакции это позволяет успешно проводить атаки DNS cache poisoning.

4. Атаки на основе фрагментации DNS-ответов

DNS-ответы, передаваемые по UDP, могут разбиваться на несколько IP-фрагментов, если их размер превышает MTU (Maximum Transmission Unit). Злоумышленник заставляет легитимный ответ разделиться на несколько фрагментов, оставляя первый фрагмент с легитимным заголовком неизменным и подменяя фрагменты, содержащие DNS-данные, собственным вредоносным содержимым.

Поскольку сборка IP-фрагментов выполняется на основе полей смещения (offset) и идентификатора, без криптографической проверки, резолвер собирает DNS-ответ, объединяющий легитимный заголовок с вредоносным содержимым злоумышленника. Проверка ID транзакции и UDP-порта при этом проходит успешно, поскольку эти поля находятся в первом, неизмененном фрагменте.

5. Локальная подмена DNS

В общих сетях, таких как публичный Wi-Fi или корпоративные гостевые сети, злоумышленник, имеющий локальный доступ, может напрямую перехватывать DNS-запросы с помощью спуфинга ARP (Address Resolution Protocol) или поддельных ответов DHCP (Dynamic Host Configuration Protocol).

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

Основным механизмом защиты от отравления DNS-кеша остается DNSSEC. Эта технология добавляет к DNS-записям криптографические подписи, позволяя резолверам проверять, что ответ действительно поступил от авторитетного DNS-сервера и не был изменен при передаче. Если DNS-запись не содержит корректной подписи, резолвер ее отклоняет. Однако DNSSEC работает только в том случае, если технологию поддерживают обе стороны — и владелец домена, и сам резолвер. Несмотря на длительное развитие стандарта, уровень внедрения DNSSEC остается относительно низким и составляет около 35%, что связано со сложностями настройки и сопровождения.

Частичную защиту обеспечивают DNS поверх HTTPS (DoH) и DNS поверх TLS (DoT), которые шифруют DNS-трафик между клиентом и резолвером. Это особенно важно в недоверенных сетях, где локальная подмена DNS наиболее вероятна.

Снизить последствия отравления кеша DNS в случае успешной атаки помогают меньшие значения TTL для критически важных DNS-записей. Чем меньше TTL, тем меньше времени поддельная запись сможет оставаться в кеше.

Кроме того, важную роль играет мониторинг DNS-трафика. Такие признаки, как резкие всплески количества DNS-запросов, неожиданные адреса источников или аномально большое число NXDOMAIN-ответов, могут использоваться для раннего обнаружения попыток отравления DNS-кеша.