DNS-менеджер Cloudflare — мощный инструмент с интуитивным интерфейсом. Изменения DNS применяются мгновенно в сети Cloudflare, что намного быстрее традиционных регистраторов.
Режимы DNS-записей
Proxied (оранжевое облако ☁️)
- Трафик проходит через Cloudflare CDN
- Реальный IP скрыт
- Работают: CDN, DDoS-защита, WAF, оптимизация
- Подходит для: A, AAAA, CNAME на веб-серверы
DNS Only (серое облако ⛅)
- Cloudflare только резолвит DNS, трафик идёт напрямую
- Реальный IP виден
- Нет CDN и защиты
- Обязательно для: MX, SPF, DKIM, FTP, SSH записей
Добавление DNS-записей
| Тип | Пример использования | Proxy? |
|---|---|---|
| A | @ → 192.168.1.1 (основной сайт) | ✅ Да |
| CNAME | www → example.com | ✅ Да |
| MX | @ → mail.example.com (почта) | ❌ Нет |
| TXT | @ → v=spf1... (SPF) | ❌ Нет |
| TXT | mail._domainkey → (DKIM) | ❌ Нет |
| CNAME | ftp → сервер FTP | ❌ Нет |
TTL в Cloudflare
Для Proxied записей TTL автоматически устанавливается на Auto (300 секунд). Для DNS Only можно выбрать от 1 минуты до 24 часов.
Проверка DNS-записей
# Проверить A-запись через Cloudflare DNS
dig @1.1.1.1 example.com A
# Проверить MX
dig @1.1.1.1 example.com MX
# Проверить что Proxy работает (должен вернуть IP Cloudflare, не ваш)
dig example.com ACNAME на корневом домене (CNAME Flattening)
Стандарт DNS запрещает CNAME-запись на apex-домене (example.com без поддомена) наравне с другими записями. Cloudflare обходит это ограничение автоматически: если создать CNAME на @, Cloudflare на уровне своих серверов «разворачивает» её в A/AAAA-записи целевого хоста. Это удобно для интеграции с сервисами вроде Vercel или Netlify, которые выдают только CNAME-адрес.
Разбор ошибок DNS
Error 1000: DNS points to prohibited IP
Cloudflare блокирует создание Proxied-записи, которая указывает на приватный (10.0.0.0/8, 192.168.0.0/16) или зарезервированный диапазон IP-адресов. Решение — использовать реальный публичный IP сервера или переключить запись в режим DNS Only, если она используется только для внутренней сети.
Error 1001: DNS resolution error
Возникает, когда Proxied-запись указывает на хост, который сам не резолвится (например, CNAME на несуществующий поддомен). Проверьте цепочку записей от корня и убедитесь, что конечная запись — рабочий A/AAAA-адрес.
Домен не резолвится вообще
Если после смены NS-серверов домен не отвечает больше 24 часов — проверьте у регистратора, что NS-записи сохранены именно в формате, который выдал Cloudflare (без опечаток, без лишних точек), и что регистратор не блокирует смену NS до истечения какого-то периода после покупки домена. Сам процесс подключения описан в статье про добавление сайта в Cloudflare.
Проверка результата
# Убедиться что домен использует NS Cloudflare
dig example.com NS +short
# Сравнить ответ напрямую с сервера Cloudflare и публичного резолвера
dig @1.1.1.1 example.com A +short
dig @8.8.8.8 example.com A +short
# Оба должны вернуть одинаковый результат после полного распространенияКогда DNS-менеджер Cloudflare не подходит
- Нужен DNSSEC с ключами, которыми управляет сторонний регистратор без поддержки делегирования на Cloudflare — придётся либо переносить домен, либо отключать DNSSEC на время.
- Нужны экзотические типы записей, которые Cloudflare не поддерживает в бесплатном плане (например, некоторые расширенные форматы для внутренних DNS-серверов).
- Для почтовых записей (MX, SPF, DKIM) нужна отдельная маршрутизация писем — см. статью про Email Routing в Cloudflare, если хотите принимать почту без отдельного почтового сервера.
Cloudflare поддерживает Secondary DNS: можно оставить основной DNS-сервер у себя (например, для внутренней инфраструктуры) и настроить одностороннюю передачу зоны через AXFR на Cloudflare как вторичный сервер — тогда изменения делаются на исходном сервере, а Cloudflare только раздаёт копию по всему миру.
Для MX-записи в Cloudflare указывается отдельное поле Priority (меньшее число — более приоритетный сервер). Если почта резервируется через несколько MX, второй сервер должен иметь больший приоритет (например, 10 и 20), иначе оба будут считаться равнозначными и почта может теряться при недоступности одного из них.
Глобальное распространение изменений удобно проверять через сторонние сервисы вроде whatsmydns.net — они показывают ответ DNS сразу из нескольких десятков точек мира, и наглядно видно, где обновление уже применилось, а где ещё отдаёт старое значение.
Частые вопросы
Почему режим Proxied может сломать доступ по SSH или FTP к серверу?
В режиме Proxied трафик идёт через сеть Cloudflare, а не прямо на сервер, и Cloudflare проксирует только веб-протоколы HTTP и HTTPS. SSH, FTP и другие нестандартные порты через Proxied просто не проходят, поэтому такие записи обязательно переводят в режим DNS Only — тогда запрос идёт напрямую на реальный IP сервера, минуя сеть Cloudflare целиком.
Нужно ли ждать распространения DNS при переключении записи между Proxied и DNS Only?
Переключение облака в Cloudflare применяется мгновенно внутри сети самого Cloudflare, без обычного ожидания распространения DNS по миру. Однако кэш у конечных пользователей и промежуточных резолверов может хранить старый ответ до истечения TTL записи, поэтому эффект иногда ощущается не сразу, хотя сама настройка на стороне Cloudflare меняется без задержки.
Что такое Secondary DNS в Cloudflare и когда он нужен?
Secondary DNS позволяет оставить основной DNS-сервер на своей инфраструктуре, а Cloudflare использовать только как вторичный узел, который раздаёт копию зоны по всему миру через одностороннюю передачу AXFR. Такой режим подходит, когда изменения записей должны делаться на внутреннем сервере по корпоративным причинам, а не через панель Cloudflare.
Почему почта может не доходить, хотя MX-запись в Cloudflare настроена правильно?
Частая причина — неверный приоритет резервных MX-записей: если у основного и резервного сервера указано одинаковое значение Priority, они считаются равнозначными, и письма могут маршрутизироваться на недоступный сервер. Также почтовые записи обязаны работать в режиме DNS Only — если MX или SPF случайно включены как Proxied, доставка писем нарушается.