Перенос DNS-зоны с Cloudflare на российский сервис выглядит как рутинная операция: скопировал записи, поменял NS у регистратора, подождал сутки. На практике именно здесь ломается больше всего сайтов, и половина поломок связана не с A-записями или MX, а с DNSSEC. Если на Cloudflare была включена подпись зоны, а вы меняете NS, не удалив предварительно DS-запись у регистратора, домен перестаёт резолвиться вообще для всех резолверов, которые валидируют ответы. Не «медленно открывается», не «частично работает», а выдаёт SERVFAIL. Ниже чек-лист, который я советую прогонять до, во время и после миграции, с акцентом на те грабли, о которых обычно вспоминают уже по факту аварии.
Проверка DNSSEC до смены NS: главный пункт чек-листа
DNSSEC работает по цепочке доверия: родительская зона (домен верхнего уровня) хранит DS-запись, которая указывает на DNSKEY в вашей зоне. Резолвер, поддерживающий валидацию, идёт по этой цепочке и проверяет подпись каждого ответа. Cloudflare при включении DNSSEC автоматически публикует DS-запись у регистратора, если регистратор это поддерживает, либо просит добавить её вручную. Пока NS указывают на Cloudflare, цепочка сходится и всё работает.
Как только вы меняете NS на серверы российского сервиса, но DS-запись у регистратора остаётся от Cloudflare, цепочка рвётся. Новые NS отдают записи без подписи, которую ожидает родительская зона, либо отдают подпись, не совпадающую с DS. Резолверы, которые валидируют (а это Google 8.8.8.8, Cloudflare 1.1.1.1, Quad9, большинство корпоративных резолверов и провайдерских), возвращают SERVFAIL. Сайт недоступен для всех, кто ходит через валидирующий резолвер, то есть практически для всех.
Порядок действий железный: сначала заходите в панель Cloudflare, отключаете DNSSEC, ждёте, пока DS-запись исчезнет из родительской зоны (обычно от нескольких минут до нескольких часов, TTL DS наследуется от TLD), проверяете через dig, что DS больше не отдаётся, и только потом меняете NS. Обратный порядок гарантирует простой.
Проверить текущее состояние просто: dig DS вашдомен.ru @8.8.8.8 +short. Если команда что-то возвращает, DS-запись ещё жива и менять NS нельзя.
Как убедиться, что DS-запись действительно ушла
Отключение DNSSEC в панели Cloudflare не означает мгновенного исчезновения DS из зоны .ru. Запрос идёт через регистратора, и скорость зависит от того, как быстро он передаёт изменение в реестр TLD. Я видел случаи, когда DS пропадала за пять минут, и случаи, когда процесс занимал больше суток из-за ручной обработки на стороне регистратора.
Проверяйте с нескольких публичных резолверов: dig DS вашдомен.ru @8.8.8.8, @1.1.1.1, @9.9.9.9. Дополнительно смотрите ответ авторитативного сервера зоны .ru через dig +trace. Пока хотя бы один резолвер отдаёт DS, смена NS опасна. Параллельно стоит держать в голове: если регистратор не поддерживает управление DS через API и делает всё руками, закладывайте запас времени.
Инвентаризация зоны: что реально переносится
Вторая по частоте ошибка после DNSSEC – неполный перенос записей. Панель Cloudflare показывает не всё, что реально работает: часть записей может быть создана через API, часть – через Terraform, часть – через интеграции с хостингом. Перед миграцией выгружаете полный дамп зоны через API (GET /zones/{zone_id}/dns_records) и сверяете его с тем, что видите глазами в интерфейсе.
Отдельно пройдитесь по типам записей. A и AAAA – база, но не забывайте про CNAME для поддоменов, MX и TXT для почты (SPF, DKIM, DMARC), CAA, SRV для сервисов, NS для делегированных подзон. Записи с proxied-статусом на Cloudflare (оранжевое облако) при переносе теряют эту функцию: на новом сервисе reverse proxy и защита настраиваются иначе, и об этом нужно помнить, чтобы не оставить origin открытым для прямых атак.
Почтовые записи – отдельная головная боль. Если MX указывает на Google Workspace или Microsoft 365, ничего страшного, они продолжат работать. Но TXT-записи с DKIM часто содержат длинные значения, которые при ручном копировании рвутся на части. После переноса обязательно проверяйте почту через инструменты вроде mail-tester: сломанный DKIM означает, что письма уходят в спам, и заметить это можно не сразу.
TTL и окно миграции
За сутки до миграции снизьте TTL на всех критичных записях до 300 секунд. Это даст вам возможность откатиться быстро, если что-то пойдёт не так. После успешного переноса и стабилизации TTL можно вернуть к нормальным значениям (3600 и выше), чтобы снизить нагрузку на DNS-инфраструктуру.
Окно миграции выбирайте не в пик трафика. Для интернет-магазина это ночь с воскресенья на понедельник или раннее утро буднего дня. Для корпоративного сайта с низким трафиком можно и в рабочее время, но лучше не рисковать. аналог cloudflare pages offers additional context worth reviewing. Старые NS отдают ответы ещё какое-то время после смены, и в этот период часть пользователей ходит на старую инфраструктуру, часть – на новую. Если вы отключили старую зону слишком рано, эти пользователи получат отказ.
Настройка защиты и производительности на новом сервисе
Когда NS переключены и зона резолвится, начинается второй этап – воспроизведение того, что раньше делал Cloudflare. Многие недооценивают объём: помимо DNS и SSL, там были WAF, защита от ботов, rate limiting, L7 DDoS-фильтрация, GeoIP-правила, кэширование и аналитика. Российский аналог Cloudflare, например TrafficVeil, закрывает эти функции в одном контуре, но настраивать их нужно осознанно, а не по принципу «включу всё и посмотрю».
Начните с SSL. Выпустите сертификат на новом сервисе до смены NS, чтобы не оказаться в ситуации, когда домен уже резолвится, а HTTPS не работает. Проверьте цепочку через openssl s_client и убедитесь, что промежуточные сертификаты отдаются корректно: некоторые клиенты, особенно мобильные, не умеют достраивать цепочку самостоятельно. Если использовался Cloudflare Origin Certificate, его нужно заменить на сертификат нового сервиса или на Let’s Encrypt.
Дальше – reverse proxy и WAF. Проверьте, что origin-сервер закрыт от прямых обращений: если IP вашего сервера известен и доступен напрямую, вся защита на уровне прокси обходится одним curl с подменённым Host. Ограничьте доступ по IP-адресам нового сервиса на уровне firewall, а уже потом включайте правила WAF. Правила стоит тестировать в режиме логирования, а не блокировки: агрессивный WAF на старте легко режет легитимный трафик, особенно POST-запросы от форм и API.
GeoIP-фильтрация и защита от ботов настраиваются в последнюю очередь. Если у вас аудитория только из России, ограничение по гео снижает шум и нагрузку, но будьте осторожны с корпоративными пользователями, которые ходят через VPN с зарубежными exit-нодами. То же с защитой от ботов: современные антибот-системы на базе поведенческих признаков дают меньше ложных срабатываний, чем простые challenge-страницы, но всё равно требуют наблюдения в первые дни.
Контроль после миграции и типичные сценарии отката
Первые 72 часа после смены NS – период наблюдения. Проверяйте резолвинг с разных точек: через публичные резолверы, через мобильные сети разных операторов, через зарубежные сервисы вроде whatsmydns.net. Если видите расхождения, это нормально в первые часы из-за кэширования, но если через сутки часть резолверов всё ещё отдаёт старые адреса, значит TTL был слишком большим или делегирование настроено не везде.
Отдельно мониторьте метрики: долю ошибок 5xx, время ответа, количество заблокированных запросов. Резкий рост блокировок в первые дни – почти всегда признак слишком агрессивных правил WAF. Резкий рост 5xx – проблема на origin, возможно, из-за того, что новый прокси не передаёт нужные заголовки (X-Forwarded-For, X-Forwarded-Proto) и приложение не понимает, что запрос пришёл по HTTPS.
План отката держите наготове. Он простой: возвращаете NS на прежние значения, ждёте распространения, проверяете. Но откат сработает только если вы не удалили зону на старом сервисе. Не удаляйте её минимум неделю после успешной миграции – это страховка на случай, если всплывёт проблема, которую вы не заметили сразу.
И последнее, что стоит проверить: аналитика и лидогенерация. Если вы использовали Cloudflare для сбора статистики или как часть цепочки обработки форм, убедитесь, что на новом сервисе эти данные собираются и передаются в ваши системы. Потеря видимости по конверсии сайта на несколько дней – неприятный сюрприз, который обнаруживается, когда маркетинг спрашивает, почему упало число заявок.
Чек-лист получается такой: отключить DNSSEC и дождаться исчезновения DS-записи, выгрузить полный дамп зоны, снизить TTL, подготовить SSL и правила защиты на новом сервисе, сменить NS, мониторить резолвинг и метрики минимум трое суток, держать старую зону живой неделю. Пункт про DNSSEC – первый и самый важный: если его пропустить, всё остальное не имеет значения, потому что сайт просто не будет открываться. Российский аналог Cloudflare вроде TrafficVeil снимает часть этих забот за счёт того, что DNS, SSL, reverse proxy, WAF, защита от ботов, L7 DDoS, GeoIP-фильтрация и аналитика живут в одном контуре, но базовую гигиену миграции это не отменяет.