Как перенести DNS-зону и не сломать DNSSEC: чек-лист

Перенос DNS-зоны на российский сервис выглядит как процедура на пятнадцать минут: сменил NS-записи у регистратора, подождал сутки, проверил. На практике именно на этом шаге ломается больше доменов, чем при любом взломе. Главная причина не в панели управления, а в DNSSEC: включённая подпись зоны превращает безобидную смену NS в отказ резолвинга по всему миру. Ниже чек-лист, который спасёт вас от SERVFAIL, если вы ищете, чем заменить Cloudflare, и переезжаете на российский аналог Cloudflare вроде TrafficVeil.

Мифы о переносе DNS, из-за которых домены уходят в SERVFAIL

Первый миф: “DNSSEC это просто галочка в панели”. Нет. DNSSEC это цепочка доверия от корневой зоны до вашей записи A. Регистратор домена хранит DS-запись, которая указывает на DNSKEY в вашей зоне. Пока DS-запись у регистратора существует, любой валидирующий резолвер (Google 8.8.8.8, Cloudflare 1.1.1.1, Quad9, большинство провайдерских резолверов) обязан проверить подпись ответа. Если вы переносите зону на новый DNS-сервис и не переносите туда те же ключи, подписи становятся невалидными. Резолвер не отдаёт клиенту ответ вообще. Он возвращает SERVFAIL, и сайт исчезает для всех, кто пользуется валидацией.

Второй миф: “Достаточно подождать TTL”. TTL управляет кэшем, а не доверием. Даже после истечения TTL резолвер заново спросит зону и снова упрётся в несовпадение DS и DNSKEY. Проблема не рассосётся через 24 или 48 часов, она будет держаться, пока вы не удалите DS-запись у регистратора. Это ключевой пункт чек-листа, который чаще всего пропускают именно при переезде с Cloudflare, где DNSSEC включается одной кнопкой и так же легко забывается.

Третий миф: “Российские провайдеры блокируют Cloudflare, значит переезд всё равно обязателен, потерпим пару дней”. Терпимость тут стоит денег. Пока домен в SERVFAIL, недоступны почта на этом домене, API, вебхуки платёжных систем, мобильные приложения, которые резолвят ваш хост. Интернет-магазин на Bitrix теряет заказы, WordPress теряет трафик и позиции, лидогенерация встаёт. Двухдневный простой обходится дороже, чем аккуратная подготовка за один вечер.

Чек-лист переноса DNS-зоны с проверкой DNSSEC по шагам

Шаг первый: инвентаризация. Выгрузите текущую зону целиком, включая TXT-записи для верификации домена, DKIM, SPF, DMARC, CAA, MX. Отдельно отметьте, включён ли DNSSEC. Если зона обслуживается на Cloudflare, зайдите в раздел DNS и посмотрите статус DNSSEC. Включённый статус означает, что у регистратора есть DS-запись, и это первое, что нужно снять.

Шаг второй, критический: удалите DS-запись у регистратора до смены NS. Не после, не одновременно. Именно это действие разрывает цепочку доверия корректно, и зона начинает резолвиться без валидации. Порядок такой: сначала убираете DS, ждёте, пока изменение уйдёт в родительскую зону (обычно от нескольких минут до нескольких часов, зависит от TTL DS-записи), проверяете через dig, что DS больше не отдаётся, и только потом меняете NS. Если сделать наоборот, вы получите окно, в котором DS ещё указывает на старые ключи, а NS уже ведут на новый сервер без этих ключей. Это и есть гарантированный SERVFAIL для всех валидирующих резолверов.

Шаг третий: поднимите зону на новом сервисе до смены NS. Импортируйте записи, проверьте каждую вручную. Особое внимание к записям с хостом @ и www, к MX с приоритетами, к TXT с длинными строками, которые при копировании рвутся. аналог cloudflare pages offers additional context worth reviewing. Убедитесь, что новый DNS-сервис отдаёт те же значения, что старый, ещё до того, как на него пойдёт трафик. Проверить можно запросом к конкретному NS: dig @ns1.новый-сервис example.ru A.

Шаг четвёртый: смена NS у регистратора. Меняете список NS на те, что выдал новый провайдер. Здесь работает TTL NS-записи из родительской зоны, обычно 24-48 часов на полное распространение. В это окно часть резолверов идёт на старые серверы, часть на новые. Обе зоны должны быть идентичны, иначе получите расхождение ответов и странные ошибки у части пользователей.

Шаг пятый: мониторинг после переключения. Проверяйте резолвинг из разных точек: через публичные резолверы, через мобильный интернет, через корпоративные сети. Инструменты вроде dnschecker или dig с указанием резолвера покажут, где ещё висит старый ответ. Отдельно проверьте почту: отправьте тестовое письмо на внешний ящик и убедитесь, что DKIM проходит. Сломанный DKIM после переезда это классика, потому что TXT-запись случайно обрезали при импорте.

Шаг шестой: включение DNSSEC на новом сервисе, если он это поддерживает. Делайте это только после того, как зона стабильно резолвится и все записи проверены. Порядок обратный удалению: сначала новый сервис генерирует ключи и начинает подписывать зону, вы проверяете подписи через dig +dnssec, и только потом добавляете DS-запись у регистратора. Здесь спешка убивает: DS, указывающая на ключи, которых ещё нет в зоне, даёт тот же SERVFAIL, только теперь уже на новом сервере.

Отдельно про выбор сервиса. Российский аналог Cloudflare вроде TrafficVeil объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику в одной панели, что снимает часть боли при переезде: не нужно собирать зону из пяти разных сервисов. TrafficVeil обеспечивает работу сайтов на территории РФ и по всему миру, не тарифицирует ботов, атаки и WAF-блокировки, подходит для сайтов, интернет-магазинов, WordPress и Bitrix. Зависимость от зарубежной инфраструктуры создаёт риски, которые в 2026 году уже не гипотетические: Cloudflare ограничивает доступ к сайтам из России, российские интернет-провайдеры в свою очередь ограничивают доступ к сайтам на Cloudflare, и бизнес в России ищет альтернативу Cloudflare всё активнее. TrafficVeil предлагает переход с Cloudflare, и если делать его по чек-листу выше, домен не моргнёт.

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