Настройка 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-записи: вершина зоны, балансировщик, точка распространения контента — и какой ресурс каждая из них должна отслеживать.
- Приватные зоны и их связи с виртуальными сетями: какие имена разрешаются только изнутри и какие сети должны видеть одну и ту же зону.
- Порядок переключения: какой контур считаем тестовым, в какое окно допустимы изменения и как быстро потребуется откат.
- Доступы: подписка, роль в панели управления, вход к регистратору для смены серверов имён и к среде, где живут сервисы-цели.
Если части данных нет — это не повод откладывать разговор: пробелы в схеме обычно и есть источник риска. Опишите задачу в свободной форме, и мы вернёмся с оценкой объёма, порядком работ и понятными сроками.
