Налаштування Azure DNS: де ручне керування зонами призводить до відмов
Налаштування Azure DNS на практиці часто зводиться до порталу: записи додають вручну, правки вносять безпосередньо в робочому середовищі, а історія змін залишається в листуванні та в чиїйсь пам'яті. Поки сервісів десять, це терпимо.
Коли зон кілька і над ними паралельно працюють різні команди, правка стає незворотною: другий інженер перезаписує результат першого, і повернути попередній стан нічим — звіряти нема з чим.
Окрема біда — неактуальні записи. Сервіс переїхав на новий балансувальник, стенд вивели з експлуатації, адресу звільнили, а вказівники на стару адресу в зоні залишилися: хтось забув, хтось не знав, що це його ділянка.
Клієнти та внутрішні служби продовжують ходити за застарілим маршрутом, доки не спливе TTL, а частина звернень потрапляє на чужий ресурс і повертає несподівану відповідь.
Найнеприємніше те, як це проявляється. Відмови розв'язування імен виглядають як помилки застосунку: збої є, але не в усіх і не завжди, відтворити складно, і розбір починається з коду, а не із зони.
Приватні зони, прив'язані не до всіх віртуальних мереж, дають різну поведінку в сусідніх підмережах — з однієї служби ім'я розв'язується, з іншої ні.
Ціна — простій сервісів, який помічають користувачі, і години на пошук причини не в тому місці. Розбираємо, як це закривається: як зони переводять в опис кодом, заводять alias-записи й пов'язують приватні зони з мережами, щоб розв'язування імен перестало бути ручною операцією.
Ефект керованих зон: швидкість правок і зниклий клас відмов
Правка в керованій зоні Azure DNS набуває чинності за хвилини: зміна вирушає тим самим маршрутом, що й решта конфігурації, і не потребує чекати вікна обслуговування.
Час застосування змін перестає залежати від того, хто з чергових зараз біля панелі — набір записів розгортається однаково і вдень, і вночі, а відмінності між стендом і продакшеном залишаються лише в значеннях змінних.
Автоматичне перемикання під час збою будується на alias-записах: вони вказують не на жорстку адресу, а на сервіс із перевіркою доступності. Поки вузол відповідає, трафік іде на нього; перестав — зона віддає адресу резервного контуру без ручного втручання й дзвінка черговому. Раніше такий переїзд займав десятки хвилин і тримався на тому, що хтось вчасно помітить проблему.
Окремий ефект — слід аудиту правок. Кожна зміна запису фіксується: хто, коли й що змінив, з якої гілки прийшла конфігурація.
Це знімає класичну суперечку «так і було»: історія зони читається як журнал, а повернення до попередньої ревізії займає одну операцію замість відновлення з пам'яті.
Частка ручних помилок падає насамперед завдяки відмові від правок через панель.
Записи описуються декларативно й проходять перевірку на конфлікти та дублі до застосування, тому одрук у адресі, загублена крапка в кінці імені або неправильний час життя запису перестають бути джерелом інцидентів — їх ловить автоматична перевірка, а не користувачі.
У сумі це переводить зону з режиму «чіпаємо обережно» в звичайний керований ресурс, зміни в якому передбачувані за строками й оборотні.
Схеми розміщення зон: публічні, приватні, гібридні
Схему розміщення обирають за тим, хто має бачити імена.
Публічна зона обслуговує зовнішні сервіси та підтвердження володіння доменом, приватна — звернення між вузлами й керованими сервісами всередині мережі, гібридна закриває випадок, коли вітрина дивиться назовні, а бази та внутрішні інтерфейси розв'язуються лише зсередини периметра.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Публічна зона | Зовнішні сервіси, перевірка домену, записи для партнерів | Імена видно з інтернету, внутрішні адреси публікувати не можна |
| Приватна зона | Звернення між вузлами й керованими сервісами всередині мережі | Розв'язується лише з пов'язаних віртуальних мереж, ззовні імені немає |
| Гібридна схема | Частина імен назовні, частина — лише всередині | Однакові імена в двох зонах потрібно розводити, інакше відповідь залежить від точки запиту |
Псевдоніми на зовнішні сервіси, балансувальники й точки роздачі працюють поверх будь-якої зі схем: запис посилається на ресурс, а адреса підставляється автоматично, тому зміна точки входу не потребує ручної правки зони й не залишає «завислих» імен.
Ключова деталь гібридної схеми — прив'язка приватної зони до віртуальних мереж. Без неї ім'я просто не розв'язується, а зайва прив'язка відкриває внутрішні імена сусіднім контурам, тому список мереж фіксують і перевіряють за кожної зміни топології.
Порядок робіт: від інвентаризації записів до передачі керування
Порядок робіт будуємо так, щоб жодне перемикання не залишилося без точки повернення. Спершу знімаємо поточний стан зон у Microsoft Azure, потім збираємо карту залежностей, і лише після цього змінюємо записи — по одному, з перевіркою на кожній контрольній точці.
Послідовність
- Аудит зон. Вивантажуємо всі зони й звіряємо набір записів із фактичним трафіком: де статичні адреси дублюють alias на зовнішній сервіс, де TTL завищено і кеш резолверів тримає старе значення добами. На виході — перелік розбіжностей за кожною зоною.
- Карта залежностей сервісів. Позначаємо, які застосунки та зовнішні підрядники читають зону, хто посилається на apex, у кого внутрішні імена розв'язуються через приватну зону. Карта показує, що зламається, якщо запис зникне.
- Проєктування схеми. Розкладаємо записи за призначенням: alias на балансувальник замість статичних адрес, приватні зони для внутрішніх сервісів, правила автореєстрації вузлів.
- Налаштування. Переносимо записи поетапно, попередньо знизивши TTL, щоб зміна адреси проходила передбачувано, а не розтягувалася на добу.
- Перевірка на контрольних точках. Звіряємо відповіді з кількох резолверів, окремо — розв'язування приватних імен зсередини мережі та поведінку за недоступності цільового сервісу.
- План перемикання. Фіксуємо порядок зміни NS-записів, вікно робіт, відповідального та критерій відкату — за яким сигналом повертаємо попередню конфігурацію.
- Приймання змін і передача. Ролі доступу замість спільних облікових даних, конфігурації зон у репозиторії, коротка інструкція з типових правок. Приймаємо результат разом із вашою командою, щоб далі зони супроводжувалися без нас.
Комплект передачі: конфігурації зон, схеми, регламенти правок
Зміни в DNS живуть довше, ніж підрядник: зони, записи й права залишаються у вашому тенанті — разом із ними мають залишитися й знання.
Тому передаємо не доступ до порталу, а відтворюваний набір артефактів, за яким інженер вашої команди повторить поточний стан і внесе правку без нас.
- Конфігурації зон у вигляді коду: публічні та приватні зони, alias-записи на ресурси, прив'язки до віртуальних мереж — стан відновлюється з репозиторію, а не з пам'яті.
- Схема розв'язування імен: де закінчуються внутрішні імена й починаються зовнішні, як це впливає на звернення між сервісами.
- Карта власників записів: у кожної зони та критичного запису — команда-власник і канал зв'язку, щоб під час збою не шукати винуватого.
- Політики доступу: хто читає зони, хто змінює, де зберігаються облікові дані та що робити при звільненні співробітника.
- Ролі для правок: читання відкрито інженерам, зміна — через погоджений канал із рев'ю; правки в порталі поза регламентом не проходять.
- Регламент змін: кроки від заявки до публікації, перевірка в непродуктивній зоні, вікно застосування та порядок відкату.
- Журнал і чек-лист приймання: що перевіряється після кожної правки, де зберігається історія та хто фіксує причину зміни.
Передачу закрито, коли ваша команда сама додає запис, перевіряє її резолв і відкочує зміну. Це критерій, за яким ми здаємо роботу.
Розбір впровадження: строки правок, частка ручних помилок, відмови
Зони Azure DNS жили у веб-панелі: інженер правив запис вручну й додавав скриншот у тікет. Один прогін зміни — від заявки до підтвердження — займав у середньому два дні й зачіпав трьох погоджувачів.
Дорожче коштувала не швидкість, а передбачуваність. Близько третини звернень у чергову зміну припадало на правки, внесені вручну: одрук в імені запису, загублений набір записів, помилково видалений вказівник. Історії змін не було, тому відновлення розтягувалося на години.
Що змінили
Зони переїхали в репозиторій і описуються декларативно: alias-записи посилаються прямо на ресурси, а не на проміжні імена, зони приватного розв'язування прив'язані до своїх віртуальних мереж, будь-яка правка проходить перевірку до застосування. Зміна стала запитом на злиття — з автором, історією та відкатом за один прохід.
- Час внесення правки: два дні → 20 хвилин.
- Частка інцидентів від ручних правок: третина звернень → поодинокі випадки.
- Час відновлення: години → хвилини, відкат до попереднього стану.
«Тримати записи в репозиторії виявилося спокійніше, ніж у панелі: видно, хто і навіщо змінював зону. Сперечатися на планерках більше нема про що», — керівник інфраструктури на боці замовника.
Залишилося навести лад у старих зонах, які не потрапили в першу хвилю перенесення. Переносимо їх без зупинки розв'язування імен.
Чим відрізняється делегування DNS від перенесення зони?
Делегування домену змінює того, хто відповідає за імена: у реєстратора правляться записи, які вказують, які сервери імен обслуговують зону.
Перенесення зони — це переїзд самого набору записів між серверами імен або акаунтами, і точка, куди дивиться батьківська зона, при цьому може залишитися тією самою.
Звідси й різниця в роботах: у першому випадку змінюється маршрут запитів, у другому — лише вміст, який за цим маршрутом віддається.
Зона відповідальності при делегуванні ширша: ми починаємо авторитативно відповідати за зону загалом — службовий запис, склад серверів імен, усі піддомени та записи підтвердження володіння.
Під час перенесення відповідаємо за повноту перенесеного набору: якщо загубиться запис поштового домену або перевірки володіння, домен продовжить резолвитися, а пошта та зовнішні сервіси відваляться. Тому перенесення завжди супроводжується звіркою вивантаження до й після.
Плутати ці роботи в плані небезпечно, бо порядок у них зворотний за змістом. Спершу зона піднімається на новому місці й перевіряється опитуванням із зовнішніх резолверів, потім знижується строк кешування, і лише після цього змінюються сервери імен у реєстратора.
Якщо делегувати раніше, ніж зона готова, домен віддає порожні відповіді весь строк життя попереднього запису в кешах провайдерів. Якщо перенести записи, але не делегувати, запити, як і раніше, йдуть на старі сервери імен, і змін ніхто не побачить.
Відкат на цих етапах теж різний. Делегування відкочується поверненням попередніх серверів імен у реєстратора — керування займає хвилини, але поширення займає години. Перенесення відкочується поверненням попереднього набору записів, і тут рятує вивантаження зони, зняте до правок.
У Azure DNS обидві операції виконуються різними інструментами, тому в плані робіт ми розводимо їх як окремі етапи з власними точками перевірки й рішенням про завершення.
Технічні сумніви: приватні зони, псевдоніми, обмеження
До першої правки в робочій зоні спливають ті самі п'ять питань — від ізоляції приватних зон між мережами до прав на зміну записів. Нижче короткі відповіді, щоб вирішувати це на етапі планування, а не в момент перенесення.
Одна зона може обслуговувати кілька мереж?
Так: до однієї приватної зони додаються прив'язки віртуальних мереж. Автореєстрацію імен вмикають лише на одній — інакше записи машин перезаписують одна одну, а для ізоляції беруть окремі підзони.
Як перенести вже розгорнуту зону?
Експорт у файл зони, імпорт у Azure DNS, звірка SOA, NS і попередніх CNAME. За добу до перемикання знижуємо TTL, змінюємо NS у реєстратора, стару зону тримаємо доступною для відкату, доки трафік не зійдеться.
Навіщо псевдонім, якщо є CNAME?
Псевдонім посилається на ресурс, а не на ім'я: адреса підхоплюється сама під час перестворення ресурсу, і він допустимий на вершині зони, де CNAME заборонено. Обмеження — лише ресурси Azure і загальний ліміт наборів записів та запитів.
Хто отримає права на правки?
Роль видаємо на конкретну зону, а не на підписку. Зміни йдуть через опис інфраструктури в репозиторії, на зоні стоїть блокування видалення, а всі правки з автором видно в журналі дій.
Що із зоною під час збою регіону?
Публічні зони глобальні й до регіону не прив'язані. У приватних прив'язка до мережі регіональна — резолвінг на постраждалому майданчику зникне, тому прив'язки в резервному регіоні тримаємо заздалегідь.
Обговоримо задачу: розберемо вашу схему зон і повернемося з планом
Налаштування Azure DNS рідко зводиться до додавання пари записів: важливіша схема зон, делегування та зв'язка публічних і приватних зон із сервісами.
Щоб розбір схеми зон зайняв одну розмову, а не листування на тиждень, корисно заздалегідь зібрати кілька вступних — за ними ми повернемося з оцінкою та планом робіт.
- Список доменів і зон: що публічне, що приватне, де зараз розміщена кожна зона і хто керує делегуванням.
- Поточна таблиця записів: A, CNAME, TXT, MX і все, що обов'язково має залишитися без змін після перенесення.
- Де потрібні alias-записи: вершина зони, балансувальник, точка розповсюдження контенту — і який ресурс кожна з них має відстежувати.
- Приватні зони та їхні зв'язки з віртуальними мережами: які імена розв'язуються лише зсередини і які мережі мають бачити ту саму зону.
- Порядок перемикання: який контур вважаємо тестовим, у яке вікно допустимі зміни і як швидко знадобиться відкат.
- Доступи: підписка, роль у панелі керування, вхід до реєстратора для зміни серверів імен і до середовища, де живуть сервіси-цілі.
Якщо частини даних немає — це не привід відкладати розмову: прогалини в схемі зазвичай і є джерелом ризику. Опишіть задачу у вільній формі, і ми повернемося з оцінкою обсягу, порядком робіт і зрозумілими строками.
