После смены DNS домен даёт SERVFAIL: проверить DNSSEC

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

Проверьте, что сломалось до обращения к сайту

Если имя не разрешается, смена SSL-сертификата или настройка страницы ошибки не устраняет этот этап. Сначала зафиксируйте доменное имя, тип запроса, использованный резолвер и наблюдаемый ответ. Сообщение браузера — начало диагностики, а не точное описание состояния DNS.

В руководстве Google Public DNS SERVFAIL встречается как при проблемах проверки DNSSEC, так и при недоступности авторитетных серверов. Дополнительные ошибки EDE могут уточнить причину, но их отсутствие не делает конкретную гипотезу доказанной.

Сопоставьте время отказа с журналом изменений домена. Что меняли: регистратора, NS, учётную запись провайдера или только адрес сайта? Назначьте одного координатора, чтобы параллельные попытки исправления не меняли разные звенья без общего плана.

Где находится связь между старой и новой инфраструктурой

DS публикуется со стороны родительской зоны; владелец домена обычно управляет её передачей через регистратора. DNS-провайдер обслуживает свою сторону: ключи DNSKEY и подписанные данные зоны. Это разные места управления, даже если интерфейс одной панели объединяет их.

В документации Cloudflare по DNSSEC описана связь DS с открытым ключом и метаданными. Смена авторитетного провайдера без согласования старых DNSSEC-записей у регистратора может нарушить проверку. Копирование A и MX эту связь не переносит.

Учебная карта согласования зоны

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

Почему ответ без проверки полезен только для диагностики

Google предлагает сравнение результата с проверкой DNSSEC и без неё как диагностический шаг. Если без проверки ответ появляется, это указывает на направление дальнейшего разбора. Такой результат не подтверждает корректность подписанной зоны.

Не предлагайте посетителям постоянно отключать валидацию или выбирать резолвер лишь потому, что он показывает адрес. Пользователи должны получать согласованный ответ при нормальной проверке. Исправление выполняется на стороне управления доменом и его DNS.

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

Выберите порядок восстановления с провайдером

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

Не удаляйте DNSKEY наугад, пока у родителя остаётся требование проверять соответствующий ключ. Cloudflare отдельно предупреждает, что удаление ключей при включённой проверке может сломать разрешение. Управляйте изменениями в согласованной последовательности и проверяйте опубликованный результат.

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

Не назначайте универсальное время ожидания

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

Мы советуем сохранять контрольные ответы с указанием времени и источника проверки. Сравнивайте одинаковые имя и тип запроса. Если один источник продолжает выдавать старое состояние, это полезное наблюдение; оно не отменяет проверку того, что публикуется сейчас.

Не переносите конкретный пример TTL из инструкции чужого провайдера на любой домен. План проверки должен учитывать ваши опубликованные записи и процедуру изменения. Срок восстановления нельзя честно назвать только по сообщению SERVFAIL.

Какие признаки позволяют закрыть задачу

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

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

Последовательность разбора

1. Зафиксируйте точное имя, тип запроса и SERVFAIL вместе с доступными пояснениями.
2. Установите текущее делегирование и фактически отвечающих авторитетных провайдеров.
3. Сопоставьте опубликованную DS с данными действующей зоны и подписями.
4. Отделите подтверждённую ошибку DNSSEC от других проблем разрешения.
5. Согласуйте исправление с владельцами управления зоной и регистратором.
6. Примените предусмотренный порядок и проверьте нормальную валидацию после распространения.
7. Запишите результат и зависимости для будущего переноса.

При аудите безопасности цепочку доверия рассматривайте отдельно от наличия HTTPS. В доработке эксплуатации стоит закрепить ответственных и контроль смены DNS-провайдера. Тогда следующий перенос будет включать DNSSEC в план заранее, а не только после недоступности домена.