DNS

Проверка DNSSEC

Проверьте цепочку доверия DNSSEC — проверка DNSKEY, DS-записи и RRSIG.

О инструменте «Проверка DNSSEC»

Проходит по цепочке доверия DNSSEC от корня через каждую делегацию, проверяя совпадение записей DS и DNSKEY на каждом уровне, а также действительность и срок подписей. Ошибки DNSSEC особенно сложно диагностировать вручную: разрыв в любом звене цепочки приводит к тому, что валидирующие резолверы молча отказываются разрешать домен вообще, без явного сообщения об ошибке. Стоит проверять после смены ключей DNSSEC, смены регистратора или когда домен внезапно перестаёт резолвиться у одних пользователей, но не у других.

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

📖 Подробнее в базе знаний →

Цепочка DNSSEC

DNSKEY -- Public key published at the zone apex
DS -- Delegation Signer at the parent zone
RRSIG -- Signature over DNS records
AD flag -- Resolver confirms chain is valid

Похожие инструменты

Secure, insecure, bogus: что означает результат

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

  • Secure — цепочка от корня до ваших записей проверяется. Резолвер выставляет флаг AD (Authenticated Data).
  • Insecure — домен не подписан или в родительской зоне нет для него DS-записи. Домен резолвится как обычно, просто без защиты DNSSEC. Это не ошибка.
  • Bogus — домен заявлен как подписанный, но где-то в цепочке проверка не проходит. Валидирующие резолверы возвращают SERVFAIL, и домен пропадает для их пользователей, а невалидирующие продолжают отвечать. Поэтому сбой DNSSEC выглядит как «у меня работает, а у них нет».

Самые частые сбои

  • DS-запись не совпадает ни с одним DNSKEY. Классическая причина — переезд к новому DNS-провайдеру или смена ключа KSK без обновления DS-записи у регистратора. Родительская зона указывает на старый ключ, и цепочка рвётся на делегировании.
  • Истёкшие подписи. У RRSIG-записей есть срок действия. Если подписание остановилось — упала cron-задача, остановлен подписывающий сервис, сервер перенесён, — через дни или недели подписи истекают, и зона становится bogus без каких-либо изменений в конфигурации.
  • Расхождение между NS-серверами. Один авторитативный сервер отдаёт подписанные данные, другой — неподписанную или устаревшую копию. Результат зависит от того, к какому серверу обратился резолвер.
  • Устаревшие алгоритмы. Зоны, подписанные RSA/SHA-1 (алгоритмы 5 и 7), стоит переподписать. Распространённый современный выбор — ECDSA P-256 (алгоритм 13): короткие ключи и компактные ответы.

Как подтвердить проблему DNSSEC с помощью dig

Если домен возвращает SERVFAIL, повторите запрос с отключённой проверкой:

dig example.com A            # SERVFAIL через валидирующий резолвер
dig example.com A +cd        # +cd = проверка отключена

Если запрос с +cd возвращает нормальный ответ, сами записи в порядке, а сбоит именно проверка DNSSEC. Чтобы увидеть обе стороны делегирования, сравните DS-запись в родительской зоне с ключами в самой зоне:

dig example.com DS +short
dig example.com DNSKEY +multiline

Key tag в DS-записи должен совпадать с key tag ключа DNSKEY с флагами 257 (ключ KSK).

Как безопасно отключить DNSSEC

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

DNSSEC входит в полную проверку здоровья домена NODA, которая также охватывает делегирование NS и почтовую аутентификацию. Для просмотра отдельных записей используйте инструмент DNS-запросов.