BIND и DNSSEC: ZSK/KSK, DS record и разбор SERVFAIL

Что вы увидите при проблемах DNSSEC и почему это почти всегда «цепочка доверия»

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

В контексте DNSSEC SERVFAIL почти всегда означает одно: валидирующий резолвер не смог построить или проверить цепочку доверия от родительской зоны до вашей (или нашёл криптографическое несоответствие по дороге).

Важно различать два режима:

• Невалидирующий резолвер (или запрос без проверки) может продолжать получать ответы.
• Валидирующий резолвер при любой криптографической ошибке (неверный DS, подпись не сходится, отсутствует нужный DNSKEY, истекла подпись и т.д.) отдаёт SERVFAIL.

Поэтому принцип диагностики простой: всегда проверяйте ответы в режиме DNSSEC и отдельно смотрите «стык» родитель ↔ ваша зона (DS ↔ DNSKEY).

Минимальная теория: зачем два ключа (ZSK и KSK) и где участвует DS record

Зона DNSSEC подписывается ключами. В классической схеме используются два типа:

• ZSK (Zone Signing Key) — подписывает наборы записей в зоне (RRset).
• KSK (Key Signing Key) — подписывает набор DNSKEY (то есть «ключи зоны»).

Чтобы резолвер мог доверять вашей зоне, родительская зона (например, .ru или .com) публикует для домена DS record. DS — это отпечаток одного из DNSKEY (обычно KSK). Если DS не соответствует фактическому KSK, валидация рушится, и валидаторы возвращают SERVFAIL.

Привязка простая: DS живёт у родителя, а KSK/DNSKEY — в вашей зоне. DNSSEC чаще всего ломается, когда эти две стороны перестают совпадать.

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

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

Подробнее

Если авторитативный DNS крутится рядом с приложениями, удобнее держать всё на предсказуемой инфраструктуре: на VDS проще контролировать версии BIND, расписание переподписи, синхронизацию зон и логи диагностики.

Какие «грабли» чаще всего приводят к SERVFAIL в DNSSEC на BIND

Ниже причины, которые в реальности встречаются чаще всего. Начинайте проверку именно с них, потому что они дают «массовые» отказы у валидаторов.

1. Неверный DS record у регистратора/в родительской зоне: старый DS после смены KSK, DS посчитан не от того ключа, выбран digest, который не принимает родитель.
2. В зоне опубликован DNSKEY, но зона подписана другими ключами: переподписали «не тем» набором, перемешали каталоги ключей или подписанную зону.
3. Истекли RRSIG: зону не переподписывали вовремя, cron/systemd-таймер не отработал, время на сервере «уехало».
4. На авторитативных серверах разная версия зоны: на одном NS новая подписанная зона, на другом старая (или разные DNSKEY/RRSIG), валидатор натыкается на несогласованность.
5. Поломка NSEC/NSEC3 цепочек: чаще при ручных правках и частичной подписи, реже при корректной автоматизации.
6. Проблемы с переносом зоны: AXFR/IXFR без синхронизации ключей/подписей, secondary раздаёт не тот файл, или не получает обновления.

Если вы используете BIND в сложной схеме (views/split-horizon), отдельно проверьте, что DNSSEC-материал соответствует тому, что видят внешние клиенты. В таких конфигурациях легко «подписать одно, а раздать другое». По теме полезно держать под рукой заметку про split-horizon и views в BIND: как не перепутать внешнюю и внутреннюю зоны.

Проверка снаружи: диагностика через dig +dnssec (быстрый чек-лист)

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

1) Проверяем A/AAAA и наличие флага AD

Если спрашивать через валидирующий резолвер, в успешном случае вы увидите флаг ad (Authenticated Data):

dig +dnssec +multi example.com A

• status: NOERROR — базово не SERVFAIL.
• Флаги: наличие ad обычно означает, что валидация прошла.
• При +dnssec рядом с ответом будут RRSIG.

2) Смотрим DNSKEY напрямую на авторитативных серверах

Спросите DNSKEY у каждого NS отдельно (важно сравнить ответы):

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

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

• Оба NS должны отдавать одинаковый набор DNSKEY (по содержимому, не только по количеству).
• В ответе должен быть RRSIG для DNSKEY.
• Если TTL/набор ключей «пляшут» между NS — сначала лечите рассинхрон (transfer/деплой).

3) Сверяем DS (у родителя) и DNSKEY (в зоне)

DS хранится в родительской зоне. Проверка выглядит так:

dig +dnssec example.com DS

Если DS пустой, то DNSSEC в цепочке доверия «не включён» (и SERVFAIL из-за DNSSEC обычно не будет). Если DS есть — его нужно сравнить с DS, рассчитанным от вашего текущего KSK (ниже будет команда).

4) Если видите SERVFAIL — отделяем проблему зоны от проблемы делегирования

Удобная развилка для быстрой диагностики:

