DNSSEC и SERVFAIL после смены NS: кейс krivoshein.site (Cloudflare → Beget)

Смена NS с Cloudflare на Beget для krivoshein.site закончилась классикой: часть резолверов отдавала A-запись, Google DNS и Cloudflare DNS – SERVFAIL. Причина – «хвост» DNSSEC: DS у регистратора остались, а зона на новых NS уже не подписывалась. Ниже – как это диагностировалось, что ответила поддержка и в каком порядке чинить, чтобы не ловить SERVFAIL после смены DNS.

Что происходило

Домен ушёл с Cloudflare обратно на NS Beget. NS у регистратора обновили, ждали пропагации. Через несколько часов часть аудитории сайт не открывала. Проверка с валидирующих резолверов:

dig krivoshein.site @8.8.8.8

Ответ:

;; Got SERVFAIL reply from 8.8.8.8

nslookup krivoshein.site 1.1.1.1

** server can't find krivoshein.site: SERVFAIL

При этом через DNS без строгой DNSSEC-валидации (в том кейсе – Yandex DNS) имя резолвилось. Типичный симптом «битого» DNSSEC, а не «просто NS ещё не разошлись».

Проверка через другие NS (CLO)

Для сужения причины домен временно делегировали на NS CLO (ns1.clo.ru, ns2.clo.ru). Запросы через них отрабатывали. Значит, дело не в «мёртвом» домене как таковом, а в связке делегирование + оставшиеся DS / DNSSEC после Cloudflare.

Скрин проверки:

В чём была ошибка

На Cloudflare DNSSEC часто включается и публикует DS у родительской зоны (.site / регистратор). При уходе на Beget NS сменили, а DS не сняли. Цепочка:

• родительская зона говорит: «зона подписана, вот DS»;
• новые NS отдают обычные (несогласованные с этими DS) записи;
• валидирующий резолвер (8.8.8.8, 1.1.1.1) отвечает SERVFAIL;
• резолвер без валидации (в кейсе – 77.88.8.8) отдаёт A и сайт «вроде жив».

Итог для пользователей: у кого DNS через Google/Cloudflare – беда, у кого через «мягкий» резолвер – всё открывается. Диагностика «у меня работает» обманчива.

Как чинили

1. Тикет в поддержку Beget

В тикете зафиксировали:

• домен вернули с Cloudflare на NS Beget;
• на 8.8.8.8 / 1.1.1.1 – SERVFAIL, на Yandex DNS – OK;
• подозрение на остаточные DS после Cloudflare.

Поддержка подтвердила лишние DS и удалила запись. Само по себе это ключ, но кэш валидирующих резолверов ещё какое-то время может отдавать старый SERVFAIL.

2. Повторные dig

Сразу после удаления DS:

dig krivoshein.site @8.8.8.8

Ещё SERVFAIL. Cloudflare DNS – то же. Yandex:

dig krivoshein.site @77.88.8.8

krivoshein.site.        2218    IN      A       90.156.253.7

3. Flush кэша и ожидание TTL

Чтобы ускорить обновление у Google Public DNS, использовали форму сброса кэша Google Public DNS. Плюс обычное ожидание, пока разойдутся кэши DS/NS.

4. Финал

Через несколько часов валидирующие резолверы ожили:

nslookup krivoshein.site 8.8.8.8

Name:   krivoshein.site
Address: 90.156.253.7

SERVFAIL ушёл, домен снова резолвился у всех проверенных публичных DNS.

Как не наступить снова

1. Перед сменой NS выключите DNSSEC и удалите DS у регистратора (или в панели, где DS публикуются). Порядок: снять DNSSEC/DS, дождаться, сменить NS. Не наоборот.
2. Проверяйте несколько резолверов, не только «у меня дома»:
   dig example.com @8.8.8.8
dig example.com @1.1.1.1
dig example.com @77.88.8.8
3. Смотрите DS явно: dig DS example.com +short и dig DNSKEY example.com +short на текущих NS. DS без согласованной подписи на стороне NS – красный флаг.
4. Визуализация цепочки: DNSViz, Verisign DNSSEC Debugger.
5. Тикет в поддержку регистратора/хостера с выводами dig – быстрее, чем гадать в панели в одиночку, если DS правите только они.

Кратко

SERVFAIL только на 8.8.8.8/1.1.1.1 при живом ответе с «обычных» DNS почти всегда про DNSSEC: остались DS после Cloudflare (или другого провайдера с DNSSEC), а новая зона не совпадает с ними. Снимаете DS, ждёте кэш (и flush Google при необходимости) – домен оживает. Смена NS без проверки DNSSEC – готовый рецепт «сайт то открывается, то нет».

Источники и ссылки