Cloudflare DNS: как подключить домен без простоя

Подключение Cloudflare DNS состоит из двух разных действий. Сначала вы копируете DNS-зону — список записей домена — в Cloudflare. Затем у регистратора меняете NS-серверы, то есть адреса службы, у которой интернет спрашивает эти записи. Если новая зона заранее повторяет рабочую, сайт и почта продолжат отвечать во время перехода.

Самая частая причина простоя — не скорость обновления DNS, а пропущенная запись. Автоматический импорт помогает начать, но не освобождает от ручной сверки.

Что изменится, а что останется прежним

Регистратор по-прежнему хранит право на домен и принимает оплату за продление. Хостинг также не переезжает сам по себе. Cloudflare становится авторитетной DNS-службой: после смены NS именно она сообщает браузерам IP-адрес сайта, а почтовым серверам — адрес почтового узла.

У записей сайта появится дополнительный выбор:

• Proxied — веб-запрос идёт через сеть Cloudflare, а посетитель получает адреса Cloudflare;
• DNS only — Cloudflare только отвечает на DNS-запрос, после чего посетитель соединяется с вашим сервером напрямую.

Proxy поддерживается не для любых протоколов. Записи MX, TXT и почтовые имена оставляют в режиме DNS only. Проверочные CNAME-записи, которые выдал другой сервис, также обычно должны отвечать своим исходным значением.

Снимите копию действующей зоны

Откройте DNS-панель текущего провайдера и сохраните список записей. Если панель умеет экспортировать зону, скачайте файл, но дополнительно сделайте снимок экрана: формат экспорта может не включать служебные настройки.

Отметьте как минимум:

• A и AAAA для корневого домена и поддоменов;
• CNAME для www и внешних сервисов;
• MX для входящей почты;
• TXT со SPF, DKIM, DMARC и подтверждениями владения;
• отдельные поддомены панелей, API, файлового хранилища и почты.

Если непонятно, чем отличаются A, AAAA и CNAME, сначала прочитайте разбор основных DNS-записей. Важно сверять не только имя и значение, но и тип записи. TXT со значением почтовой политики нельзя заменить похожим CNAME.

Добавьте домен и проверьте импорт

В панели Cloudflare выберите добавление сайта, введите домен без https:// и пути, затем выберите подходящий план. Сервис попробует найти публичные записи и покажет подготовленную зону.

Сравните её строка за строкой с сохранённым списком. Недостающие записи создайте вручную. Если в старой панели имя корневой записи показано как @, в Cloudflare оно будет отображаться как сам домен — это одно и то же место зоны.

На первом проходе разумно оставить веб-записи в режиме DNS only. Так вы меняете только DNS-провайдера и не добавляете в ту же минуту ещё один источник возможной ошибки. Когда зона станет активной и сайт пройдёт проверку, proxy можно включить отдельно.

Не удаляйте старую DNS-зону. Она понадобится, пока разные резолверы — DNS-серверы провайдеров и организаций — ещё используют прежнее делегирование.

Разберитесь с DNSSEC до смены NS

DNSSEC позволяет проверять цифровую подпись DNS-ответа. Регистратор хранит DS-запись — ссылку на ключ, которым должна быть подписана зона. Если DS относится к старому провайдеру, а NS уже указывают на Cloudflare, проверяющий резолвер сочтёт ответы недостоверными. Для посетителя это выглядит как полностью неработающий домен.

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

dig DS example.com +short

Замените example.com своим доменом. Команда только читает DNS и ничего не меняет. Пустой вывод означает, что публичной DS-записи сейчас нет; строка с числами и длинным хешем означает, что она ещё опубликована. После активации зоны Cloudflare DNSSEC можно включить заново и добавить выданные ею данные у регистратора. Подробный порядок разобран в статье о DNSSEC для домена.

Смените NS у регистратора

Cloudflare назначит домену два NS-имени. Скопируйте их без изменений в поле «DNS-серверы» или «Серверы имён» у регистратора. Удалите прежние NS: одновременное указание серверов разных провайдеров не создаёт резервирование, а приводит к непредсказуемым ответам.

Меняется именно делегирование домена, а не NS-записи внутри обычного редактора зоны. Если интерфейс регистратора показывает оба варианта, используйте настройку серверов имён домена. Подробнее эта связь объяснена в материале о NS и делегировании.

Cloudflare указывает срок до 24 часов на обнаружение изменения. В это время не редактируйте старую и новую зоны по-разному. Если срочно нужна новая запись, временно добавьте одинаковую запись в обе панели.

Проверьте делегирование и сервисы

Проверку выполняйте не только по открывшейся главной странице. Сначала узнайте, какие NS видны через публичный DNS:

dig NS example.com +short
dig A example.com +short
dig MX example.com +short

Первая команда должна показать два NS, назначенных Cloudflare. Вторая — ожидаемые адреса сайта; при включённом proxy это будут адреса Cloudflare, а в режиме DNS only — адрес вашего сервера. Третья должна вернуть почтовые серверы. dig не доказывает, что веб-сервер и почта работают, поэтому после DNS-проверки откройте сайт, отправьте тестовое письмо на домен и ответьте с него.

На Windows без dig можно начать с nslookup -type=ns example.com, но для полного сравнения записей удобнее установить DNS-утилиты или воспользоваться отдельной диагностической машиной. В руководстве по dig и nslookup показано, как спрашивать конкретный DNS-сервер и отличать кеш от ошибки зоны.

Включайте proxy по одной записи

После статуса Active включите proxy для корневого веб-домена и www, если оба обслуживают HTTP или HTTPS. Сразу проверьте:

1. открытие по HTTPS;
2. перенаправление между www и адресом без www, если оно настроено;
3. отправку форм и вход в административную часть;
4. журнал веб-сервера и отсутствие новых ошибок TLS.

Не включайте proxy для mail, smtp, imap, FTP, SSH и произвольных TCP-сервисов в расчёте, что оранжевое облако защитит любой порт. Обычный proxy Cloudflare предназначен прежде всего для поддерживаемого веб-трафика; доступность других продуктов и портов зависит от отдельной услуги и её условий.

Когда proxy включён, исходный IP сервера всё ещё может быть известен из старых записей, почтовой конфигурации или других поддоменов. Не считайте скрытый адрес заменой firewall, обновлениям и защите панели управления.

Если после переключения домен не работает

Проверяйте причины в порядке, который не смешивает несколько изменений:

Симптом	Что проверить
Cloudflare долго показывает Pending	у регистратора указаны ровно назначенные два NS
SERVFAIL только у проверяющих DNSSEC-серверов	старая DS-запись не удалена или новые данные DNSSEC внесены неверно
сайт открывается, почта нет	MX и связанные TXT-записи перенесены полностью
открывается старый сервер	значение A/AAAA, локальный DNS-кеш и фактические NS
после включения proxy ошибка TLS	сертификат и HTTPS на исходном сервере, режим шифрования в Cloudflare
один поддомен работает, другой нет	запись поддомена существует и имеет верный тип

Если ошибка появилась сразу после включения proxy, верните конкретную запись в DNS only и повторите проверку. Это не отменяет перенос DNS: Cloudflare продолжит обслуживать зону, но веб-трафик снова пойдёт прямо на сервер.

Полный возврат к прежнему DNS-провайдеру нужен редко. Для него восстановите старые NS у регистратора и убедитесь, что прежняя зона всё ещё содержит актуальные записи. Не удаляйте зону Cloudflare до завершения обратного перехода.

Источники

• Cloudflare: подключение домена в режиме full setup
• Cloudflare: статус proxy для DNS-записей
• Cloudflare: устранение ошибок full setup