Що буде з вашим сайтом, якщо ляже дата-центр: як ми переносили DNS і що перевірити у себе за 10 хвилин

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Удари по енергетиці й дата-центрах змушують по-новому подивитися на просте питання: де фізично живе ваш сайт і що зупиниться разом із ним. Ми в студії поставили це питання спершу собі й сьогодні перенесли DNS власного домену olbo.com.ua на інший сервіс. Нижче — що ми перевіряли, де можна зламати пошту й сайт за одну хвилину і що варто зробити кожній компанії.

Що насправді падає разом із дата-центром

Сайт — це не одна річ, а кілька незалежних шарів, і часто всі вони лежать в одному місці:

— DNS — «телефонна книга», яка каже браузерам і поштовим серверам, куди звертатися. Якщо DNS обслуговує той самий провайдер, що й хостинг, то з падінням дата-центру зникає не лише сайт, а й домен як такий: перестає ходити пошта, ламаються перевірки в Google, сервіси розсилок і все, що прив’язано до домену.
— Хостинг — сервер, на якому працює сайт і форми заявок.
— Пошта — якщо вона на тому самому хостингу, листи від клієнтів і партнерів не просто затримуються, а можуть повертатися відправникам як недоставлені.
— Резервні копії — якщо вони зберігаються в тому ж дата-центрі, їх немає.

Найчастіша картина, яку ми бачимо: домен, DNS, сайт, пошта й бекапи — в одного провайдера, в одній будівлі. Одна точка відмови на все.

Принцип: розвести шари

Ідея не в тому, щоб знайти «найнадійніший хостинг», а в тому, щоб падіння одного шару не тягнуло за собою інші:

— DNS — окремо від хостингу, у сервісі з розподіленою мережею серверів у багатьох країнах (anycast). Тоді навіть якщо сайт недоступний, пошта працює, а домен можна за хвилини спрямувати на резервну копію.
— Сайт — на платформі, яка роздає сторінки з багатьох точок світу, або принаймні з готовою копією в іншому місці.
— Пошта — у спеціалізованого поштового провайдера, не на хостингу.
— Бекапи — в іншому місці, ніж сайт, і з перевіреним відновленням. Бекап, який ніхто жодного разу не розгортав, — це припущення, а не бекап.

Наш кейс: перенесення DNS за годину

DNS olbo.com.ua обслуговував сервіс при реєстраторі. Сайт уже працював на розподіленій платформі, пошта — в окремого провайдера, тож слабким місцем лишався саме DNS. Ми перенесли його на Cloudflare (безкоштовний тариф). Кроки й пастки:

1. Спершу — повний список записів. У нас їх було 14: адреса сайту, піддомени, три поштові MX, SPF, DKIM, DMARC, записи перевірки для Google і пошти, записи сервісу розсилки листів. Ми вивантажили їх файлом і звірили вручну. Автоматичний імпорт у новому сервісі щось підхоплює, а щось ні, і пропущений запис виявиться тоді, коли вже не дійде лист.
2. Довгі записи DKIM — найчастіше місце помилки. Вони довгі, і при копіюванні легко обрізати кінець. Обрізаний DKIM не видно одразу: листи просто почнуть потрапляти в спам.
3. Запис перевірки Google Search Console. Якщо ресурс підтверджено через DNS, а TXT-запис загубиться при перенесенні, ви втратите доступ до статистики пошуку.
4. Проксі — вимкнено. Cloudflare за замовчуванням пропонує пропускати трафік через свої сервери. Для нашого сайту це шкодить: платформа хостингу не рекомендує ставити проксі поверх себе, а записи пошти й сервісу розсилки проксувати не можна взагалі. Усі записи в нас у режимі «лише DNS».
5. DNSSEC. Якщо в реєстратора ввімкнено DNSSEC, зміна DNS-серверів без попереднього вимкнення «кладе» домен повністю. Порядок такий: спершу вимикаєте DNSSEC, потім переносите, а вмикати знову — спершу в новому сервісі, потім у реєстратора.
6. Зміна DNS-серверів у реєстратора — один рядок. Після цього починається поширення: Cloudflare 1.1.1.1 побачив нові записи вже за пів години, а Google 8.8.8.8 ще тримав старі з кешу. Повне поширення може тривати до доби-двох, тому ми не видаляли старі записи в попередньому сервісі — вони лишаються на тиждень як страховка.
7. Відкат — теж один рядок: повернути в реєстратора попередні DNS-сервери.
8. Двофакторний вхід в акаунт. Той, хто керує DNS, керує і сайтом, і поштою. Акаунт без 2FA — найслабша ланка всієї схеми. І він має бути оформлений на компанію, а не на особисту пошту підрядника.

Чесно про обмеження

Cloudflare — не панацея. Це теж одна компанія, і в неї бувають глобальні збої: масштабний стався в листопаді 2025 року. Ми переносимо ризик туди, де він значно менший, але не прибираємо його повністю.

Є й компанії, яким такий шлях не підходить: ті, для кого закон чи регулятор вимагає зберігати дані в Україні або в конкретній інфраструктурі. Для них рішення інше — резервний майданчик в іншому регіоні країни, а не за кордоном. Це питання варто спершу розібрати з юристом і безпековиком.

Що перевірити на своєму сайті сьогодні

— Хто обслуговує ваш DNS. У Windows: nslookup -type=ns вашдомен.ua. Якщо у відповіді той самий провайдер, що й хостинг, — у вас одна точка відмови.
— Де ваша пошта: nslookup -type=mx вашдомен.ua. Якщо MX веде на ваш хостинг — пошта впаде разом із сайтом.
— На кого зареєстровано домен, коли спливає оплата і чи ввімкнене автопродовження.
— Чи є двофакторний вхід у реєстратора, хостинг і DNS-сервіс.
— Де лежать бекапи і коли їх востаннє відновлювали для перевірки.
— Чи є в когось із команди записаний план: що робимо, якщо сайт недоступний більше години.

Буду радий обговорити в коментарях: як ви розводите інфраструктуру і чи був у вас досвід переїзду під час відключень.