DNSSEC: DS-запись, key rollover и почему домен уходит в SERVFAIL

DNSSEC обычно вспоминают в два момента: когда его «для галочки» включили в панели и забыли — и когда внезапно часть интернета начала видеть ваш домен как SERVFAIL. Во втором случае проблема почти всегда не в веб‑сервере и не в CDN, а в DNSSEC‑валидации на рекурсивных резолверах: цепочка доверия от родительской зоны до вашей зоны «рвётся».

Ниже — практический разбор типовых причин SERVFAIL из‑за DNSSEC, роль DS в родительской зоне, быстрые проверки через dig и безопасный key rollover (ZSK/KSK) без простоя.

Что означает SERVFAIL при DNSSEC и почему это не «ошибка сайта»

SERVFAIL — это ответ рекурсивного резолвера (провайдер, корпоративный DNS, публичный резолвер), означающий: «я не смог получить корректный ответ». При проблемах DNSSEC это часто означает другое: «ответ пришёл, но не прошёл DNSSEC‑валидацию, поэтому я не имею права отдавать его клиенту».

Ключевой момент: многие валидирующие резолверы при провале проверки не «отдают как есть», а намеренно ломают резолвинг. Для пользователя это выглядит как падение сайта, хотя на авторитативных NS всё может быть «нормально».

Если авторитативный сервер отвечает, а клиенты через рекурсивные резолверы получают SERVFAIL — это почти всегда симптом сломанной цепочки DNSSEC.

Минимальная теория: DNSKEY, RRSIG, DS и цепочка доверия

DNSSEC добавляет к DNS‑данным подписи. Упрощённо:

• в вашей зоне публикуются ключи DNSKEY;
• каждый набор записей (RRset) подписан RRSIG;
• в родительской зоне (например, TLD) хранится DS — «отпечаток» вашего ключа, которым родитель «закрепляет» доверие к вашей зоне;
• рекурсивный резолвер строит цепочку доверия: корень → TLD → ваш домен и проверяет подписи.

Самая частая причина SERVFAIL при DNSSEC — несоответствие DS в родительской зоне и актуального DNSKEY в вашей зоне. То есть «родитель доверяет одному ключу», а вы уже публикуете другой (или публикуете, но не тот; или подписи делаются не тем ключом).

Типовые сценарии, когда появляется SERVFAIL

1) DS остался старый после смены DNS-хостинга или пересоздания зоны

Вы перенесли зону на другой сервис, там заново включили DNSSEC и получили новый набор ключей — но DS у регистратора/в реестре остался от старых ключей. Валидатор видит: DS указывает на один ключ, а DNSKEY в зоне другой — проверка падает, и домен уходит в SERVFAIL.

Если вы как раз меняете NS и делегацию, держите под рукой пошаговый план: как сделать делегацию домена и проверить NS без сюрпризов.

2) Неправильный key rollover (KSK/ZSK) или игнорирование задержек TTL

Key rollover — плановая ротация ключей. Типичная ошибка — удалить старый ключ или старые подписи слишком рано. Даже при корректных действиях есть задержки распространения:

• TTL у записей (кэши резолверов);
• задержки обновления DS в родительской зоне (регистратор/реестр);
• время, пока резолверы увидят новый DNSKEY и перестроят доверие.

Если вы поменяли ключи и сразу убрали старые, часть клиентов будет валидировать по старой информации из кэша и получать SERVFAIL.

3) Разные ключи/подписи на разных NS (несогласованная зона)

Если часть авторитативных серверов отдаёт одну версию зоны (одни DNSKEY/RRSIG), а часть — другую, то в зависимости от того, на какой NS попадёт резолвер, результат будет «то работает, то нет».

Частые причины: сломанная синхронизация, частичный деплой, некорректная репликация secondary DNS, разные версии ПО и разные политики подписания.

4) Подписи просрочены или зона не переподписывается

RRSIG имеет срок действия. Если автоматическое переподписание остановилось (ошибка в планировщике, закончилась доступность HSM, поломалась интеграция в панели), подписи истекают — и домен уходит в SERVFAIL на валидирующих резолверах.

