#Что произошло и как распознать неисправность
После включения DNSSEC или переноса подписанной зоны часть рекурсивных DNS-серверов отвечает SERVFAIL, хотя прямой запрос к авторитетному BIND9 иногда возвращает A-запись. Это не означает, что у BIND9 нужно отключить проверку DNSSEC: причиной могут быть неверный DS у регистратора, устаревшая RRSIG, несогласованные DNSKEY либо недоступный авторитетный сервер. Сначала определите, где именно возникает отказ: на авторитетном сервере с флагом AA или на проверяющем рекурсивном сервере. Сравните запросы с проверкой DNSSEC и с диагностическим флагом CD; он не изменяет настройки и используется только для определения типа сбоя.
#Причины и отличительные признаки
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| DS родительской зоны не соответствует DNSKEYПри перевыпуске ключей или переносе подписанной зоны DS у регистратора остался от прежнего ключа. | Авторитетный сервер отвечает, а проверяющий рекурсор выдаёт SERVFAIL; проверка через CD успешна. | Согласовать DS с опубликованным ключом по плану смены DNSSEC. |
| Истекли подписи RRSIGПодписи в зоне не продлеваются или неправильно работает система автоматического подписания. | dig ... RRSIG показывает давно истёкшие временные метки. | Исправить механизм подписания и повторно проверить цепочку. |
| Служба не загрузила новую зонуОшибка в файле, журнале обновлений или доступе к ключам мешает отвечать авторитетно. | Прямой запрос авторитетному узлу не содержит AA либо возвращает SERVFAIL. | Прочесть журнал named и исправить конкретную ошибку загрузки. |
| Некоторые серверы отвечают старой подписьюВторичный сервер ещё не получил актуальную зону. | Результаты по разным NS и SOA serial не совпадают. | Проверить передачу зоны, NOTIFY и наборы ключей на NS. |
#Пошаговая диагностика и исправление
- Определите, какой сервер выдаёт SERVFAILНа своём компьютере откройте терминал Linux или PowerShell с установленной утилитой
dig(на Debian её предоставляет пакет dnsutils/bind9-dnsutils). Выполнитеdig @1.1.1.1 example.com A +dnssecдля своего имени вместо example.com. Найдитеstatus:и флаги ответа; при SERVFAIL проверьте другой известный рекурсор. Если SERVFAIL только у одного — возможен его кеш; если у нескольких, продолжайте диагностику подписи. - Сравните запрос с диагностическим флагом CDВ том же терминале выполните
dig @1.1.1.1 example.com A +dnssec +cd. Флаг CD просит не выполнять проверку DNSSEC для этого конкретного запроса, но не выключает её на сервере. Если с CD видны записи, а без него SERVFAIL, наиболее вероятна ошибка цепочки доверия. Если оба запроса неудачны, сначала проверьте доступность авторитетных NS и саму зону. - Уточните авторитетные серверы и проверьте каждыйЗапросите
dig +short NS example.comи затем отдельноdig @ns1.example.com example.com SOA +norecurse, меняя ns1.example.com на реальный сервер зоны. В полном выводе ищитеaa: он показывает авторитетный ответ. Сравните серийные номера SOA на всех NS. Если один отвечает старым набором — исправляйте синхронизацию зоны, а не DNSSEC во всём интернете. - Проверьте записи DS и DNSKEY, не изменяя ихИспользуйте
dig example.com DS +dnssecдля записи DS из родительской зоны, затемdig @ns1.example.com example.com DNSKEY +dnssecдля открытых ключей авторитетного сервера. Сопоставление дайджеста DS с DNSKEY требует DNSSEC-анализатора или штатных инструментов BIND, а не визуального сравнения длинных строк. Отсутствие DS допустимо для неподписанной цепочки, но оставшийся DS при сменившемся ключе приводит к сбою. - Посмотрите подписи и время сервераЗапросите
dig @ns1.example.com example.com SOA +dnssec; если возвращаются RRSIG, проверьте их сроки действия и время сервера. На сервере с правами администратора откройте SSH, проверьтеtimedatectl status, журналыsudo journalctl -u bind9 -n 100 --no-pager(на отдельных системах имя службыnamed). Если часы отклоняются, исправляйте синхронизацию времени штатным NTP, а не ручным обходом DNSSEC. - Проверьте действительную загрузку и подпись зоныНа Linux-сервере с SSH и правами администратора выполните
sudo named-checkconf -z— эта команда пробно загружает основные зоны из активной конфигурации. Если обнаружена ошибка, устраните её по строке сообщения. На динамически обновляемой подписанной зоне не правьте файл вслепую: подписи может обслуживать inline-signing, ключи и журнал.jnl. - Исправьте подтверждённое несоответствие без отключения защитыЕсли авторитетные ответы правильные, а DS не соответствует ключу, согласуйте обновление DS в панели регистратора по документации вашей системы подписания, сохранив прежние значения. Если RRSIG истекли, восстановите автоматическое подписывание BIND9 или процедуру повторного подписания. Перед любым изменением сохраните копию зоны и настройки; не публикуйте новый DS до проверки соответствующего DNSKEY у всех авторитетных серверов.
- Перепроверьте цепочку с нескольких рекурсоров и продумайте откатПосле изменения подождите срок кеширования DS/DNSKEY и запросите домен через несколько рекурсоров обычным запросом без CD. Должны появиться записи с
status: NOERROR, без SERVFAIL, и ожидаемые A/AAAA. Если отказ сохраняется, верните прежнюю конфигурацию подписания, если это безопасно для текущего DS, либо согласуйте план восстановительного переключения DNSSEC со специалистом: поспешный возврат старого ключа может сделать проблему хуже. - Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
#Как проверить результат и что делать при неуспехе
Окончательный успех — каждый авторитетный NS возвращает одинаковую актуальную зону, а независимые проверяющие рекурсоры разрешают её без CD. Если остался SERVFAIL, сохраните обезличенные выводы, NS и время проверки; не удаляйте DNSSEC-записи наугад.