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, доставка листів порушується.