Настройка DNS Cloudflare: что ломается при переносе зон
Перенос зоны в Cloudflare выглядит как копирование списка записей — на деле ломается связка между содержимым зоны и делегированием. Часть записей не попадает в новый набор: типично теряются MX, служебные TXT и записи поддоменов, о которых помнил только прежний администратор. Старый TTL держит у провайдеров прежние адреса, новый серийный номер зоны ещё не разошёлся по кэшам — и разные пользователи получают разные ответы на один и тот же запрос.
Отдельная история — ошибки делегирования. Если у регистратора переключить NS раньше, чем зона отдаётся авторитативно, адреса указывают на сервер, где данных ещё нет, и сбой разрешения имён выглядит как недоступность домена при формально «правильных» настройках. Рядом стоит DNSSEC-ловушка: DS-запись осталась от прежней зоны, подписи не сходятся, и сайт перестаёт открываться даже там, где кэш ещё отдавал корректный адрес.
Цена такого сбоя — простой сервиса, а не неудобство: не работает почта, вход в личный кабинет, оплата и обмен данными с внешними системами. Неполный сбой хуже полного: часть клиентов обслуживается, часть нет, и в журналах это выглядит как случайные отказы без общей причины.
Настройка DNS через Cloudflare снимает большую часть этих рисков, если выверен порядок шагов. Сначала выгружаем и сверяем полный набор записей, затем готовим зону и проверяем ответы с разных точек, только потом переключаем делегирование, а дальнейшие изменения ведём конфигурацией, а не руками в панели. Разбираем, как это закрывается.
Что даёт управляемая зона: скорость отклика и меньше отказов
Управляемая зона — это когда состояние DNS описано конфигурацией, а не живёт в памяти администратора и не правится руками в панели. Каждое изменение проходит проверку: видно, что именно поменялось и зачем, а откат возвращает предыдущее состояние зоны целиком. Ручные правки, из-за которых зона расходится с реальной инфраструктурой, уходят как класс — это и есть основной эффект от настройки DNS в Cloudflare через описание зоны.
Отклик разрешения имён держится на распределённой сети: ответ отдаёт ближайший к пользователю узел Cloudflare, а не один сервер в одном регионе. Кеширование настраивается осознанно — короткий TTL на записях, которые участвуют в переключениях, и длинный на статичных вроде MX. Переключение сервиса между площадками укладывается в минуты, а не в часы ожидания, пока истечёт кеш у провайдеров.
Что меняется в измеримом виде: время переключения записи — минуты; доля правок, сделанных руками, — ноль; класс ушедших отказов — забытая запись после переезда, тестовый хост, оставшийся в рабочем контуре, конфликт двух администраторов, менявших зону одновременно. Зону подписывают DNSSEC, ключи ротируются по регламенту, поэтому подмена ответа резолвера перестаёт быть сценарием, о котором узнают из жалоб.
Доступность сервиса перестаёт зависеть от того, помнит ли кто-то про конкретную запись. Зона живёт рядом с кодом инфраструктуры: изменение приходит вместе с остальными ресурсами, а не отдельной задачей в чужой очереди.
Способы управления зоной Cloudflare: панель, шаблоны, свой сервер
Управляемая зона на стороне провайдера, свои серверы имён или комбинация обоих — выбор определяется тем, кто и как часто меняет записи, сколько зон в контуре и нужен ли полный контроль над делегированием. Ниже — четыре режима, которые встречаются на практике, с их применимостью и ограничениями.
Все они совместимы между собой: делегирование переключается по каждому домену отдельно, а записи при этом могут жить в шаблонах конфигурации. Задача — заранее понять, где заканчивается полнота управления и начинается ручная работа, которая накапливает расхождения.
| Режим | Когда подходит | Ограничения |
|---|---|---|
| Панель управления | Разовые переносы, одна-две зоны, изменения редки | Правки не воспроизводимы, нет истории и ревью, при росте зон появляются расхождения |
| Шаблоны конфигурации (Terraform) | Десятки зон, несколько сред, нужны повторяемость и ревью изменений | Требуется хранилище состояния и программный доступ, часть сущностей описывается неполно |
| Свои серверы имён | Свои требования к хранению данных, нестандартные сценарии, нужен полный контроль | Обслуживание, отказоустойчивость и обновления зон ложатся на вашу команду |
| Гибридная схема | Основной контур в шаблонах, отдельные домены — на своих серверах имён | Синхронизация делегирования и контроль расхождений записей между контурами |
На практике большинство команд приходит к гибридной схеме: зона остаётся в управляемом контуре с шаблонами и историей изменений, а домены со своими серверами имён подключаются точечно. Мы описываем такую схему до начала работ — вместе с порядком отката делегирования.
Этапы переноса зоны: аудит, схема, правки, проверка
От инвентаризации до сопровождения — шесть шагов, которые выполняем в фиксированном порядке. Ключевое правило: новая зона полностью готова и проверена до того, как меняются NS-записи у регистратора, поэтому в любой момент есть куда вернуться.
- Аудит записей. Выгружаем текущую зону целиком, сверяем с фактическим трафиком: какие имена реально отвечают, где висят дубли и длинные CNAME-цепочки, у каких записей завышен TTL. Мёртвые записи помечаем — часть из них обнаруживается только по логам резолверов.
- Схема зоны. Собираем целевую структуру: делегирование поддоменов, почтовые записи, служебные и проверочные имена. Схема согласуется до правок — потом менять её дороже.
- Подготовка целевой зоны. Заводим зону в Cloudflare, переносим записи по схеме, описываем состояние конфигурацией, чтобы изменения шли через ревью, а не руками в панели. DNSSEC настраиваем, но не активируем до делегирования.
- Проверка на тестовом контуре. Прогоняем имена через независимые резолверы, проверяем ответы для почты и внутренних сервисов, сверяем набор записей с аудитом.
- Переключение и проверка делегирования. TTL снижаем заранее, меняем NS у регистратора и подтверждаем делегирование с внешних точек. Отдельно проверяем цепочку подписи DNSSEC — ошибка здесь ломает разрешение имён целиком.
- План отката. Сохраняем копию исходной зоны и прежние NS: возврат занимает минуты и не требует восстановления из бэкапа.
- Передача в сопровождение. Отдаём репозиторий с описанием зоны, доступы, регламент изменений и мониторинг отказов разрешения имён.
Что передаём на руки: конфигурации зоны и регламенты
Передаём не доступ к панели управления, а саму зону и правила, по которым её меняют без нас. Комплект рассчитан так, чтобы новый инженер в команде заказчика мог разобраться в конфигурации и внести правку, не заглядывая в историю переписки.
- Схема зоны — карта доменов и поддоменов с указанием, где зона обслуживается, какие записи отданы внешнему провайдеру, а какие живут на собственных серверах, и как проходит делегирование.
- Матрица записей — таблица по каждому типу (A, AAAA, CNAME, MX, TXT, CAA, SRV): назначение, ответственный, время жизни, признак «меняется только через репозиторий».
- Описание конфигурации как кода — какие записи объявлены декларативно, что импортировано из существующей зоны, где хранится состояние, как запускается проверка плана перед применением.
- Роли доступа и ключи — разделение прав на чтение и изменение, ограничение токенов по конкретным зонам, порядок ротации, отдельная учётная запись для автоматизации вместо общих логинов.
- Порядок работы с DNSSEC — где лежат ключи подписи, как публикуется запись делегирования у регистратора, что делать при ротации и как снять подпись, если цепочка сломалась.
- Регламент изменений — заявка, проверка на тестовой зоне, план применения, окно работ, точка отката и список тех, кто согласует правку.
- Инструкции для команды — разбор типовых задач, диагностика распространения записей, снятие блокировки, куда смотреть при расхождении между репозиторием и живой зоной.
Приёмка идёт по прогону: изменение применяется на тестовой зоне, проверяется цепочка подписи и разрешение имён из нескольких точек, затем фиксируется расхождение между репозиторием и рабочей зоной. После этого конфигурации остаются у вас как рабочий документ — с ними зону можно развивать своими силами или отдать другому подрядчику без пересборки.
Кейс: перенос сорока зон без простоя сервисов
Точка отсчёта
Парк из сорока зон жил в веб-панели и правился руками: записи добавляли напрямую, история изменений не сохранялась, а причину сломанного маршрута восстанавливали по переписке. TTL стоял на сутках, поэтому переключение на резервный узел растягивалось до 24 часов — часть клиентов продолжала идти на неработающий адрес. За квартал набралось семь инцидентов, пять из них — опечатки в NS- и CNAME-записях, которые никто не проверял до публикации.
Что изменили и что получили
Зоны описали декларативно: модуль на каждую зону, состояние в удалённом хранилище с блокировкой, любое изменение — только через ревью. На время миграции понизили TTL до 300 секунд, включили DNSSEC и опубликовали DS-запись у регистратора. Перед сменой NS-серверов снимали полный дамп зоны и сверяли с эталоном: расхождение по любой записи блокировало переключение.
Метрики после переноса: время переключения записи — с суток до пяти минут, откат — возврат предыдущего состояния за минуту, доля изменений, прошедших автоматическую проверку, — сто процентов. Проверка после миграции идёт обходом всех зон: ответы авторитетных серверов сверяются с конфигурацией, ложных срабатываний DNSSEC нет. Отказов, вызванных ручной правкой, — ноль за всё время эксплуатации.
Чем управляемая зона отличается от своего сервера
Управляемая зона — это когда авторитетные серверы имён живут в сети провайдера, а вам остаётся содержимое зоны. Свой сервер означает, что вы держите сам сервис: обновления, отказоустойчивость, защиту от всплесков и ротацию ключей.
На практике выбирают между тремя схемами — они отличаются тем, кто отвечает за отклик во время сбоя и сколько людей нужно держать на сопровождении.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Управляемая зона | Нужны отказоустойчивость из коробки, DNSSEC и API для автоматизации | Часть настроек ядра закрыта, изменения идут через провайдера |
| Свой сервер имён | Нужны нестандартные ответы и полный контроль над зоной | Доступность, защита от нагрузки и обновления — на вашей команде |
| Гибрид: свой источник зоны и внешний сервер | Нужен контроль над содержимым плюс внешний резерв | Требуются зонные трансферы и контроль расхождений реплик |
С масштабированием проще у управляемой зоны: запросы размазываются по сети точек присутствия, и рост числа запросов почти не меняет время ответа. Свой сервер требует расчёта — сколько запросов в секунду держит инстанс, есть ли второй узел в другой сети и как сервис поведёт себя под отражённой атакой.
От команды управляемая зона тоже требует работы: записи, TTL и цепочку DNSSEC с ротацией ключей нужно вести как код, через Terraform и ревью правок, а не руками в панели. Свой сервер добавляет обновления пакетов, мониторинг ответов с внешних точек и контроль совпадения реплики с источником. Границы стоит зафиксировать письменно: ошибка в значении записи роняет сервис одинаково в обеих схемах — разница лишь в том, кто дежурит.
Технические сомнения: делегирование, DNSSEC, откат
Перенос зоны упирается в три вопроса: как пройдёт делегирование домена, что будет с защитой от подмены ответов и как вернуть всё назад. Ниже — ответы, которые чаще всего нужны инженеру до старта работ.
Как пройдёт делегирование и не будет ли простоя?
Сначала зона наполняется записями на стороне Cloudflare, и только потом у регистратора меняются NS. Пока кэши не остыли, часть запросов идёт на старые серверы, поэтому обе зоны держим синхронными. Сроки переключения — от нескольких часов до двух суток, и это видно по логам, а не «на глаз».
Что даёт DNSSEC и не сломает ли он домен?
DNSSEC — это защита от подмены ответов: зона подписывается, у регистратора публикуется DS-запись. Порядок принципиален — сначала проверяем валидацию на публичных резолверах, потом фиксируем цепочку; ошибочная DS делает домен недоступным для части пользователей.
Останутся ли резервные копии зоны?
Перед каждым изменением делаем экспорт зоны и храним историю версий в репозитории. Резервные копии зоны лежат вне панели провайдера — восстановление не зависит от доступа в аккаунт, предыдущее состояние поднимается даже спустя месяцы.
Как устроен откат изменений?
Конфигурация описана декларативно, поэтому откат — возврат предыдущей версии и повторное применение, а не ручная правка записей. После сверяем отдачу по контрольным именам и ждём расхождения кэша: операция занимает минуты, а не часы.
Обсудим вашу задачу: с чего начнём
Чтобы обсудить задачу предметно, достаточно описать её своими словами и приложить то, что уже есть под рукой. Дальше мы разберём текущее состояние зоны, зададим уточняющие вопросы и вернёмся с оценкой сроков и планом работ по этапам.
- Домен и регистратор: где делегированы зоны, кто владеет аккаунтом и может менять NS-записи.
- Экспорт текущей зоны: критичные поддомены, почтовые записи, сервисы, которые проверяют домен по TXT-записям.
- Что уже автоматизировано, а что правят руками, — от этого зависит объём перевода зоны на шаблоны Terraform.
- Известные проблемы: были ли отказы разрешения имён, жалобы на почту, ручные правки в нерабочее время.
- Ограничения: окно переноса, допустимое время недоступности сервисов, кто подтверждает переключение и откат.
- Доступы и данные: права на зону в Cloudflare и панель регистратора; токены передавайте через менеджер секретов, а не в переписке.
- Кто со стороны заказчика принимает результат и остаётся на связи, если потребуется вернуть прежние настройки.
В ответ присылаем план работ по этапам, оценку сроков, состав команды с ролями и перечень доступов, которые понадобятся на каждом шаге. Если по итогам разбора окажется, что часть зоны безопаснее оставить как есть, скажем об этом прямо.
