DNSSEC на практике: KSK/ZSK, DS record и безопасный rollover без SERVFAIL

DNSSEC часто включают «для галочки», а вспоминают о нём в самый неприятный момент — когда часть пользователей внезапно получает SERVFAIL, мониторинг ругается на rrsig expired, а у регистратора в панели непонятные «ключи» и DS. Ниже — практичная схема: что именно подписывается, зачем нужны KSK/ZSK, что такое DS record и как делать dnssec rollover (key rotation) без простоя.

Что даёт DNSSEC и почему он ломает резолв при ошибках

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

Операционная особенность DNSSEC: это не «ускоритель» и не «шифрование», а строгая валидация. Если цепочка доверия не сходится, валидирующий резолвер предпочитает вернуть ошибку. Для пользователя это «сайт не открывается», для администратора — типичный запрос в поиске servfail dnssec.

DNSSEC повышает безопасность ценой того, что ошибки конфигурации становятся видны мгновенно: вместо «как-нибудь работает» валидирующие клиенты получают отказ.

Три компонента, которые надо держать в голове

• Ваша зона (authoritative DNS) публикует записи и DNSSEC-данные: DNSKEY, RRSIG (и NSEC/NSEC3).
• Родительская зона (обычно зона TLD) публикует DS — «якорь» для доверия к вашей зоне.
• Валидирующий резолвер проверяет подписи и цепочку доверия от корня до вашей зоны.

Термины DNSSEC простыми словами: DNSKEY, RRSIG, DS

В DNSSEC к обычным ресурсным записям добавляются специальные типы:

• DNSKEY — открытые ключи зоны, которыми резолвер проверяет подписи.
• RRSIG — подпись для набора записей (RRset). Например, RRset для www типа A идёт вместе с подписью RRSIG.
• DS record — запись в родительской зоне, которая «связывает» родителя с вашими ключами. По сути это хэш от ключа (чаще всего от KSK или ключа, выполняющего роль KSK).

Цепочка доверия выглядит так: корень доверяет ключам TLD, TLD доверяет вашей зоне через DS, а ваша зона подписывает критичные RRset. Если в цепочке что-то не сходится — валидация падает, и валидирующие клиенты получают SERVFAIL.

KSK и ZSK: зачем два ключа и кто что подписывает

В классической модели используются два ключа:

• ZSK (Zone Signing Key) — подписывает данные зоны (RRset) и создаёт большинство RRSIG.
• KSK (Key Signing Key) — подписывает набор DNSKEY (то есть «подписывает ключи»). Именно на KSK обычно указывает DS record у родителя.

Практический смысл разделения простой: ZSK можно ротировать чаще (операционная гигиена, политика, инцидент), а KSK — реже, потому что его смена почти всегда требует обновления DS у регистратора. Это и есть самая рискованная точка.

Алгоритмы и размеры ключей: что важнее для эксплуатации

В продакшене чаще всего встречаются RSA и ECDSA. Выбирайте то, что поддерживают ваш authoritative DNS/хостинг и родительская зона, и что предсказуемо валидируется массовыми резолверами. С точки зрения эксплуатации важнее не «идеальный алгоритм», а корректный rollover, адекватные TTL и контроль сроков действия подписей (RRSIG).

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

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

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

Как включить DNSSEC и не попасть в ловушку DS

Практически «включить DNSSEC» означает два параллельных действия:

• ваша зона начинает публиковать DNSKEY и RRSIG;
• в родительской зоне появляется DS record, указывающий на ваш ключ.

Самая частая авария — сделать только половину:

• Зона подписана, но DS у родителя не добавлен: резолв обычно не ломается, но DNSSEC «не работает» (нет цепочки доверия).
• DS у родителя добавлен, но зона ещё не подписана или уже переподписана другими ключами: валидирующие клиенты часто получают SERVFAIL.

Самый опасный сценарий: DS у родителя указывает на ключ, которого нет в вашей зоне или который не подписывает RRset DNSKEY. Для валидаторов это выглядит как подмена.

Мини-чеклист перед публикацией DS

1. Убедитесь, что authoritative DNS отдаёт DNSKEY и RRSIG для зоны.
2. Сверьте, что DS строится именно от ключа, который выполняет роль KSK.
3. Проверьте TTL у DNSKEY и заложите время на кеши перед изменениями.

Почему возникает SERVFAIL при DNSSEC: типовые причины

Под запросом servfail dnssec чаще всего скрывается один из сценариев ниже.

1) Неверный или «старый» DS record

DS у родителя не соответствует текущему KSK (или текущему DNSKEY, на который он должен ссылаться). Частая причина — смена DNS-провайдера, ручная генерация ключей, несинхронный rollover или «забыли обновить DS у регистратора».

2) Подписи истекли: rrsig expired

RRSIG имеет срок действия. Если подписи истекли, валидирующий резолвер не примет ответ. Типовые первопричины:

• сломался автоматический re-sign на DNS-сервере;
• неправильное время на сервере (NTP не работает, часы уехали);
• слишком короткая «validity» и редкое переподписание;
• перенос зоны/файлов подписи без корректной процедуры.

3) Ошибки с NSEC/NSEC3 (отрицательные ответы)

DNSSEC должен доказывать не только «запись есть», но и «записи нет». Это делается через NSEC или NSEC3. При проблемах в этом месте часто ломаются NXDOMAIN-ответы и часть запросов превращается в SERVFAIL только у валидирующих резолверов.

