Налаштування 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 і панель реєстратора; токени передавайте через менеджер секретів, а не в листуванні.
- Хто з боку замовника приймає результат і залишається на зв'язку, якщо потрібно повернути попередні налаштування.
У відповідь надсилаємо план робіт за етапами, оцінку термінів, склад команди з ролями та перелік доступів, які знадобляться на кожному кроці. Якщо за підсумками розбору виявиться, що частину зони безпечніше залишити як є, скажемо про це прямо.
