NIST впервые за десятилетие обновляет рекомендации по безопасности DNS

Инфраструктура DNS лежит в основе почти каждого сетевого подключения организации, однако рекомендации по её конфигурации безопасности на федеральном уровне не пересматривались более двенадцати лет. NIST опубликовал документ SP 800-81r3, "Руководство по безопасному развертыванию системы доменных имён", который заменил версию, датируемую 2013 годом.

Документ охватывает три основные области: использование DNS в качестве активного средства контроля безопасности, защита самого протокола DNS, а также обеспечение безопасности серверов и инфраструктуры, на которых работают DNS-службы. Он адресован двум группам: руководителям и лицам, принимающим решения в области кибербезопасности, а также операционным командам, отвечающим за сеть и безопасность, которые настраивают и обслуживают DNS-среды.

DNS как точка принудительного применения политик безопасности

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

В документе описаны две общие модели развёртывания: облачные службы защитного DNS и локальные развёртывания с использованием DNS-брандмауэров или зон политик ответа. Там, где это возможно, рекомендуется гибридный подход, сочетающий оба варианта, на том основании, что при сбое в облаке локальное резервирование всё равно сохраняет защиту.

Крикет Лю, исполнительный вице-президент по инженерии, главный архитектор DNS и старший научный сотрудник Infoblox, соавтора публикации, предоставил дополнительные детали о практике развёртывания зон политик ответа. "При развёртывании зон политик ответа, одного из наиболее распространённых механизмов защитного DNS, мы советуем организациям создавать локальную зону для переопределения зон, которые они могут получать от других организаций", — сказал он. "Организации обычно используют локальную зону для добавления в белый список своего внутреннего пространства имён, а затем могут добавлять в белый список отдельные доменные имена, которые могут быть ошибочно заблокированы".

В руководстве рекомендуется интегрировать журналы защитного DNS с платформами SIEM или анализа логов, а также коррелировать данные DNS-запросов с историями аренды DHCP для сопоставления IP-адресов с конкретными активами во время реагирования на инциденты.

Шифрованный DNS меняет роль DNS-сервера

Публикация уделяет значительное внимание зашифрованному DNS, рассматривая три протокола: DNS через TLS (DoT), работающий на TCP-порту 853; DNS через HTTPS (DoH), использующий TCP и UDP порт 443; и DNS через QUIC (DoQ), функционирующий на UDP-порту 853. Все три протокола шифруют обмен данными между клиентскими и рекурсивными DNS-серверами и, опционально, поддерживают аутентификацию сервера.

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

Лю указал на структурное следствие внедрения зашифрованного DNS, которое подчеркивается в руководстве. «Сам DNS-сервер становится критически важным при развертывании зашифрованного DNS, — сказал он. — DNS-сервер превращается в точку обнаружения и контроля. Кроме того, организации могут получать и хранить данные Passive DNS, собранные с их DNS-серверов, что позволяет им выявлять угрозы, вести журналы ответов и многое другое».

Публикация рекомендует организациям блокировать несанкционированный трафик DoT с помощью правил межсетевого экрана на TCP-порту 853, а также использовать RPZ в сочетании с правилами брандмауэра для ограничения несанкционированного трафика DoH, который сложнее заблокировать из-за использования порта 443. Для принудительного применения утвержденных DNS-конфигураций на конечных устройствах предлагается использовать инструменты управления мобильными устройствами.

Рекомендации по DNSSEC обновлены в соответствии с современными алгоритмами

Публикация обновляет рекомендации по подписанию DNSSEC, отражая текущие криптографические стандарты. В ней представлена таблица поддерживаемых алгоритмов, взятых из RFC 8624 и NIST SP 800-57, включая RSA с SHA-256, ECDSA P-256 и P-384, а также алгоритмы на кривых Эдвардса Ed25519 и Ed448. В документе отмечается предпочтение алгоритмам ECDSA и Edwards-curve перед RSA, поскольку меньшие размеры ключей и подписей помогают сохранять размер DNS-ответов в пределах, не требующих использования TCP.

Ключи подписи DNSSEC классифицируются как ключи подписи с рекомендуемым максимальным сроком службы от одного до трёх лет. В документе рекомендуется устанавливать короткие периоды действительности RRSIG, порядка пяти-семи дней, чтобы ограничить временное окно, в течение которого скомпрометированный ключ может быть использован для подделки ответов. Рекомендуется использовать аппаратные модули безопасности для хранения приватных ключей, особенно ключей подписи зон, где это практически осуществимо.

В руководстве рекомендуется отдавать предпочтение NSEC перед NSEC3 для аутентифицированного отрицания существования записей, отмечая, что вычислительные накладные расходы NSEC3, как правило, не оправданы той защитой от обхода зоны, которую он обеспечивает. Организациям, которым политика предписывает использовать NSEC3, рекомендуется обратиться к RFC 9276 для настройки параметров, снижающих риск атак типа «отказ в обслуживании».

Постквантовые криптографические алгоритмы пока не специфицированы для использования в DNSSEC. В документе отмечается, что администраторам следует планировать переход, как только станут доступны соответствующие спецификации и инструменты.

Гигиена авторитативных серверов и управление зонами

В руководстве описаны несколько категорий угроз, специфичных для авторитативных DNS-сервисов. Висячие записи CNAME, указывающие на домен, который больше не зарегистрирован или не контролируется организацией, могут позволить злоумышленникам перехватить разрешение этого имени. Некорректные делегирования, когда поддомен делегирован на серверы имён, которые больше не являются для него авторитативными, создают аналогичную уязвимость и могут привести к захвату домена через хостинг-провайдера.
В документе рекомендуется активный мониторинг регистраций доменов для выявления похожих или опечаточных доменных имён. Также рекомендуется поддерживать делегирования выведенных из эксплуатации доменов в «припаркованном» состоянии в течение некоторого времени, чтобы предотвратить их перерегистрацию злоумышленниками.

Для большинства DNS-данных рекомендуются значения TTL в диапазоне от 1800 секунд (30 минут) до 86400 секунд (один день). Значение TTL, равное нулю, явно запрещено, а значения ниже 30 секунд не рекомендуются для записей, подписанных DNSSEC.

Что руководство NIST по безопасности DNS охватывает в части архитектуры инфраструктуры и доступности

В публикации повторяется рекомендация из более ранних версий о разделении авторитативных и рекурсивных функций на серверах, доступных из интернета. DNS-сервер, доступный из интернета и сконфигурированный для выполнения обеих функций, описывается как угроза безопасности.

NIST рекомендует развертывать как минимум два авторитетных сервера имён на различных сетевых сегментах, географически распределив их по разным физическим площадкам. Для снижения риска прямой атаки рекомендуется использовать скрытый первичный авторитетный сервер, который не указывается в наборе NS-записей зоны.

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

Вебинар: Реальное состояние безопасности 2026