Azure DNS: настройка публичных и private зон, автоматизация

Azure DNS ломается тихо: где узкие места зон и записей

Сбой разрешения имён редко выглядит как падение целиком: обычно часть клиентов ещё открывает сервис, а часть получает отказ или уходит на старый адрес. В Azure DNS запись живёт в конкретной зоне, и как только правку вносят вручную в одной панели, вторая зона — публичная или внутренняя — остаётся с прежним состоянием. Разрыв копится незаметно, а проявляется сразу как недоступность сервисов для отдельного сегмента.

Конфликт публичного и внутреннего разрешения имён — второе узкое место зоны. Если внутренний контур ходит по внешнему имени, трафик уходит наружу, а расхождение записей между контурами превращается в отказы аутентификации и в проверки, которые проходят не для всех сетей. Добавьте сюда записи-сироты: адреса выведенных узлов, чьи имена всё ещё указывают на снятый с эксплуатации узел, и остаточные CNAME после миграций.

Ручные правки в нескольких панелях дают накопление ошибок в записях, которого не видно ни в мониторинге, ни в регламенте изменений. У каждой записи свой TTL, свои значения, свой автор — и через пару месяцев никто не скажет, какая версия соответствует реальной топологии. Пока зона отвечает, проблема не считается инцидентом, хотя цена ошибки в записи такая же, как у неудачного релиза.

Заметнее всего это на больших TTL: старый ответ живёт в кэше резолверов дольше, чем длится откат, и восстановление сервиса растягивается на часы. Ниже разбираем, как это закрывается — от единого источника правды для зон до проверок, которые ловят расхождение до того, как оно станет сбоем доступности.

Что даёт выстроенная схема зон: скорость, отказы, контроль

Выстроенная схема зон держится на одном принципе: публичные и приватные зоны описаны в одном месте и в одном формате, а не собираются по панелям управления. Запись меняется через обязательную проверку, а после применения выглядит одинаково для всех: имя, тип, TTL, привязка к ресурсу, связь с виртуальными сетями.

Так появляется единая точка правды по именам. Расхождение между «как настроено в панели» и «как написано в документации» уходит как класс — сверять больше нечего. Время реакции на изменение записи измеряется минутами: правка проходит проверку и применяется автоматически, без цепочки согласований и ручного ввода.

Отдельный класс отказов — расхождение публичной и приватной зон. Сервис внутри сети резолвится в устаревший адрес, потому что запись обновили только в одной зоне, а вторая осталась на прежнем значении. Когда обе зоны в Azure DNS генерируются из одного описания, такой сбой становится невозможен технически, а не «маловероятен по договорённости».

Восстановление после сбоя тоже перестаёт быть импровизацией. Описание зон лежит в репозитории под контролем версий, поэтому конфигурация поднимается повторным применением, а не по памяти дежурного инженера. Сверка после восстановления автоматическая: проверки разрешения имён из разных сетей подтверждают, что зоны вернулись в рабочее состояние.

Контроль добавляется тем же описанием: разграничение прав по ролям, журнал изменений с автором и причиной, проверки, которые ловят конфликтующие записи до применения. Управление зонами становится рутинной предсказуемой операцией, а не разовым подвигом с непредсказуемым результатом.

Публичные и приватные зоны Azure DNS: выбор режима

В Azure DNS режим зоны определяет не удобство, а то, кто вообще сможет разрешить имя. Публичная зона отвечает на запросы любых резолверов и позволяет подтвердить права на домен. Приватная живёт внутри связанных виртуальных сетей: снаружи такие имена не существуют, зато внутренние сервисы получают стабильные адреса и не выходят наружу.

Сравнение вариантов

Выбор делаем по карте разрешения имён: что и откуда обращается, какие сети связаны с зоной, нужна ли автоматическая регистрация узлов. Дальше процесс описывается кодом — иначе ручные правки записей быстро разъезжаются между внешним и внутренним контуром.

Этапы внедрения: от аудита зон до передачи регламентов

Порядок работ фиксирован: каждый этап заканчивается проверяемым артефактом, без которого следующий шаг не имеет смысла. В Azure DNS это особенно важно — ошибка в записи видна не сразу, а когда часть сервисов перестаёт разрешать имена.

