Потеря доступности сайта при смене DNS — это не «ожидание обновления», а конкретный простой, который в e-commerce секторе с оборотом от 1 млн руб./мес. обходится в 15-30 тысяч рублей за каждый час даунтайма. Ошибка в одной записи A или неверный TTL превращают ваш бизнес в заглушку «Сайт недоступен», пока кэш провайдеров не обнулится.
Сценарий 1: Ошибка TTL и «эффект хвоста»
Самая частая ошибка новичков — смена NS-серверов при стандартном TTL (Time to Live) в 86400 секунд (24 часа). В итоге часть пользователей видит новый сервер, а часть — старый, что приводит к разрыву сессий и потере до 40% конверсии в первые сутки миграции.
Кейс: Перенос сайта с общего хостинга на VPS. Администратор сменил IP в записи A, не снизив TTL заранее. Итог: сайт был недоступен для 30% аудитории в течение 12 часов, так как DNS-рекурсоры крупных провайдеров (МТС, Билайн) кэшировали старый адрес. Экспертный вывод: За 24 часа до переноса всегда снижайте TTL до 300-600 секунд. Это сокращает окно неопределенности с суток до 10 минут.
Сценарий 2: Конфликт Glue Records при делегировании
При переносе домена на собственные NS (например, ns1.nice4me.ru) часто забывают про Glue Records — специальные IP-адреса, которые регистрируются в зоне .ru для разрешения имен самих серверов. Без них возникает циклическая зависимость: чтобы найти сайт, нужно знать IP сервера, а чтобы узнать IP сервера, нужно зайти на сайт.
В практике встречается в 15% случаев при переходе на частные DNS-кластеры. Если в панели регистратора не прописаны IP для NS-серверов, сайт будет висеть в статусе «недоступно» даже при верных записях в зоне. Экспертный вывод: Проверяйте наличие Glue Records через команду dig или онлайн-сервисы DNS-чекеров сразу после делегирования, не дожидаясь жалоб клиентов.
Сценарий 3: Ошибка в MX-записях и «молчание» почты
Часто при смене DNS-хостинга копируют только A-запись, забывая про MX (Mail Exchange). В результате сайт работает, но почта перестает приходить. Для бизнеса это критичнее, чем временный простой фронтенда, так как теряются лиды и заказы.
Пример: При переезде на Cloudflare пользователь забыл перенести MX-записи своего почтового сервера. Результат: 100% возврата писем (Bounce rate) с ошибкой 550. Восстановление заняло 4 часа, за которые было потеряно около 50 входящих заявок. Экспертный вывод: Смена DNS — это всегда аудит всей зоны. Сначала создайте все записи (A, MX, TXT, CNAME) на новом сервере, и только потом меняйте NS-серверы.
Сценарий 4: Дублирование записей A и конфликт IP
Критическая ошибка — наличие двух разных A-записей для одного хоста. DNS-сервер начинает отдавать их по очереди (Round Robin). В итоге пользователь то попадает на новый сервер, то на старый, где сайт уже удален или выдает ошибку. Это часто путают с тем, что почему страница недоступна, хотя фактически работает часть узлов.
В таких случаях браузер кэширует «битый» ответ, и даже после удаления старой записи сайт остается недоступным для конкретного пользователя еще несколько часов. Экспертный вывод: Перед обновлением IP удаляйте старую запись полностью. Никогда не держите два разных IP для одного домена, если не используете специально настроенный балансировщик нагрузки.
Сценарий 5: Проблемы с DNSSEC и блокировка зоны
DNSSEC (расширение безопасности) добавляет цифровую подпись к записям. При смене DNS-провайдера, если старые ключи DNSSEC остались в панели регистратора, а новые не были установлены, проверка подлинности провалится. Современные браузеры и рекурсоры просто заблокируют доступ к сайту из соображений безопасности.
Это «невидимая» ошибка: записи верны, сервер пингуется, но сайт недоступен. Доля таких сбоев растет с переходом на строгую валидацию в .ru и .com зонах. Экспертный вывод: Отключайте DNSSEC за 24-48 часов до смены NS-серверов. Включайте его только после полной стабилизации работы на новом хостинге.
Вывод
Чтобы избежать простоя, забудьте о методе «поменял и жду». Правильный алгоритм: снижение TTL до 300с $
ightarrow$ отключение DNSSEC $
ightarrow$ создание полной копии зоны на новом сервере $
ightarrow$ смена NS $
ightarrow$ ожидание 24 часов $
ightarrow$ возврат TTL к норме. Избегайте смены DNS в пятницу вечером; любой сбой в выходные увеличит время реакции техподдержки регистратора с 15 минут до 12 часов, что недопустимо для коммерческого проекта.