Yandex Cloud DNS: налаштування — де ламається розв'язання імен
Збій розв'язання імен рідко виглядає як повна відмова: сервіс не знаходить сусідній, випуск сертифіката зависає на перевірці домену, застосунок іде на резервний вузол, а за десять хвилин усе працює саме собою.
Логи застосунку при цьому чисті — ім'я розв'язалося, але не туди, куди очікувалося, і до цього місця зазвичай доходить уже після нічного розбору.
Найчастіше причина — в одній із чотирьох точок. Застарілі та дубльовані записи залишаються від ручних правок у панелі: адреса на знятий вузол, два записи на одне ім'я з різними значеннями, забутий перевірочний запис, який блокує випуск сертифіката.
Друга точка — неправильна зона: домен випадково описано в публічній зоні замість приватної, або приватна зона перекриває зовнішні імена всередині мережі, і внутрішні сервіси починають ходити не туди.
Третя точка — кеш відповідей. Поки TTL завищений, клієнти, внутрішні резолвери й самі застосунки тримають старі адреси, і внесена правка «не застосовується» годинами.
Четверта — відсутність історії змін: запис виправили руками, відкочувати нічим, а наступний викат затирає його мовчки.
Розбираємо, як налаштування DNS у хмарі закривається декларативним описом: зони й записи в Yandex Cloud DNS живуть у репозиторії, проходять рев'ю, застосовуються за планом з усвідомленим TTL, а стан звіряється з описом. Тоді збій розв'язання імен локалізується за хвилини, а не за ніч перебору гіпотез.
Що дає керований сервіс імен: швидкість і передбачуваність
Керована зона — це ресурс провайдера, а не файл на одній машині: записи реплікуються, а розв'язання йде з найближчої до клієнта точки присутності.
Виведення серверів імен з обслуговування не потребує правок з нашого боку, тому планові роботи не перетворюються на вікно недоступності. Переводимо зони на Yandex Cloud і одразу фіксуємо параметри, від яких залежить поведінка при відмові.
Швидкість відгуку імен визначається близькістю резолвера і підібраним TTL. За розумного значення більшість запитів віддається з кешу, і клієнт не чекає повного рекурсивного обходу — ефект видно за часткою відповідей з кешу та за часом встановлення з'єднання.
Відмовостійкість розв'язання тримається на кількох серверах імен у різних зонах доступності. Втрата однієї точки не призводить до збою: запити йдуть на решту, а частка невдалих розв'язань залишається на рівні фонової. Ми знімаємо її до і після переїзду та порівнюємо, а не покладаємося на відчуття.
Історія змін записів закриває найдорожчий клас помилок — правку «руками» без сліду. Кожна зміна зберігає автора й час, відкат до попереднього стану займає хвилини, а самі записи живуть у декларативному описі (Terraform) з рев'ю до застосування. Там же вирішується перевірка домену для сертифікатів, яким потрібен запис у тій самій зоні.
Публічні та приватні зони: порівняння варіантів організації
Поділ на публічні та приватні зони вирішує не питання «де зберігати записи», а питання видимості: які імена розв'язуються з інтернету, а які — лише всередині хмарної мережі.
Це дві незалежні сутності з окремим життєвим циклом, і поєднувати їх в одній зоні не можна: приватні записи не повинні бути видні ззовні, а публічні зобов'язані.
На практиці обирають між чотирма схемами. Нижче — умови застосовності та те, чим кожна обмежує.
| Схема | Коли підходить | Обмеження |
|---|---|---|
| Одна публічна зона | Сайт, API і вітрина доступні з інтернету, внутрішніх імен немає | Внутрішні імена йдуть у публічний резолв, межі між зовнішнім і внутрішнім трафіком немає |
| Приватна зона всередині мережі | Внутрішні сервіси, бази, черги, звернення за іменами | Ззовні не розв'язується; записи видні лише з прив'язаних мереж, на кожну мережу — своя зона |
| Гібридна схема зон | Публічний зовнішній контур плюс закрите ядро — типовий продуктовий випадок | Однакові імена живуть у двох зонах: розсинхрон конфігурацій дає рідкісні й складні відмови |
| Власні сервери імен | Потрібен повний контроль над зоною, нестандартні записи, своя інфраструктура імен уже є | Доступність і відмовостійкість — на вас; делегування, передача зони, резолв залежить від вашої площадки |
Гібрид — те, до чого приходять майже всі продуктові контури: назовні віддається мінімум записів, внутрішні імена живуть у приватній зоні, прив'язаній до конкретних мереж. Варіант визначає не зручність, а межі відмови: чим публічніша зона, тим дорожча помилка в записі.
Порядок впровадження: від інвентаризації зон до передачі
Впровадження розбито на етапи так, щоб кожну зміну можна було перевірити й відкотити, не чекаючи спливання TTL.
Спершу фіксуємо поточний стан і власників записів, потім переносимо зони і лише потім перемикаємо трафік — на кожному кроці є точка повернення й критерій, за яким зрозуміло, що можна йти далі.
-
Інвентаризація записів. Вивантажуємо всі записи з чинних зон — A, AAAA, CNAME, MX, TXT, SRV, CAA — і звіряємо з фактичним трафіком та активними сервісами. Для кожного запису знаходимо власника: без відповідального за призначення запис у перенесення не йде.
-
Схема зон. Розмічаємо, що залишається в публічній зоні, а що йде в приватну — внутрішні сервіси, бази, службові імена. Приватні зони прив'язуємо до конкретних мереж, щоб внутрішні імена не відповідали назовні.
-
Опис конфігурації як коду. Зони й записи описуємо декларативно, стан зберігаємо віддалено, зміни проходять рев'ю. Наявні записи імпортуємо, щоб опис збігався з реальністю, а не розходився з нею.
-
Зниження TTL і підготовка вікна. На записах, які змінюватимуться, заздалегідь зменшуємо TTL — вікно відкату скорочується з годин до хвилин. Це робиться до перемикання, інакше швидкість повернення задає старий кеш резолверів.
-
Контрольоване перемикання. Спершу переносимо тестовий домен і переконуємося, що відповіді збігаються з еталоном, потім змінюємо делегування бойової зони. Стара зона залишається робочою — обидва набори серверів відповідають однаково.
-
Перевірка після зміни. Опитуємо записи із зовнішніх резолверів і з кожної мережі, звіряємо з інвентарним вивантаженням, перевіряємо поштові записи й випуск сертифікатів: домен-підтвердження і CAA мають проходити без ручних правок.
-
Відкат і передача. До кінця вікна спостереження тримаємо стару зону в актуальному стані, відкат — повернення делегування. В експлуатацію передаємо доступи, порядок правок через код, моніторинг відповідей і контроль строків поновлення сертифікатів.
Що передаємо на руки: конфігурації, схеми, регламенти
Передаємо не архів файлів, а робочу конфігурацію, яку можна розгорнути з нуля й далі вести без нас. Усі артефакти лежать у репозиторії та проходять перевірку до застосування, тому стан зон у Yandex Cloud DNS не розходиться з тим, що описано в коді.
- Опис зон і записів у декларативному вигляді — файли з публічними й приватними зонами, записами, значеннями TTL і прив'язкою до середовищ. Будь-яка правка йде через рев'ю та перевірку плану, ручні зміни в панелі керування виключені.
- Схема мережі та зв'язків — як зони співвідносяться з мережами, підмережами й сервісами, де розв'язання імен іде назовні, а де залишається всередині контуру. Окремо позначені точки, де найчастіше виникають конфлікти.
- Правила доступу до керування зонами — ролі для інженерів, окремі сервісні облікові записи для автоматизації, розподіл прав між бойовим і тестовим контуром.
- Розподіл середовищ — параметри й стани для продакшену та стендів рознесені, тому експерименти не потрапляють у бойові зони й не ламають розв'язання імен у користувачів.
- Документація — порядок додавання запису, випуску й оновлення сертифікатів, перевірки відповідності опису реальному стану.
- Регламент реагування на інциденти — контрольні точки моніторингу, порядок відкату до попередньої конфігурації, критерії ескалації та зона відповідальності на боці замовника.
- Порядок передачі — склад доступів, послідовність запуску з нуля та перевірочний сценарій, за яким ваша команда переконується, що інфраструктура працює без нас.
Кейс: переведення зон без простою та зростання успішних відповідей
Замовник — продуктовий сервіс із кількома десятками піддоменів і внутрішньою інфраструктурою в двох мережах. Публічні зони жили в старого реєстратора, приватні — у рукописних конфігураціях на двох серверах, сертифікати поновлювали вручну. Правка одного запису займала півдня і вимагала ручної звірки між середовищами.
Зріз до міграції: частка успішних відповідей трималася на 96–97%, після кожної правки зони розв'язання імені просідало до 40 секунд, а внутрішні імена частина сервісів не знаходила взагалі.
У підтримку надходило близько тридцяти звернень на місяць із формулюванням «сервіс не відкривається», і розбирали їх руками — причин могло бути три: кеш, застарілий запис або сертифікат, що відвалився.
Що змінили
Зони й записи перенесли в Yandex Cloud DNS і описали в Terraform: публічні — декларативно, приватні — прив'язкою до мереж, щоб внутрішні імена розв'язувалися лише всередині контуру.
За добу до перемикання знизили TTL до хвилини, дали старим кешам сплисти і лише потім змінили сервери імен у реєстратора. Перевірку домену для сертифікатів перевели на DNS-записи, поновлення стало автоматичним.
Зріз після: частка успішних відповідей — 99,9% і вище, розв'язання імені вкладається в десятки мілісекунд. Перемикання пройшло без простою — вікно зайняло 40 хвилин, і весь цей час сервіс коректно відповідав через обидва набори серверів імен.
Звернення «не відкривається» впали до поодиноких за місяць, і майже всі — із зовнішніх мереж, де кеш провайдера живе своїм життям.
Чим приватна DNS-зона відрізняється від публічної
Публічна зона відповідає на запити з інтернету: її записи віддають авторитативні сервери імен, а батьківська зона делегує на них домен. Приватна зона живе всередині хмарної мережі — її бачать лише запити звідти, і делегування назовні в неї немає. Тому однаково названий домен може існувати у двох зонах одночасно і не конфліктувати між собою.
Область видимості записів — головна відмінність. У публічній зоні будь-який зовнішній резолвер отримає адресу, і приховати частину записів не вийде: піддомени рано чи пізно потрапляють у відкриті переліки.
У приватній ім'я для інтернету не існує — ззовні запит поверне відмову, а зсередини потрібну адресу.
На приватній зоні будуються внутрішні імена сервісів. Ім'я виду db.prod.internal створюється поряд із мережею і не залежить від адрес конкретних інстансів: при заміні чи масштабуванні змінюється лише запис, а конфігурації застосунків залишаються незмінними. Те саме ім'я використовується в правилах доступу між сервісами.
При розділенні зовнішнього й внутрішнього розв'язання одне ім'я може відповідати різними адресами — ззовні на вхідну точку, зсередини напряму на сервіс. Так службовий трафік не ходить через зовнішній периметр, а вибір середовища задається зоною, а не правкою коду.
У Yandex Cloud DNS обидві зони описуються декларативно разом із прив'язкою до мереж, тому стан відтворюваний.
Сертифікати для внутрішніх імен випускає приватний центр сертифікації, для публічних — підтвердження володіння доменом; і те й інше спливає за розкладом, тому оновлення ставимо регулярною задачею, а не ручною операцією.
Часті питання: час життя записів, міграція, сертифікати
Налаштування зони — це лише початок: далі важливіше, як вона живе в експлуатації. Нижче — відповіді на чотири питання, які найчастіше ставлять перед тим, як узяти площадку в роботу.
Зони, записи, сертифікати й права описуємо кодом і зберігаємо в репозиторії — стан зони завжди можна порівняти з описом і відкотити. Це ж знімає головний біль передачі: новий інженер бачить, чому запис виглядає саме так.
Який час життя записів вибрати?
Перед плановим перемиканням час життя знижують заздалегідь, щоб старі адреси перестали осідати в кеші резолверів, а після стабілізації повертають до спокійного значення. Тримати його низьким постійно не варто: зростає кількість запитів до зони. Для статичних записів беруть години, для записів за балансувальником — хвилини.
Як переїхати на нову площадку без простою?
Спершу імпортуємо поточні записи в опис, звіряємо розходження і лише потім перемикаємо сервери імен, перевіряючи резолв із кількох мереж. Старий контур тримаємо до спливання найдовшого часу життя запису і лише потім знімаємо. Відкат — повернути попередній опис зони.
Як не пропустити поновлення доменів і сертифікатів?
Випуск і поновлення сертифікатів ставимо на автоматику з перевіркою валідації на тестовому контурі, а не в день спливання. За доменами й зонами налаштовуємо оповіщення за кілька тижнів до строку, щоб поновлення не перетворювалося на аварійну роботу у вихідні.
Що входить у передачу експлуатації?
Схема зон, опис у репозиторії, регламенти випуску сертифікатів і правок записів, розмежування доступів та інструкція з відкату. Проводимо розбір із вашою командою і залишаємося на зв'язку на період, поки чергування не перейде до вас.
Обговоримо вашу схему зон і повернемося з планом робіт
Щоб оцінка робіт була не «на око», нам достатньо поточної картини зон: які домени обслуговуються, де зони публічні, а де приватні всередині Yandex Cloud.
Якщо конфігурація вже описана кодом, надішліть репозиторій або вивантаження; якщо записи ведуться вручну — вистачить переліку й схеми зв'язків.
На дзвінку розберемо:
- які зони публічні, які приватні й чи не дублюють вони одна одну;
- як видаються сертифікати й де спливають їхні строки;
- де залишилися ручні правки й що заважає перенести їх в опис інфраструктури;
- як налаштоване делегування й куди вказують NS-записи;
- які сервіси залежать від DNS і що станеться при недоступності зони;
- чи потрібен захист від підміни відповідей і контроль цілісності;
- як розділені права доступу до зон усередині команди.
Що надіслати заздалегідь:
- перелік доменів і піддоменів із призначенням;
- схему мереж: де живуть сервіси й кому потрібні внутрішні імена;
- поточні конфігурації або вивантаження зон;
- перелік сертифікатів і місць, де вони використовуються.
Після цього повернемося з оцінкою та планом впровадження: черговість перенесення зон, спосіб опису конфігурації, точки перевірки й порядок відкату. Опишіть задачу у двох абзацах — цього вистачить, щоб назвати строки та склад робіт.