1. Аудит зон и записей. Выгружаем все зоны и записи, сверяем типы A, CNAME, MX и TXT, значения TTL, ищем висячие ссылки и дубли. Отдельно фиксируем, кто вносит изменения сейчас — вручную через панель или скриптом.

2. Схема доменов. Сводим карту: публичные и внутренние зоны, точки делегирования, привязка к виртуальным сетям, кто имеет право создавать записи. Схема согласуется до правок в рабочих зонах.

3. Настройка записей и доступов. Создаём зоны и записи строго по схеме, приводим TTL к единым шаблонам, раздаём роли с минимально нужными правами и включаем журналирование изменений.

4. Автоматизация. Типовые записи заводим шаблонами, изменения проходят через инфраструктуру как код с проверкой в тестовой зоне до применения.

5. Проверка разрешения имён. Сверяем ответы изнутри сети и снаружи с эталонной выгрузкой, ждём распространения записей, отдельно тестируем откат на прежние серверы имён.

6. Передача документации и обучение. Отдаём регламент изменений, карту зон и порядок отката, разбираем с командой типовые задачи на живых примерах.

После этого правки идут по регламенту, а не по памяти инженера: изменение воспроизводимо, откат проверен, состояние зон совпадает с документацией.

Что остаётся у вас: зоны, записи, политики, схемы, регламенты

Мы не оставляем после себя настроенный портал, к которому привязан подрядчик. Всё, что описывает ваши публичные и приватные зоны, лежит в вашем репозитории и разворачивается из него. Состояние зон пересобирается с нуля на чистой подписке, а документация объясняет не только что настроено, но и почему именно так.

• Конфигурация зон и записей. Публичные зоны с полным набором A, AAAA, CNAME, MX и TXT и корректным делегированием через NS у регистратора; приватные — с привязкой к виртуальным сетям и включённой авторегистрацией записей.
• Описания инфраструктуры в коде. Модули, из которых зоны собираются повторяемо: прогон не создаёт дублей и не перезаписывает TTL записей, которые ведёт другая команда.
• Схема связей. Диаграмма: что делегировано, какие сети привязаны к приватным зонам, где заканчивается зона и начинается балансировщик или внешний сервис.
• Политики доступа. Роли на чтение и правку в разрезе команд, доступ к приватным зонам только изнутри сети, правки в обход репозитория закрыты на уровне прав.
• Регламент изменений. Кто согласует новую запись, в какой ветке она появляется, какие проверки проходит до применения и как ошибочное изменение откатывается одним прогоном.
• Инструкция для дежурной смены. Пошаговая проверка при недоступности имени: делегирование, кэш резолвера, состояние записи — без поиска ответственного в мессенджерах.
• Отчёт инвентаризации. Что было в зонах до работ: висящие записи, конфликты имён, записи без владельца.

Кейс: разделение публичного и внутреннего контуров зоны

Клиент пришёл с типовой картиной: одна зона в Azure DNS обслуживала и внешние сервисы, и внутренние системы. Записи внутренних узлов лежали в той же зоне, что и публичные, — правка адреса внутреннего сервиса уходила во внешний резолв. Это давало утечку топологии наружу и превращало рутинное изменение в операцию с окном простоя.

Что было

Внутренние сервисы резолвились по публичным именам, поэтому маршрут трафика зависел от внешнего резолвера. Ошибка в одной записи валила сразу оба контура — класс отказа был общим. На рядовое изменение записи уходило до двух часов согласований, работы ставили в ночное окно.

Что сделали и что стало

Контуры развели: публичная зона осталась за внешними сервисами, внутренние системы переехали в приватную зону, видимую только из связанной виртуальной сети. Ответ стал зависеть от того, откуда пришёл запрос, а не от того, кто последним правил запись. Изменения пошли через управляемый репозиторий с проверкой синтаксиса и предпросмотром правок — запись попадает в зону только после ревью.

• Простой при плановом изменении: с ~40 минут до нуля — правки применяются без прерывания резолва.
• Инциденты из-за пересечения записей: с 5–6 в квартал до нуля за наблюдаемый период.
• Время на изменение записи: с ~2 часов до минут, включая ревью.
• Откат: возврат предыдущей версии зонного файла вместо ручной правки в панели.

Отдельно зафиксировали TTL для внутренних записей — теперь старая запись не «залипает» в кэше на часы после смены адреса.

Чем приватная зона отличается от публичной в одном домене?