• Если при запросе напрямую к авторитативному NS ответы есть, записи на месте и видны RRSIG.
• Но при запросе через валидирующий резолвер приходит SERVFAIL.

Тогда чаще всего проблема либо в несоответствии DS ↔ KSK, либо в невалидных/истёкших подписях, либо в том, что разные NS отдают разный DNSSEC-материал.

Практика в BIND: ручная подпись зоны и где появляются файлы .signed

Есть два подхода к DNSSEC в BIND:

• Ручная (offline/manual) подпись: вы генерируете ключи и подписываете зону утилитой dnssec-signzone, а BIND раздаёт уже подписанный файл.
• Автоматическая DNSSEC (inline-signing/managed keys): BIND сам управляет ключами и переподписывает зону. Это удобно, но требует аккуратной настройки и понимания ротаций.

Дальше разберём ручной путь, потому что именно он чаще всего приводит к «человеческим» ошибкам (и потом к SERVFAIL).

Генерация ключей: KSK и ZSK

Пример шаблона: создаём KSK (с флагом -f KSK) и ZSK. Алгоритм и параметры выбирайте по своей политике.

cd /etc/bind/keys/example.com

dnssec-keygen -a ECDSAP256SHA256 -f KSK -n ZONE example.com

dnssec-keygen -a ECDSAP256SHA256 -n ZONE example.com

Появятся файлы вида Kexample.com.+013+12345.key и Kexample.com.+013+12345.private. Доступ к .private ограничьте максимально: утечка приватного ключа = компрометация зоны.

Подпись зоны через dnssec-signzone

Подписываем исходный файл зоны (например, db.example.com). Результат — файл db.example.com.signed:

cd /etc/bind/zones

dnssec-signzone -o example.com -N keep -t -k /etc/bind/keys/example.com/Kexample.com.+013+12345.key db.example.com /etc/bind/keys/example.com/Kexample.com.+013+67890.key

• -o — имя зоны.
• -k — KSK, которым подписывается RRset DNSKEY.
• Последним аргументом передаётся ZSK (в ротации их может быть несколько).
• -N keep помогает не сломать логику serial, но правило общее: serial должен расти.

Дальше BIND должен раздавать именно подписанный файл: в описании зоны указывайте db.example.com.signed, а не исходный db.example.com.

Проверяем подписанную зону локально до публикации

Перед перезапуском/перезагрузкой BIND прогоните проверку:

named-checkzone -i local example.com /etc/bind/zones/db.example.com.signed

Синтаксис и явные логические ошибки лучше поймать на этом шаге, чем на валидаторах в продакшене.

DS record: как получить его из KSK и не словить массовый SERVFAIL

DS нужно загрузить у регистратора/в панели управления доменом. Самая частая ошибка — посчитать DS не от того ключа или выбрать digest, который не поддерживается в родительской зоне.

Надёжный способ — сгенерировать DS из файла KSK через dnssec-dsfromkey:

cd /etc/bind/keys/example.com

dnssec-dsfromkey -2 Kexample.com.+013+12345.key

dnssec-dsfromkey -1 Kexample.com.+013+12345.key

Обычно используют SHA-256 (ключ -2), но конкретный набор зависит от требований реестра/регистратора. После публикации DS учитывайте задержки обновления и TTL: «мир» не переключится мгновенно.

Правило, которое спасает от простоя: сначала публикуем новый ключевой материал в своей зоне (DNSKEY/подписи), и только потом меняем DS у родителя. Обратный порядок почти гарантирует SERVFAIL у части резолверов.

KSK/ZSK rotation в BIND: безопасные сценарии без простоя

Задача ротации — не порвать цепочку доверия, пока у части резолверов в кэше старые данные. Поэтому почти все ротации делаются «внахлёст» (overlap).

Ротация ZSK (обычно проще)

Типовой безопасный сценарий — pre-publish:

1. Генерируете новый ZSK.
2. Публикуете новый ключ в DNSKEY (переподписываете зону так, чтобы DNSKEY RRset включал новый ZSK).
3. Ждёте TTL DNSKEY (лучше ориентироваться на максимальный TTL, который реально кэшируется).
4. Начинаете подписывать RRset новым ZSK (обычно — переподписью зоны).
5. После периода перекрытия удаляете старый ZSK из DNSKEY и переподписываете.

В ручном режиме это часто означает, что некоторое время вы подписываете зону двумя ZSK (старым и новым), а затем оставляете один.

Ротация KSK (самая опасная из-за DS)

KSK rotation затрагивает DS у родителя, поэтому делайте её максимально осторожно:

1. Генерируете новый KSK.
2. Публикуете новый KSK в DNSKEY зоны, DS у родителя пока не трогаете.
3. Переподписываете зону так, чтобы DNSKEY RRset был подписан и старым, и новым KSK (зависит от выбранного процесса подписи).
4. Ждёте TTL DNSKEY.
5. Обновляете DS у родителя на DS от нового KSK.
6. Ждёте распространения DS (TTL + задержка у регистратора/реестра).
7. Удаляете старый KSK из зоны и переподписываете.

