Міграція DNS та пошти доменів на Cloudflare з DNSSEC, SPF/DKIM/DMARC та нульовим простоєм

Вихідна ситуація: є 18 доменів (10. com, 6. ru, 2. io) у двох реєстраторів. DNS зараз на старому хостингу (BIND), частина зон ведеться вручну, частина – через панель. Пошта - Microsoft 365 для 2 доменів та Google Workspace для інших. Для шести доменів використовуються піддомени клієнтів і делегування NS на зовнішні системи. Періодично трапляються простої через помилки в зонах і неконсистентних TTL. Мета – перевести авторитетний DNS на Cloudflare, увімкнути DNSSEC, привести поштову автентифікацію до єдиного стандарту та налаштувати моніторинг змін.

Технічне середовище та обмеження: доступ до реєстраторів по облікових записах замовника, доступ до поточного DNS-експорту BIND та до панелей M365/GWS буде надано. Не можна змінювати IP-адреси веб-сервісів та поштових провайдерів. Не можна переривати доставку пошти, критично зберегти всі MX, TXT (SPF), DKIM селектори та існуючі записи валідації. Вікно робіт – будні 20:00-01:00 UTC+3. Для 4 доменів не можна включати проксіювання через Cloudflare для A/AAAA, тільки DNS-only. Потрібний облік особливостей .ru по DNSSEC та DS-записам у реєстратора.

Завдання по етапам:
1) Інвентаризація та аудит поточних зон - зібрати фактичні записи з BIND/панелі, виявити розбіжності, оцінити поточні TTL, знайти застарілі записи, зрозуміти ланцюжки делегування піддоменів та зони зі split-horizon (якщо є).
2) Проектування цільової схеми DNS в Cloudflare - шаблонні налаштування, правила іменування, TTL-політика, де допустимо proxy, де суворо DNS-only, підготовка списку зон та власників.
3) Поштова частина - нормалізувати SPF без перевищення 10 DNS lookup, налаштувати/перевірити DKIM для кожного домену (для M365 та GWS), сформувати DMARC з поетапним посиленням політики та звітами (rua/ruf), врахувати піддомени, які надсилають пошту.
4) Включення DNSSEC – включити в Cloudflare, коректно підготувати DS для кожного реєстратора, виконати публікацію DS та перевірити ланцюжок довіри.
5) Міграція з нульовим простоєм - попередньо знизити TTL, синхронно перенести записи, виконати перемикання NS у реєстраторів, контролювати поширення, план відкату на випадок проблем.
6) Моніторинг та контроль змін - налаштувати базовий моніторинг DNS та поштових записів (наприклад, через DNSControl/Git, Cloudflare API та періодичні перевірки), включити повідомлення про зміни зон, підготувати коротку інструкцію для подальшого супроводу.

Конкретний результат: усі 18 доменів обслуговуються Cloudflare як авторитетний DNS, DNSSEC включений та валіден, пошта доставляється без деградації, SPF/DKIM/DMARC налаштовані та перевірені, делегування піддоменів збережено, впроваджено контроль змін зон через репозиторій та автоматичну перевірку.

Вимірні критерії приймання:
- Для кожного домену: коректні NS у реєстратора та збіг набору критичних записів (A/AAAA/CNAME/MX/TXT/SRV/CAA) з вихідним станом, крім заздалегідь узгоджених чисток.
- DNSSEC: перевірка через незалежні валідатори показує статус OK, ланцюжок довіри будується (DS опубліковано), немає SERVFAIL за основними резолверами.
- Пошта: для кожного домену успішна перевірка SPF, DKIM, DMARC (pass) на тестових листах, DMARC-звіти починають надходити на вказану адресу, SPF не перевищує ліміти.
- Делегування: піддомени із зовнішніми NS продовжують резолвуватися так само, як до міграції, без зміни target NS.
- Час недоступності DNS/пошти - 0 хвилин за даними моніторингу (допускаються лише зміни TTL та поширення NS без втрати резолву).

Артефакти: файл(и) зон/конфігурацій (наприклад, DNSControl/terraform для Cloudflare або експорт через API), таблиця відповідності записів до/після, список DS за доменом, коротка експлуатаційна інструкція та чекіст відкату.