Одно и то же имя домена может обслуживаться двумя зонами: публичной — она отвечает любому резолверу из интернета, и приватной — она видна только привязанным виртуальным сетям. Записи в них независимы: правка в публичной зоне ничего не меняет внутри. В Azure DNS это два отдельных объекта, и именно здесь возникает основная путаница при сопровождении.

Инженерная тонкость: приватную зону с именем, уже занятым публичной, не привязать к сети, пока в публичной остаётся набор записей делегирования NS. Требование осознанное — иначе ломается внешнее делегирование домена. Дальше решается судьба записей: при включённой авторегистрации адреса машин появляются в приватной зоне сами, но после вывода машины из эксплуатации остаются мусором, который нужно вычищать.

При разрешении имён клиент из привязанной сети получает ответ из приватной зоны, а если записи там нет — запрос уходит обычным путём. Поэтому внутреннее имя может внезапно разрезолвиться в публичный адрес: приватная зона ничего лишнего не отдала, просто нужной записи в ней не оказалось.

Расхождения возникают предсказуемо: запись сменили в одной зоне и забыли во второй; выведенный узел остался в приватной зоне и отдаёт неработающий адрес; кэш держит старый ответ дольше, чем идёт переключение. Лечится это не бдительностью дежурного, а регламентом.

Мы ведём обе зоны в одном реестре как одну сущность, проверяем имя двумя резолверами — снаружи и изнутри сети — и согласуем срок жизни записей со сценарием переключения. Тогда расхождение ловится проверкой, а не разбором после сбоя.

Частые технические вопросы: делегирование, кэш, откат

Изменения в DNS почти никогда не ломаются в момент применения — сложности начинаются на стыке с кэшем резолверов, делегированием и разграничением прав. Ниже собрали сомнения, которые чаще всего всплывают перед стартом работ на Azure DNS: сколько ждать вступления правок в силу, как переехать без окна недоступности и что делать, если запись ушла не туда.

Можно ли перенести делегирование без простоя?

Да, через параллельную работу двух сторон. Сначала поднимаем зону на новом месте со всеми записями и сверяем ответы, затем меняем у регистратора записи о серверах имён. Пока прежние серверы отвечают, домен продолжает разрешаться, а расхождение на время перехода закрываем двусторонней синхронизацией.

Как проходит частичная миграция записей?

Разбиваем зону на смысловые блоки — веб, почта, служебные поддомены — и переносим по одному, сверяя ответы на каждом шаге. Так сбой локализуется в одном блоке и не затрагивает остальную зону, а сроки переезда остаются предсказуемыми.

Что будет, если изменение ошибочно?

Откат идёт на уровне записей: предыдущие значения сохраняем, возврат — одна операция, вступающая в силу по тому же времени жизни. Массовые правки вносим шаблонами и скриптами, чтобы откат был воспроизводимым, а не собранным вручную под давлением.

Как ограничить доступ к внутренним зонам?

Приватные зоны привязаны к конкретным виртуальным сетям, поэтому из внешней сети имя просто не разрешается. Права выдаём ролями на уровне зоны, разделяя чтение и запись, а историю изменений ведём так, чтобы по каждому значению был виден автор и время.

Обсудим вашу зону: соберём схему и план миграции

Чтобы оценка опиралась на факты, а не на догадки, достаточно прислать перечень доменов, текущего поставщика разрешения имён, список внутренних зон и требования по доступам между командами. Этого хватает, чтобы увидеть картину целиком и не переспрашивать по ходу разбора.

В ответ вы получаете:

• схему зон в Azure DNS — публичные и приватные, с привязкой к подпискам и виртуальным сетям;
• карту делегирования: где зона отдана наружу, а где разрешение имён остаётся внутри контура;
• порядок переезда записей по этапам, с точками отката на каждом шаге;
• перечень записей, которые правятся вручную — почтовые, проверочные, сервисные;
• состав работ и разделение ответственности между нашими инженерами и вашей командой;
• сроки по этапам и условия, при которых переезд можно остановить без потери разрешения имён;
• предложение по автоматизации: что переводим в описание конфигурации кодом, а что оставляем в ручном режиме.

Дальше — короткий разбор схемы с вашей командой, уточнение границ приватных зон и старт с наименее связанного домена. Опишите задачу в удобной форме — вернёмся с оценкой и планом.