#Что происходит и когда применима инструкция
После смены регистратора или NS валидирующие резолверы могут выдавать SERVFAIL, если DS-запись в родительской зоне не соответствует DNSKEY действующих серверов. Простая смена регистратора без смены делегирования не обязательно меняет DNSSEC: сначала установите, какие записи и ключи реально используются.
#Причины: как различить похожие случаи
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Старая DS-запись осталась в родительской зонеПровайдер DNS сменился, а регистратор сохранил отпечаток ключа прежней зоны. | С проверкой DNSSEC SERVFAIL, без неё ответ о домене может существовать. | Согласовать DS с новым DNS-поставщиком либо выполнить документированную смену ключей. |
| Новая зона не подписана при существующей DSВ родительской зоне есть DS, но нынешние NS отдают неподписанные данные. | Резолверы с проверкой DNSSEC отклоняют домен, данные NS сами по себе видны. | Убедиться в режиме подписи зоны и правильном порядке перехода. |
| Ключи и подписи истекли или не совпадаютСерверы отдают разные DNSKEY/RRSIG либо подписи устарели. | Диагностический инструмент указывает на неверный/просроченный RRSIG. | Исправить подпись зоны и синхронизацию на действующих DNS-серверах. |
#Диагностика и пошаговое устранение
- 1. Определите, что именно изменилось при переносеВ кабинетах старого и нового регистратора сравните текущие NS и настройки DNSSEC. Если регистратор поменялся, но NS остались прежними, сам перенос обычно не должен менять DNSKEY; проверьте фактическую цепочку. Выпишите прежние NS, текущие NS, наличие DS и время последнего изменения. Не отключайте DNSSEC только потому, что домен стал недоступен.
- 2. Подтвердите симптомы у разных резолверовС компьютера с
digвыполните запросы к независимым рекурсивным резолверам. Код SERVFAIL может иметь несколько причин — важно увидеть его одновременно с симптомом переноса, а не сделать вывод по одному сбою сети. Для подробного диагноза используйте инструменты DNSViz или диагностику своего DNS-провайдера; не отправляйте туда секреты управления зоной. - Заменить example.com своим доменомLinux · Терминал (Bash)КомандаЗаменить example.com своим доменом. Запросы только читают DNS.
dig @1.1.1.1 example.com A +dnssecdig @8.8.8.8 example.com A +dnssec
- 3. Посмотрите DS, опубликованную родительской зонойВ терминале запустите
dig DSиdig +trace DSдля настоящего домена. DS относится к цепочке доверия родительской зоны, а не к обычной записи в веб-панели хостинга. Если DS нет, конкретная ошибка может быть не в цепочке DNSSEC; проверьте делегирование и DNS. Если DS есть, выпишите алгоритм, тег ключа и digest без попытки создать новые наугад. - example.com заменить доменом; +trace показывает цепочку делегированияLinux · Терминал (Bash)Командаexample.com заменить доменом; +trace показывает цепочку делегирования.
dig +trace DS example.comdig DS example.com +short
- 4. Сверьте DNSKEY действующей подписанной зоныПолучите имена действующих NS и запросите DNSKEY на одном из них напрямую, затем на остальных. В примере ниже сервер
ns1.example.netусловный; замените его ответом на NS. Сравните ключи с опубликованной DS с помощью панели DNS-поставщика или проверочного инструмента. Совпадение числового тега само по себе недостаточно: важен digest и алгоритм. - Подставьте настоящий авторитетный NS и домен, используйте только читающие запросыLinux · Терминал (Bash)КомандаПодставьте настоящий авторитетный NS и домен, используйте только читающие запросы.
dig NS example.com +shortdig @ns1.example.net DNSKEY example.com +dnssec
- 5. Выберите исправление вместе с DNS-поставщикомЕсли зона на новых NS корректно подписана, получите предлагаемые им точные DS-параметры и замените устаревшую DS в панели регистратора. Если зона не подписана, потребуется согласованная миграция DNSSEC с учётом времени хранения старой DS в кэшах: нельзя оставить DS, указывающую на несуществующие ключи. При высокой доступности и отсутствии опыта передайте смену DNSSEC ответственному администратору DNS.
- 6. Внесите ровно одно согласованное изменениеАвторизуйтесь у текущего регистратора, откройте карточку нужного домена → раздел DNSSEC/DS (названия отличаются). Сохраните текст и снимок старых DS. Укажите данные, выданные действующим DNS-поставщиком, либо следуйте его пошаговой процедуре миграции. После сохранения подтвердите изменение в карточке домена. Не создавайте DS самостоятельно из случайных генераторов и не выключайте проверку DNSSEC у посетителей.
- 7. Дождитесь обновления родительской зоны и кэшейПосле изменения запрашивайте DS в родительской зоне и сравнивайте результат с настройкой провайдера. Кэши валидирующих резолверов могут ещё хранить прежнюю DS; ждать нужно с учётом TTL, а не по жёстко заданным пяти минутам. Во время перехода не меняйте ключи повторно, иначе диагностика станет сложнее. Если остаётся SERVFAIL на части резолверов, соберите время/ответы для технической поддержки.
- 8. Проверьте устойчивое разрешение и сохраните сведенияПроверьте запросы A, AAAA, MX и DNSSEC с нескольких сетей. Правильное состояние: ответы с валидацией, отсутствие SERVFAIL, предсказуемые NS и DS. Зафиксируйте новую DS, дату и процедуру следующей смены ключей. Если после запланированного окна ещё ошибки, сравните ответы всех авторитетных NS и продлите обращение в поддержку, не выполняя новый хаотичный перенос.
#Как проверить, что неисправность устранена
Домен получает A/AAAA и прочие записи на валидирующих резолверах без SERVFAIL; опубликованная DS соответствует ключам действующей зоны. Исправление только в локальном /etc/resolv.conf не считается решением для пользователей.
#Если не получилось и как отменить правки
Откат DNSSEC должен быть согласован с DNS-провайдером и TTL: мгновенное удаление DS может не исправить кэши сразу, а возврат старой DS после смены ключей снова сломает домен. Храните снимок исходных записей и проводите возврат по регламенту смены ключей.
Если причина не установлена, соберите точный текст ошибки, время, имя домена, результаты проверок без паролей и приватных ключей. Передайте их ответственному администратору или поддержке регистратора, DNS-провайдера либо хостинга. Не повторяйте опасные изменения без резервной копии.