Azure DNS ламається тихо: де вузькі місця зон і записів
Збій розв'язання імен рідко виглядає як повне падіння: зазвичай частина клієнтів ще відкриває сервіс, а частина отримує відмову або йде на стару адресу.
В Azure DNS запис живе в конкретній зоні, і щойно правку вносять вручну в одній панелі, друга зона — публічна чи внутрішня — залишається з попереднім станом. Розрив накопичується непомітно, а проявляється одразу як недоступність сервісів для окремого сегмента.
Конфлікт публічного та внутрішнього розв'язання імен — друге вузьке місце зони. Якщо внутрішній контур ходить за зовнішнім ім'ям, трафік іде назовні, а розбіжність записів між контурами перетворюється на відмови автентифікації та перевірки, які проходять не для всіх мереж.
Додайте сюди записи-сироти: адреси виведених вузлів, чиї імена все ще вказують на знятий з експлуатації вузол, і залишкові CNAME після міграцій.
Ручні правки в кількох панелях спричиняють накопичення помилок у записах, якого не видно ні в моніторингу, ні в регламенті змін. У кожного запису свій TTL, свої значення, свій автор — і за пару місяців ніхто не скаже, яка версія відповідає реальній топології.
Поки зона відповідає, проблема не вважається інцидентом, хоча ціна помилки в записі така сама, як у невдалого релізу.
Найпомітніше це на великих TTL: стара відповідь живе в кеші резолверів довше, ніж триває відкат, і відновлення сервісу розтягується на години.
Нижче розбираємо, як це закривається — від єдиного джерела правди для зон до перевірок, які ловлять розбіжність до того, як вона стане збоєм доступності.
Що дає вибудувана схема зон: швидкість, відмови, контроль
Вибудувана схема зон тримається на одному принципі: публічні та приватні зони описані в одному місці й в одному форматі, а не збираються по панелях керування.
Запис змінюється через обов'язкову перевірку, а після застосування виглядає однаково для всіх: ім'я, тип, TTL, прив'язка до ресурсу, зв'язок з віртуальними мережами.
Так з'являється єдина точка правди за іменами. Розбіжність між «як налаштовано в панелі» та «як написано в документації» зникає як клас — звіряти більше нічого.
Час реакції на зміну запису вимірюється хвилинами: правка проходить перевірку й застосовується автоматично, без ланцюжка погоджень і ручного вводу.
Окремий клас відмов — розбіжність публічної та приватної зон. Сервіс усередині мережі резолвиться в застарілу адресу, бо запис оновили лише в одній зоні, а друга залишилася з попереднім значенням.
Коли обидві зони в Azure DNS генеруються з одного опису, такий збій стає неможливим технічно, а не «малоймовірним за домовленістю».
Відновлення після збою теж перестає бути імпровізацією. Опис зон лежить у репозиторії під контролем версій, тож конфігурація піднімається повторним застосуванням, а не з пам'яті чергового інженера.
Звірка після відновлення автоматична: перевірки розв'язання імен з різних мереж підтверджують, що зони повернулися в робочий стан.
Контроль додається тим самим описом: розмежування прав за ролями, журнал змін з автором і причиною, перевірки, які ловлять конфліктні записи до застосування. Керування зонами стає рутинною передбачуваною операцією, а не разовим подвигом із непередбачуваним результатом.
Публічні та приватні зони Azure DNS: вибір режиму
В Azure DNS режим зони визначає не зручність, а те, хто взагалі зможе розв'язати ім'я. Публічна зона відповідає на запити будь-яких резолверів і дає змогу підтвердити права на домен.
Приватна живе всередині пов'язаних віртуальних мереж: ззовні таких імен не існує, натомість внутрішні сервіси отримують стабільні адреси й не виходять назовні.
Порівняння варіантів
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Публічна зона | Сервіси з доступом з інтернету, зовнішні точки входу, перевірка володіння доменом | Усі записи видно ззовні, внутрішні імена доводиться виносити в окремий суфікс; доступ ззовні не обмежити |
| Приватна зона | Внутрішні імена сервісів, баз даних і службових вузлів, звернення лише зі своїх мереж | Не розв'язується з інтернету; кожна мережа пов'язується із зоною явно; за автореєстрації записів потрібно чистити сліди видалених вузлів |
| Суміщена схема: одне ім'я домену в обох зонах | Коли зовнішні та внутрішні клієнти звертаються за однією адресою, але мають потрапляти на різні точки входу | Два набори записів живуть окремо й потребують синхронізації; розбіжність дає збої, які складно відтворити |
Вибір робимо за картою розв'язання імен: що й звідки звертається, які мережі пов'язані із зоною, чи потрібна автоматична реєстрація вузлів. Далі процес описується кодом — інакше ручні правки записів швидко розходяться між зовнішнім і внутрішнім контуром.
Етапи впровадження: від аудиту зон до передачі регламентів
Порядок робіт зафіксований: кожен етап завершується перевірюваним артефактом, без якого наступний крок не має сенсу. В Azure DNS це особливо важливо — помилка в записі видна не одразу, а коли частина сервісів перестає розв'язувати імена.
-
Аудит зон і записів. Вивантажуємо всі зони й записи, звіряємо типи A, CNAME, MX і TXT, значення TTL, шукаємо висячі посилання та дублі. Окремо фіксуємо, хто вносить зміни зараз — вручну через панель чи скриптом.
-
Схема доменів. Зводимо карту: публічні та внутрішні зони, точки делегування, прив'язка до віртуальних мереж, хто має право створювати записи. Схема погоджується до правок у робочих зонах.
-
Налаштування записів і доступів. Створюємо зони й записи строго за схемою, приводимо TTL до єдиних шаблонів, роздаємо ролі з мінімально потрібними правами й вмикаємо журналювання змін.
-
Автоматизація. Типові записи заводимо шаблонами, зміни проходять через інфраструктуру як код із перевіркою в тестовій зоні до застосування.
-
Перевірка розв'язання імен. Звіряємо відповіді зсередини мережі та ззовні з еталонним вивантаженням, чекаємо поширення записів, окремо тестуємо відкат на попередні сервери імен.
-
Передача документації та навчання. Віддаємо регламент змін, карту зон і порядок відкату, розбираємо з командою типові задачі на живих прикладах.
Після цього правки йдуть за регламентом, а не з пам'яті інженера: зміна відтворювана, відкат перевірений, стан зон збігається з документацією.
Що залишається у вас: зони, записи, політики, схеми, регламенти
Ми не залишаємо після себе налаштований портал, до якого прив'язаний підрядник. Усе, що описує ваші публічні та приватні зони, лежить у вашому репозиторії й розгортається з нього.
Стан зон перезбирається з нуля на чистій підписці, а документація пояснює не лише що налаштовано, а й чому саме так.
- Конфігурація зон і записів. Публічні зони з повним набором A, AAAA, CNAME, MX і TXT та коректним делегуванням через NS у реєстратора; приватні — з прив'язкою до віртуальних мереж і увімкненою автореєстрацією записів.
- Описи інфраструктури в коді. Модулі, з яких зони збираються повторювано: прогін не створює дублів і не перезаписує TTL записів, які веде інша команда.
- Схема зв'язків. Діаграма: що делеговано, які мережі прив'язані до приватних зон, де закінчується зона й починається балансувальник або зовнішній сервіс.
- Політики доступу. Ролі на читання й правку в розрізі команд, доступ до приватних зон лише зсередини мережі, правки в обхід репозиторію закриті на рівні прав.
- Регламент змін. Хто погоджує новий запис, у якій гілці він з'являється, які перевірки проходить до застосування і як помилкова зміна відкочується одним прогоном.
- Інструкція для чергової зміни. Покрокова перевірка за недоступності імені: делегування, кеш резолвера, стан запису — без пошуку відповідального в месенджерах.
- Звіт інвентаризації. Що було в зонах до робіт: висячі записи, конфлікти імен, записи без власника.
Кейс: розділення публічного та внутрішнього контурів зони
Клієнт прийшов із типовою картиною: одна зона в Azure DNS обслуговувала і зовнішні сервіси, і внутрішні системи. Записи внутрішніх вузлів лежали в тій самій зоні, що й публічні, — правка адреси внутрішнього сервісу йшла у зовнішній резолв. Це давало витік топології назовні й перетворювало рутинну зміну на операцію з вікном простою.
Що було
Внутрішні сервіси резолвилися за публічними іменами, тому маршрут трафіку залежав від зовнішнього резолвера. Помилка в одному записі валила одразу обидва контури — клас відмови був спільним. На рядову зміну запису йшло до двох годин погоджень, роботи ставили в нічне вікно.
Що зробили і що стало
Контури розвели: публічна зона залишилася за зовнішніми сервісами, внутрішні системи переїхали в приватну зону, видиму лише з пов'язаної віртуальної мережі. Відповідь почала залежати від того, звідки надійшов запит, а не від того, хто останнім правив запис.
Зміни пішли через керований репозиторій із перевіркою синтаксису та передпереглядом правок — запис потрапляє в зону лише після рев'ю.
- Простий під час планової зміни: з ~40 хвилин до нуля — правки застосовуються без переривання резолву.
- Інциденти через перетин записів: з 5–6 на квартал до нуля за спостережуваний період.
- Час на зміну запису: з ~2 годин до хвилин, включно з рев'ю.
- Відкат: повернення попередньої версії зонного файлу замість ручної правки в панелі.
Окремо зафіксували TTL для внутрішніх записів — тепер старий запис не «залипає» в кеші на години після зміни адреси.
Чим приватна зона відрізняється від публічної в одному домені?
Те саме ім'я домену може обслуговуватися двома зонами: публічною — вона відповідає будь-якому резолверу з інтернету, і приватною — вона видима лише прив'язаним віртуальним мережам. Записи в них незалежні: правка в публічній зоні нічого не змінює всередині. В Azure DNS це два окремі об'єкти, і саме тут виникає основна плутанина під час супроводу.
Інженерна тонкість: приватну зону з ім'ям, уже зайнятим публічною, не прив'язати до мережі, поки в публічній залишається набір записів делегування NS. Вимога усвідомлена — інакше ламається зовнішнє делегування домену.
Далі вирішується доля записів: за увімкненої автореєстрації адреси машин з'являються в приватній зоні самі, але після виведення машини з експлуатації залишаються сміттям, яке потрібно вичищати.
Під час розв'язання імен клієнт із прив'язаної мережі отримує відповідь із приватної зони, а якщо запису там немає — запит іде звичайним шляхом.
Тому внутрішнє ім'я може раптом розрезолвитися в публічну адресу: приватна зона нічого зайвого не віддала, просто потрібного запису в ній не виявилося.
Розбіжності виникають передбачувано: запис змінили в одній зоні й забули в другій; виведений вузол залишився в приватній зоні й віддає неробочу адресу; кеш тримає стару відповідь довше, ніж триває перемикання. Лікується це не пильністю чергового, а регламентом.
Ми ведемо обидві зони в одному реєстрі як одну сутність, перевіряємо ім'я двома резолверами — ззовні та зсередини мережі — і узгоджуємо строк життя записів зі сценарієм перемикання. Тоді розбіжність ловиться перевіркою, а не розбором після збою.
Часті технічні питання: делегування, кеш, відкат
Зміни в DNS майже ніколи не ламаються в момент застосування — складнощі починаються на стику з кешем резолверів, делегуванням і розмежуванням прав.
Нижче зібрали сумніви, які найчастіше спливають перед стартом робіт на Azure DNS: скільки чекати набуття правками чинності, як переїхати без вікна недоступності і що робити, якщо запис пішов не туди.
Як швидко зміни стають видні?
Швидкість визначає час життя запису, а не панель керування. Поки попереднє значення не спливло в кеші проміжних резолверів, частина клієнтів бачитиме стару адресу — від кількох хвилин до годин.
Тому записи, які плануємо змінювати, заздалегідь переводимо на короткий час життя, витримуємо паузу й лише потім вносимо правку.
Чи можна перенести делегування без простою?
Так, через паралельну роботу двох сторін. Спершу піднімаємо зону на новому місці з усіма записами й звіряємо відповіді, потім змінюємо в реєстратора записи про сервери імен.
Поки попередні сервери відповідають, домен продовжує розв'язуватися, а розбіжність на час переходу закриваємо двосторонньою синхронізацією.
Як проходить часткова міграція записів?
Розбиваємо зону на смислові блоки — веб, пошта, службові піддомени — і переносимо по одному, звіряючи відповіді на кожному кроці. Так збій локалізується в одному блоці й не зачіпає решту зони, а строки переїзду залишаються передбачуваними.
Що буде, якщо зміна помилкова?
Відкат іде на рівні записів: попередні значення зберігаємо, повернення — одна операція, що набуває чинності за тим самим часом життя. Масові правки вносимо шаблонами й скриптами, щоб відкат був відтворюваним, а не зібраним вручну під тиском.
Як обмежити доступ до внутрішніх зон?
Приватні зони прив'язані до конкретних віртуальних мереж, тому із зовнішньої мережі ім'я просто не розв'язується. Права видаємо ролями на рівні зони, розділяючи читання й запис, а історію змін ведемо так, щоб за кожним значенням було видно автора й час.
Обговоримо вашу зону: зберемо схему та план міграції
Щоб оцінка спиралася на факти, а не на здогадки, достатньо надіслати перелік доменів, поточного постачальника розв'язання імен, список внутрішніх зон і вимоги щодо доступів між командами. Цього вистачає, щоб побачити картину загалом і не перепитувати по ходу розбору.
У відповідь ви отримуєте:
- схему зон в Azure DNS — публічні та приватні, з прив'язкою до підписок і віртуальних мереж;
- карту делегування: де зона віддана назовні, а де розв'язання імен залишається всередині контуру;
- порядок переїзду записів за етапами, з точками відкату на кожному кроці;
- перелік записів, які правляться вручну — поштові, перевірочні, сервісні;
- склад робіт і розподіл відповідальності між нашими інженерами та вашою командою;
- строки за етапами та умови, за яких переїзд можна зупинити без втрати розв'язання імен;
- пропозицію щодо автоматизації: що переводимо в опис конфігурації кодом, а що залишаємо в ручному режимі.
Далі — короткий розбір схеми з вашою командою, уточнення меж приватних зон і старт із найменш пов'язаного домену. Опишіть задачу в зручній формі — повернемося з оцінкою та планом.