4) Алгоритмы/параметры не поддерживаются на пути

Реже, но бывает: выбранный алгоритм или параметры не поддерживаются родительской зоной (для DS) или частью резолверов. Формально цепочка может существовать, но валидаторы не смогут её построить.

DNSSEC rollover: что вращаем и почему ZSK проще, чем KSK

Key rotation DNSSEC бывает двух типов:

• ZSK-rollover — обычно полностью внутри вашей зоны/провайдера DNS, не требует менять DS. Самый безопасный и частый.
• KSK-rollover — почти всегда упирается в обновление DS у родителя (через регистратора). Самый рискованный.

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

Практическая схема ZSK rollover: pre-publish

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

Если ваша реализация поддерживает double-sign (двойные подписи RRset), переход может быть ещё мягче, но учитывайте размер ответов и риск фрагментации UDP.

Практическая схема KSK rollover: «двойной DS» как страховка

Безопасная стратегия для KSK-rollover: сделать так, чтобы родитель доверял хотя бы одному валидному ключу, который реально присутствует в вашей зоне.

Если регистратор и родительская зона позволяют публиковать несколько DS record для одного домена (часто позволяют) — это лучший вариант.

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

Двойной DS — это «страховочная сетка»: даже если часть клиентов ещё видит старую картину, у них остаётся рабочая цепочка доверия.

Если двойной DS невозможен

Тогда процесс становится гораздо более «временнó-чувствительным». В таком варианте особенно важно заранее уменьшить TTL (если вы контролируете это), запланировать окно работ и строго выдерживать интервалы между шагами. Если у вас домены в большом количестве, полезно заранее наладить процесс у регистратора (и в идеале автоматизировать операции), чтобы не делать KSK-rollover «вручную на нервах».

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

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

Подробнее

Диагностика: что проверять, когда «DNSSEC сломался»

Цель диагностики — понять, где именно рвётся цепочка: внутри вашей зоны (ключи/подписи) или на уровне родителя (DS).

Команды dig: снять факты

Ниже — базовый набор запросов (выполняйте с машины, где есть dig, обычно пакет bind-utils или dnsutils):

dig +dnssec example.com SOA

dig +dnssec example.com DNSKEY

dig +dnssec example.com DS

dig +trace +dnssec example.com A

Как читать результаты на практике

• Нет DNSKEY/RRSIG в ответах authoritative — зона, вероятно, не подписана или сервер не отдаёт DNSSEC-данные.
• В +trace виден DS у родителя, но он не соответствует текущему ключу в DNSKEY — высокий риск SERVFAIL у валидаторов.
• Ключи и DS «вроде на месте», но валидаторы ругаются на сроки — проверяйте истечение подписей (rrsig expired), re-sign и корректность времени.

Быстрые гипотезы по симптомам

• Проблема только у части клиентов — часто DNSSEC-валидация плюс эффект кешей при неудачном rollover.
• Началось после смены DNS-хостинга — первым делом сверяйте, что DS соответствует новому KSK, а не остался от старого провайдера.
• Началось «само» в одно время — типичный признак истечения подписей (rrsig expired) из-за остановки re-sign или проблем с временем.

Планирование ротации: TTL, окна изменений и мониторинг

TTL как инструмент управления риском

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

Мониторинг RRSIG и валидации

Чтобы не увидеть rrsig expired внезапно, полезно мониторить:

• валидацию DNSSEC для ключевых имён (apex, www, mail);
• запас по сроку действия подписей RRSIG;
• изменения DS record у родителя (если у вас есть наблюдаемость в этой точке).

Зафиксируйте, кто отвечает за DS у регистратора

Частая организационная поломка DNSSEC — зона уже на новых ключах, а DS у регистратора меняет другой человек (или подрядчик), который «не хотел трогать лишнее». Если у вас доменов много, удобно держать домены и DNS-операции в одном процессе. По теме жизненного цикла домена (включая продление и риски «пропустить срок») полезно прочитать материал про grace/redemption периоды при продлении домена.

Авария: что делать при SERVFAIL из-за DNSSEC

Если домен уже в аварии и валидаторы возвращают SERVFAIL, действуйте прагматично и по шагам:

1. Восстановите связность: приведите DS record у родителя в соответствие текущему KSK или временно удалите DS (если это допустимо по вашей политике).
2. Проверьте подписи: убедитесь, что re-sign работает и нет истёкших RRSIG.
3. Учитывайте кеши: «починка» может разъезжаться не мгновенно — зависит от TTL и поведения резолверов.

В аварии лучше вернуться к простому предсказуемому состоянию, чем пытаться «дожать» сложный rollover без ясной картины цепочки доверия.

Короткое резюме

DNSSEC — рабочий механизм защиты DNS, но он требует аккуратного обращения с ключами и DS record. Планируйте ротации через период совместного существования ключей, следите за сроками RRSIG, документируйте владельца процесса «кто меняет DS», и всегда проверяйте соответствие DS родителя вашему текущему KSK. Тогда включение DNSSEC будет означать усиление безопасности, а не риск внезапного SERVFAIL. Если вы храните домены у одного провайдера, обычно проще держать под рукой и операции по DNS, и регистрацию доменов, чтобы не терять время на согласования в критический момент.

Для смежной практики (когда нужно подтверждать владение доменом через DNS) может пригодиться статья про автоматизацию DNS-01 для wildcard-сертификатов.