5) Ошибки алгоритма/дайджеста DS или «не тот DS»

DS включает алгоритм и тип дайджеста. Ошибка в одном числе (алгоритм/тип/хэш) или публикация DS не от того ключа приводит к провалу проверки.

Если вы планируете включать DNSSEC для продакшн-домена, заранее проверьте у регистратора, где именно управляется DS и как быстро изменения попадают в реестр. Удобно, когда домен и DNS-настройки под рукой: регистрация доменов.

Быстрая диагностика: где именно рвётся цепочка

Диагностируйте с двух сторон:

• что публикует родитель (есть ли DS и какой он);
• что публикует ваша зона (какие DNSKEY, есть ли подписи и совпадает ли логика).

Проверяем, есть ли DS у домена (родительская зона)

dig +short DS example.com

Если ответа нет — DNSSEC на уровне реестра не включён (или вы спрашиваете не тот домен/не тот TLD). Если DS есть — фиксируем значения (как минимум keytag, алгоритм, digest type и digest).

Проверяем DNSKEY (ваша зона)

dig +short DNSKEY example.com

В выводе будут ключи. Практически полезные маркеры:

• флаг 256 обычно означает ZSK;
• флаг 257 обычно означает KSK;
• алгоритм (число после флагов) должен быть согласован с тем, что ждёт DS.

Проверяем, проходит ли валидация на рекурсивном резолвере

Попросите резолвер вернуть DNSSEC‑данные:

dig example.com A +dnssec

Смотрите на:

• наличие RRSIG рядом с ответом;
• флаг ad (authenticated data) в секции flags: если резолвер валидирует и доверяет цепочке, он может выставить ad;
• если вместо ответа вы видите SERVFAIL — validation завалился или резолвер не смог собрать цепочку.

Чтобы отделить «валидация упала» от «авторитативка реально не отвечает», полезно сравнить запрос через рекурсивный резолвер и запрос напрямую к авторитативному NS:

dig example.com A

dig @ns1.example.net example.com A +dnssec

Сравниваем ответы разных NS (поиск рассинхронизации)

Убедитесь, что все авторитативные NS отдают одинаковые DNSSEC‑данные:

dig @ns1.example.net example.com DNSKEY +dnssec

dig @ns2.example.net example.com DNSKEY +dnssec

Если наборы DNSKEY или подписи RRSIG отличаются — сначала лечите консистентность зоны, иначе любые действия с DS могут дать «плавающую» проблему.

Самый частый кейс: DS не соответствует DNSKEY (как восстановить доступность)

Если домен уже в SERVFAIL, цель №1 — вернуть резолвинг. Есть два рабочих пути; выбор зависит от того, готовы ли вы временно жить без DNSSEC.

Вариант A (самый быстрый): временно снять DS в родительской зоне

Удаление DS у регистратора отключает DNSSEC на уровне цепочки доверия. Тогда резолверы перестают валидировать ваш домен (потому что «родитель не заявляет, что домен подписан»), и ответы снова начинают проходить без SERVFAIL.

Это аварийная мера: плюс — скорость восстановления; минус — на время вы теряете защитные свойства DNSSEC. После снятия DS подождите распространения изменений (реестр, TTL, кэши), и параллельно приводите зону в порядок.

Вариант B: корректно обновить DS под текущий KSK

Если зона сейчас подписана корректно и вы хотите оставить DNSSEC включённым — опубликуйте в родительской зоне DS, соответствующий вашему текущему KSK.

Критично, чтобы DS был рассчитан от KSK (обычно ключ с флагом 257), с правильным алгоритмом и digest type. На практике надёжная схема — сверить, что значение DS в панели регистратора совпадает с тем, что ваш DNS‑хостинг показывает как «DS for parent».

Key rollover без боли: рабочая схема и точки ожидания