Если поменять DS слишком рано, валидаторы начнут требовать «новый KSK», а он ещё может не быть доступен на всех ваших NS или в кэше. Итог — SERVFAIL.

Если хотите глубже разобрать логику overlap-сценариев и типовые тайминги (TTL, hold-down), держите отдельный материал: планирование rollover KSK/ZSK без обрывов.

Разбор типового инцидента: «всё подписано, но валидаторы дают SERVFAIL»

Классика: админ переподписал зону, на авторитативных NS видны DNSKEY и RRSIG, но часть пользователей жалуется. В мониторинге — SERVFAIL на валидирующих резолверах.

Шаг 1: убеждаемся, что все авторитативные NS отдают одно и то же

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

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

Сравните serial SOA и наличие DNSSEC-материала. Разный serial или «провалы» по RRSIG/DNSKEY на одном из NS почти всегда означают рассинхрон (ошибка transfer, выкладка не того файла, разные каталоги ключей).

Шаг 2: сравниваем DS «снаружи» и DS от текущего KSK

Сначала смотрим DS, который видит мир:

dig +dnssec example.com DS

Затем на своей стороне генерируем DS от текущего KSK (который реально опубликован в DNSKEY вашей зоны):

dnssec-dsfromkey -2 /etc/bind/keys/example.com/Kexample.com.+013+12345.key

Если DS не совпадает по key tag/алгоритму/digest — это и есть причина SERVFAIL. Самый частый вариант: у регистратора остался DS от старого KSK, а старый ключ вы уже убрали из зоны.

Шаг 3: проверяем сроки подписей (RRSIG) и время на сервере

Когда DS совпадает, следующий кандидат — истёкшие подписи (или некорректное время на машине, которая подписывает). Посмотрите поля inception/expiration в RRSIG:

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

Если expiration в прошлом, валидатор корректно выдаёт SERVFAIL. Лечится переподписью зоны и нормализацией времени (NTP/chrony) на сервере подписи.

Эксплуатационные советы: как не ловить SERVFAIL после внедрения DNSSEC

1) Держите расписание переподписи и запас по времени

При ручной подписи переподписывайте заранее, а не «в последний день». Закладывайте окно на сбой деплоя или ошибку в ключах, чтобы не упереться в истечение RRSIG.

2) Синхронизируйте ключи и подписанную зону между всеми NS

Определитесь, где именно происходит подпись. В ручной схеме чаще всего подписывает primary, а secondary получают уже подписанную зону. Если разные NS раздают разные версии подписей, проблема будет «плавающей» и очень неприятной для диагностики.

3) Перед сменой DS заранее уменьшайте TTL (где это возможно)

Перед KSK rotation полезно заранее снизить TTL у DNSKEY (в своей зоне), чтобы период ожидания при переключениях был управляемым. После завершения работ TTL можно вернуть к нормальным значениям.

4) Мониторьте именно DNSSEC-валидацию

Обычная проверка dig A может быть «зелёной» на невалидирующем резолвере, пока пользователи на валидаторах уже в простое. В мониторинг добавьте проверки dig +dnssec, контроль флага ad и статуса ответа.

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

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

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

Если доменов много и вы регулярно трогаете DS, удобнее держать управление в одном месте: в Fastfox есть регистрация доменов и операции по домену из панели, чтобы быстро сверить или обновить DS при ротации KSK.

Короткий чек-лист: что делать прямо сейчас, если DNSSEC уже даёт SERVFAIL

1. Снимите DS у родителя и сравните с DS от текущего KSK (dnssec-dsfromkey).
2. Проверьте, что все NS отдают одинаковые DNSKEY/подписанную зону (SOA serial, наличие RRSIG).
3. Проверьте сроки RRSIG и переподпишите зону, если подписи истекли.
4. Если недавно делали KSK rotation — убедитесь, что старый KSK ещё присутствует в зоне на этапе перекрытия (или временно верните его, если DS ещё не обновлён или не распространился).
5. После исправлений дайте время TTL, и только затем оценивайте результат на внешних валидирующих резолверах.

Итоги

DNSSEC в BIND — это не столько «подписать зону», сколько выстроить процесс вокруг ключей и делегирования: DS у родителя должен соответствовать вашему KSK, подписи должны быть актуальными, а все NS должны раздавать одну и ту же подписанную версию зоны. Почти любой SERVFAIL при включённом DNSSEC сводится к одному из трёх: несоответствие DS ↔ KSK, истёкшие/битые подписи, рассинхрон между NS. Если у вас есть понятный регламент подписи/ротации и мониторинг через dig +dnssec, DNSSEC работает предсказуемо и без сюрпризов.