Всем привет! Сегодня я расскажу о том, как решить проблему с делегированием домена и конфликтами DNSSEC. Это будет полезно тем, кто сталкивался с ошибками SERVFAIL при использовании Google DNS или Cloudflare DNS. Разбираем на примере моего домена krivoshein.site.
Предыстория: от Cloudflare к Beget и обратно
Всё началось с того, что я решил перевести свой домен krivoshein.site с Cloudflare обратно на NS-серверы Beget. Думал, что это обычная процедура — сменил NS-записи у регистратора и жду, пока изменения обновятся. Однако всё пошло не так гладко.
Через пару часов я заметил, что часть пользователей не может открыть сайт. Проверка через Google DNS и Cloudflare DNS показала ошибку SERVFAIL.
Вот пример команды:
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
Я начал разбираться, и вот что выяснил: проблема связана с DNSSEC.
Проверка через CLO
Чтобы уточнить проблему, я временно делегировал домен на NS-серверы CLO (ns1.clo.ru, ns2.clo.ru). Результат показал, что CLO успешно обработал записи, и DNS-запросы начали работать. Это подтвердило, что проблема была не в самом домене, а в остаточных DS-записях или конфликтах между DNSSEC и настройками предыдущего хостинга.
Пример проверки:
В чём была проблема?
Когда домен был делегирован на Cloudflare, там автоматически активировался DNSSEC. При возврате домена на NS-серверы Beget записи DNSSEC (DS-записи) остались у регистратора. Это вызвало конфликт:
- Yandex DNS (77.88.8.8) не проверяет DNSSEC, поэтому домен работал нормально.
- Google DNS (8.8.8.8) и Cloudflare DNS (1.1.1.1) проверяют DNSSEC, и при наличии неподписанных записей возвращают
SERVFAIL.
Итог: часть пользователей могла открыть сайт, а часть — нет.
Этапы решения проблемы
1. Связался с поддержкой Beget
Я описал ситуацию в тикете:
- Домейн был делегирован с Cloudflare обратно на Beget.
- Начались проблемы с DNS-разрешением.
- Причина, как выяснилось, в DS-записях, оставшихся после использования Cloudflare.
Поддержка оперативно проверила настройки и подтвердила наличие «лишних» DS-записей. Ответом было: «Запись удалена». На этом этапе я выдохнул, но проблема была решена не до конца.
2. Проверка обновлений через Google и Cloudflare
После удаления DS-записей я снова запустил проверку через терминал:
dig krivoshein.site @8.8.8.8
Ответ всё ещё был SERVFAIL. Cloudflare тоже возвращал ту же ошибку. Однако через Yandex DNS сайт открывался нормально:
dig krivoshein.site @77.88.8.8
Ответ:
krivoshein.site. 2218 IN A 90.156.253.7
3. Очистка кэша и ожидание
Я воспользовался Google DNS Flush, чтобы ускорить обновление записей. Кроме того, просто ждал, пока изменения распространения завершатся.
4. Финальная проверка
Через несколько часов всё начало работать. Вот финальный результат:
nslookup krivoshein.site 8.8.8.8
Ответ:
Name: krivoshein.site Address: 90.156.253.7
Google и Cloudflare больше не возвращали SERVFAIL, и домен заработал для всех пользователей.
Выводы: как избежать подобных проблем
- Перед сменой NS-записей отключайте DNSSEC. Если вы планируете смену NS-серверов, проверьте, активировано ли DNSSEC. Если оно включено, удалите DS-записи до перехода.
- Проверяйте распространение изменений. После смены NS-записей не забудьте проверить, как разные DNS-серверы видят ваш домен:
dig вашдомен @8.8.8.8 dig вашдомен @1.1.1.1 dig вашдомен @77.88.8.8 - Используйте поддержку. Если вы не уверены в правильности настроек, не стесняйтесь обращаться в поддержку вашего регистратора или хостинга.
- Проверяйте конфликты DNSSEC. Для анализа зоны используйте инструменты:
Эта ситуация помогла мне разобраться в тонкостях работы DNS и DNSSEC. Надеюсь, мой опыт будет полезен и вам! Если у вас есть похожие истории — делитесь в комментариях. 😊
