dxdt.ru: занимательный интернет-журнал

Одной из распространённых ошибок настройки DNS является рассогласование списков авторитативных серверов имён на разных уровнях системы. То есть, в делегирующей записи присутствуют имена серверов, которые отсутствуют в самой DNS-зоне. Предположим, в зоне .com для example.com указаны серверы ns1.example.com, ns2.example.com и ns1.example.net (список делегирования), а в самой DNS-зоне example.com список NS-ов включает только ns1.example.com, ns2.example.com. Это пример упомянутой ошибки. (Список NS-ов из DNS-зоны – это ответ на запрос NS, полученный от авторитативного сервера.) Обратите внимание, что обратная ситуация, когда список делегирования вкладывается в список NS-ов на стороне DNS-зоны, проблемы не представляет. А вот если в делегирующей зоне обнаружен “лишний” NS, то это плохо и является грубой ошибкой.

Почему это так? Прежде всего потому, что “лишнее” имя может вообще не контролироваться администратором зоны – соответственно, это имя может контролировать третья сторона, которая, из-за неверного делегирования, получит возможность отвечать на DNS-запросы, относящиеся к исходной зоне. На всякий случай напомню, что управление DNS позволяет полностью перехватить все сервисы, адресуемые именами в DNS-зоне: можно переадресовать веб-сайт, получать электронную почту, получить валидный TLS-сертфикат и так далее.

Как сторона, строго полагающаяся на DNS в какой-то своей деятельности, может определить, что с настройками чужой зоны что-то не так на уровне NS-ов? Например, можно сравнить список делегирования и перечень авторитативных NS-ов в зоне. И сделать это можно, – как ни странно, – только специально опросив авторитативные NS-ы. Ответ авторитативных NS-ов вышестоящей зоны – принесёт достоверный список делегирования. А ответ авторитативных NS-ов целевой зоны – достоверный список NS-ов. И если первый список содержит имена, которых нет во втором, то это признак того, что с зоной что-то случилось: например, происходит перехват управления.

При этом, вообще говоря, достаточно, чтобы списки не сходились с ответом одного авторитативного NS целевой зоны. Поэтому-то списки авторитативных NS-ов, возвращаемые серверами целевой зоны, должны совпадать между серверами. Если эти списки отличаются, то ситуация тем более подозрительна, поскольку невозможно понять, какой список настоящий, а какой – подменный. Естественно, резолверы, выполняющие рекурсивный опрос, не всегда следуют правилу, что за окончательной версией большинства DNS-записей обращаться можно только к тем NS-ам, имена которых получены в авторитативном ответе, соответствующем целевой зоне. “Авторитативность” тут определяется не столько по флагу в DNS-ответе сервера, сколько совместно по иерархии делегирования и источнику ответа: то есть, хоть начальный список NS-ов и получается из вышестоящей зоны в делегирующем ответе, но достоверные имена NS – те имена, которые есть и в ответах самих этих серверов. Этот момент постоянно упускают из виду. (К сожалению, DNS часто настраивают как попало, поскольку бытует неверное мнение, что “это очень простая система: отправил имя – получил IP-адрес”.)

Почему перечни имён NS в зоне должны сходиться с делегирующими списками? Представьте, что атакующий каким-то образом перехватил управление и смог добавить собственный NS (по имени) в делегирующий ответ (это может быть сделано далеко не только на уровне регистратора доменов). При этом успешно подменён только делегирующий ответ, а сами авторитативные NS целевой зоны (не делегирующей), как узлы, не взломаны и работают штатно. Подменив делегирующий ответ, атакующий никак не повлиял на ответы авторитативных NS – если резолвер спросит эти NS, то получит список NS без добавления подменного узла. Да, резолвер, обрабатывающий список из делегирующего ответа, не может сразу предположить, какое имя было добавлено атакующим. Поэтому, если резолвер опрашивает все NS из списка, то он обязательно обратится и к подменному NS. Но, ещё раз, этот NS не может повлиять на саму подлинную зону и на ответы других NS – поэтому возникнет видимое расхождение. Заметьте, что если подменный NS возвращает тот же список NS, что и настоящие, то всё равно есть расхождение списка делегирования и списка NS в зоне. (Да, понятно, что обычный резолвер не обязательно выполняет все эти запросы и сравнивает результаты. Но в ситуации, когда требуется подтвердить какой-то параметр DNS-зоны, – например, при выполнении проверки права управления для выпуска TLS-сертификата, – непосредственный опрос многих NS и сравнение списков – необходимый шаг.)

Лишние NS в списке делегирования позволяют заподозрить, в худшем случае, активную атаку, а в лучшем – наличие больших проблем с DNS-зоной. Нередко, лишние NS появляются в результате опечаток или “забывчивости” администраторов, что свидетельствует об отсутствии необходимых проверок при изменении настроек сервиса.

Адрес записки: https://dxdt.ru/2025/02/08/15019/