Key rollover бывает двух типов: ротация ZSK и ротация KSK. ZSK обычно проще (не требует изменения DS у родителя). KSK сложнее: меняется ключ, от которого строится DS, значит нужно синхронизировать вашу зону и родительскую максимально аккуратно.

Ротация ZSK (типовой безопасный подход)

1. Добавить новый ZSK в зону (не удаляя старый).
2. Начать подписывать RRset новым ZSK (часто это делает автоматизация).
3. Выждать минимум TTL (а лучше TTL + запас), чтобы кэши обновились и резолверы увидели новые подписи.
4. Удалить старый ZSK.

Типовая ошибка — удалить старый ZSK раньше, чем перекэшируются подписи.

Ротация KSK (где чаще всего ловят SERVFAIL)

Практичный подход — держать «двойной KSK» на время перехода:

1. Опубликовать новый KSK в зоне вместе со старым (оба видны в DNSKEY).
2. Убедиться, что зона подписывается корректно и валидатор может построить доверие (зависит от реализации, но идея в том, чтобы не лишить валидаторов нужных ключей до переключения родителя).
3. Обновить DS у родителя на новый KSK (через регистратора).
4. Выждать время распространения и минимум TTL, пока резолверы перестроят цепочку доверия.
5. Только после этого удалить старый KSK и связанные подписи.

С KSK rollover правило простое: сначала добавить и дождаться, потом переключить DS, снова дождаться, и только затем удалять старое.

Если у вас собственные авторитативные DNS и вы хотите держать всё под контролем (версии зон, репликацию, автоматическое переподписание), часто удобнее выносить DNS на отдельную инфраструктуру. Под это хорошо подходит VDS: можно развернуть PowerDNS/Bind/NSD и настроить мониторинг DNSSEC-валидности.

Регистрация доменов от 99 руб.

Каждый проект заслуживает идеального доменного имени, выберите один из сотни, чтобы начать работу!

Зарегистрировать домен

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Чеклист: что проверить, чтобы DNSSEC validation не падала снова

• Автопереподписание: убедитесь, что сервис обновляет подписи до истечения RRSIG.
• Единая зона на всех NS: контролируйте синхронизацию, особенно при secondary DNS.
• Контроль DS: фиксируйте, кто и когда меняет DS, и от какого KSK он рассчитан.
• План работ: заранее учитывайте TTL и задержки обновления у реестра/регистратора.
• Тесты после изменений: проверяйте не только «открывается ли сайт», но и валидирующий резолвинг.

Когда лучше сначала отключить DNSSEC, а потом включить заново

Иногда быстрее и безопаснее восстановиться «в два шага»: сначала убрать DS (вернуть доступность), затем спокойно пересобрать DNSSEC и снова добавить корректный DS. Это оправдано, если:

• вы не уверены, какие ключи сейчас активны и где они генерировались;
• есть подозрение на рассинхронизацию между NS;
• DNSSEC‑автоматизация на вашей стороне работает нестабильно;
• нужно срочно снять простой, а разбор причин займёт время.

Важно: «выключить DNSSEC» технически означает удалить DS у родителя. Удаление DNSKEY/RRSIG в зоне без снятия DS обычно только ухудшит ситуацию: цепочка доверия останется, а проверять будет нечего.

Если вы параллельно решаете вопросы домена (перенос, продление, смена регистратора), держите отдельно чеклист, чтобы не потерять контроль над DS и NS: как сделать трансфер домена и что проверить в DNS (EPP-код, NS, DS).

Итоги

Проблема «DNSSEC → SERVFAIL» почти всегда сводится к разрыву цепочки доверия, чаще всего из‑за несоответствия DS в родительской зоне и ваших DNSKEY (особенно после миграций и при неаккуратном key rollover). Диагностируйте через dig с проверкой DS, DNSKEY и одинаковости ответов разных NS, затем выбирайте стратегию: аварийно снять DS или аккуратно обновить DS под текущий KSK. Для плановых работ придерживайтесь схемы «сначала добавить и выждать, потом переключить и снова выждать, и только затем удалять старое».