Поддельные DNS-ответы роняют резолверы BIND 9 и отравляют их кэш

Шестнадцатого сентября 2026 года Internet Systems Consortium раскрыла 14 уязвимостей в BIND 9, самом распространённом наборе программ для работы DNS-серверов. Половина из них позволяет удалённо вывести сервер из строя одним запросом или небольшой их серией. Ещё четыре открывают путь к подмене содержимого кэша и записей доменных зон. Исправления появились в тот же день, а сведений об активной эксплуатации у разработчиков нет.

Детали уязвимостей

Проблемы затрагивают все поддерживаемые ветки BIND 9, включая закрытую ветку предварительного доступа, которую ISC поставляет заказчикам поддержки. Часть ошибок живёт в коде годами, поэтому старые выпуски уязвимы не меньше новых. BIND обслуживает доменные зоны операторов связи, банков, государственных структур и университетов. Сбой в резолвере, то есть в сервере, который сам ищет ответы и кэширует их, лишает пользователей доступа к сайтам, почте и внутренним сервисам компании. Поскольку один узел именования обслуживает сразу тысячи клиентов, цена ошибки измеряется не одним рабочим местом.

Большинство выявленных проблем ведёт к отказу в обслуживании. Если резолвер закэшировал дерево служебных записей SVCB/HTTPS, описывающих параметры подключения к сервисам, то запрос к корню этого дерева заставляет его тратить несоразмерно много процессорного времени. Повторение таких запросов исчерпывает ресурсы и останавливает обработку обычных обращений. Родственная ошибка в разборе тех же записей вызывает утечку памяти: при обработке ссылок на большое число вложенных записей резолвер не освобождает служебные структуры, и потребление памяти растёт до исчерпания либо до принудительного завершения процесса операционной системой. Другие дефекты приводят к аварийному выходу процесса почти сразу. Атакующий добивается этого ответом ровно в 65536 байт, запросом устаревшего типа TKEY к конфигурации без глобального блока параметров, искажённым ответом на сервере с включённым DNS64 (механизмом преобразования адресов) и запросом DNS-over-HTTPS с заведомо неверной подписью, если соединение обрывается до окончания проверки.

Четыре уязвимости касаются целостности данных. Валидирующий резолвер принимает подписанную запись NSEC3 из соседней зоны как доказательство отсутствия защиты у делегирования, после чего пропускает подделанный ответ. Похожая ошибка с записями NSEC в DNSSEC, системе криптографической проверки доменных имён, позволяет скрыть существование шаблонной записи и провести отравление кэша. В третьем случае искажённая зона, загруженная на авторитетный сервер, превращает служебный узел за пределами зоны в точку делегирования: сервер, совмещающий авторитетную работу с рекурсией, начинает кэшировать записи злоумышленника и отдаёт их клиентам. Наконец, при передаче изменений зоны сервер применяет присланные данные до проверки подписи TSIG, то есть механизма аутентификации передачи зон по общему секрету. Злоумышленник без действующего ключа добавляет в зону произвольные записи, если передача идёт несколькими сообщениями по TCP. Отравленный кэш живёт до истечения срока хранения записей, поэтому последствия заметны ещё долго после успешной атаки.

Случаев активной эксплуатации этих уязвимостей пока нет. Часть ошибок нашла команда ISC во время внутреннего тестирования, остальные принесли сторонние исследователи, среди них Henrique Pereira, Rintaro Kawasugi и Samy Medjahed. Многие дефекты требуют от атакующего контроля над авторитетным сервером либо умения навязать резолверу определённую последовательность ответов с определённой задержкой. Такие условия сужают круг целей, но не снимают риск для публичных резолверов провайдеров, которые обрабатывают запросы сотен тысяч клиентов и потому интересны в первую очередь. Ошибки с аварийным выходом процесса не требуют ни валидных подписей, ни доверенных зон, что делает их самым доступным сценарием для массовых попыток.

Обновления вышли в выпусках 9.20.29 и 9.21.26; заказчикам поддержки адресована сборка 9.20.29-S1. Обходных путей разработчики не предлагают, поэтому защита сводится к смене версии. Старые ветки патчей не получат: ISC сопровождает только актуальные выпуски, и администраторам придётся перейти на поддерживаемую ветку целиком. Перед обновлением полезно сохранить конфигурацию и проверить, полагается ли сервер на записи SVCB/HTTPS или на DNS64, чтобы потом отследить изменения в поведении. Для крупных инсталляций разумно обновлять узлы последовательно, оставляя рабочий резолвер до проверки нового.

DNS держит на себе всю остальную инфраструктуру, и один упавший резолвер уносит доступ к десяткам сервисов сразу. Семь уязвимостей с оценкой 7.5 по CVSS закрываются обычным обновлением, а эксплойт (код, использующий уязвимость) для части из них состоит из одного пакета. Разрыв в несколько дней между публикацией бюллетеня и установкой патча даёт атакующим окно, которого можно избежать. Обновить резолверы и авторитетные серверы имеет смысл в течение суток, а уведомления о неожиданных перезапусках процесса помогут заметить первые попытки эксплуатации.

Детали уязвимостей

Ссылки