Ошибка в одной DNS-записи может обнулить трафик сайта за 15 минут, а время полного восстановления (TTL propagation) в худшем случае растянется до 48 часов. Разбор кейса rbk-tifavyy.ru показывает, как банальная смена NS-серверов без подготовки превращает бизнес-актив в «заглушку» с потерей до 30% конверсии в первые сутки простоя.
Ошибка №1: Игнорирование TTL при миграции
Администратор оставил стандартный TTL (Time to Live) на уровне 86400 секунд (24 часа). При внесении правок в A-запись или смене NS-серверов, старые данные кэшировались провайдерами по всему миру. В итоге часть пользователей видела сайт, часть — ошибку «сервер не найден», что создало хаос в аналитике и привело к разрыву сессий у 40% активных визиторов.
Кейс: вместо стандартных 24 часов нужно за 48 часов до работ снизить TTL до 300-600 секунд. Это сокращает окно «недоступности» с суток до 10 минут. Экспертный вывод: работа с DNS без предварительного занижения TTL — это профессиональная халатность, увеличивающая риск потери лидов в 144 раза.
Ошибка №2: Конфликт Glue-записей и NS
При переносе сайта на новые серверы была допущена ошибка в Glue-записях (записях, связывающих имя NS-сервера с его IP). В итоге возникла циклическая зависимость: чтобы узнать IP сайта, рекурсивный DNS-сервер запрашивал данные у NS, который сам был недоступен из-за неверного IP. Сайт стал полностью недоступен для 100% новых пользователей.
На практике такая ошибка лечится только через панель регистратора, а не через DNS-менеджер хостинга. Это типичный сценарий, когда возникает ошибка «Страница недоступна», но проблема лежит на уровне маршрутизации, а не контента. Экспертный вывод: всегда проверяйте связку NS $
ightarrow$ IP через dig или nslookup до того, как удалите старые записи.
Ошибка №3: Отсутствие проверки MX и TXT записей
Фокусируясь на A-записи (доступности сайта), администратор забыл перенести MX-записи и SPF/DKIM. Результат: сайт «подняли» за 2 часа, но корпоративная почта лежала 12 часов. Потери составили около 150 неотправленных заявок, а исходящие письма начали попадать в спам из-за невалидного SPF, что снизило Open Rate рассылок с 25% до 3%.
Мини-кейс: компания теряет в среднем от 5 000 до 50 000 рублей в час при остановке почтового обмена в B2B-сегменте. Экспертный вывод: DNS — это единый организм; перенос только веб-части без аудита почтовых записей — это гарантированный простой бизнес-коммуникаций.
Ошибка №4: Дублирование A-записей и конфликт IP
В зоне сосуществовали две A-записи для одного хоста: старый IP и новый. DNS-серверы начали отдавать их по очереди (Round Robin). В итоге 50% трафика уходило на «мертвый» сервер, вызывая ошибку 403 или 404 в зависимости от настроек веб-сервера. Это привело к резкому скачку показателя отказов (Bounce Rate) с 12% до 58% за час.
Важно отличать техническую недоступность от удаления страницы, так как поисковые роботы при получении 404-й ошибки начинают выкидывать URL из индекса. Экспертный вывод: наличие дублей в DNS-зоне недопустимо; любая запись должна быть либо обновлена, либо удалена, иначе вы играете в рулетку с SEO-позициями.
Ошибка №5: Смена DNS без проверки прав доступа
После восстановления DNS-записей выяснилось, что новый сервер блокирует запросы по IP или имеет некорректный .htaccess. Сайт перестал быть доступен для индексации, хотя пинг шел успешно. Это создало риски неправильной настройки прав доступа, когда ресурс виден владельцу, но закрыт для Googlebot и YandexBot.
Сравнение: ошибка DNS исправляется за минуты (после обновления кэша), но ошибка прав доступа на сервере может привести к выпадению из ТОП-10 за 3-5 дней из-за невозможности обхода сайта краулером. Экспертный вывод: доступность DNS $
eq$ доступность сайта; финальный тест должен включать проверку HTTP-кода ответа (должен быть 200 OK) для всех ключевых страниц.
Вывод
Чтобы избежать полной остановки бизнеса, забудьте о «быстрых правках» в DNS. Единственный верный алгоритм: снижение TTL до 300 секунд за 48 часов до работ $
ightarrow$ полный аудит всех записей (A, MX, TXT, CNAME) $
ightarrow$ обновление $
ightarrow$ проверка через сторонние DNS-чекеры. Избегайте смешивания разных NS-серверов в одной зоне и никогда не удаляйте старые записи до подтверждения работоспособности новых. Начинайте с внедрения чек-листа миграции, чтобы техническая ошибка не превратилась в финансовую катастрофу.
