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 и привязкой к окружениям. Любая правка идёт через ревью и проверку плана, ручные изменения в панели управления исключены.
- Схема сети и связей — как зоны соотносятся с сетями, подсетями и сервисами, где разрешение имён уходит наружу, а где остаётся внутри контура. Отдельно отмечены точки, где чаще всего возникают конфликты.
- Правила доступа к управлению зонами — роли для инженеров, отдельные сервисные учётные записи для автоматизации, разделение прав между боевым и тестовым контуром.
- Разделение окружений — параметры и состояния для продакшена и стендов разнесены, поэтому эксперименты не попадают в боевые зоны и не ломают разрешение имён у пользователей.
- Документация — порядок добавления записи, выпуска и обновления сертификатов, проверки соответствия описания реальному состоянию.
- Регламент реагирования на инциденты — контрольные точки мониторинга, порядок откатa к предыдущей конфигурации, критерии эскалации и зона ответственности на стороне заказчика.
- Порядок передачи — состав доступов, последовательность запуска с нуля и проверочный сценарий, по которому ваша команда убеждается, что инфраструктура работает без нас.
Кейс: перевод зон без простоя и рост успешных ответов
Заказчик — продуктовый сервис с несколькими десятками поддоменов и внутренней инфраструктурой в двух сетях. Публичные зоны жили у старого регистратора, приватные — в рукописных конфигурациях на двух серверах, сертификаты продлевались вручную. Правка одной записи занимала полдня и требовала ручной сверки между окружениями.
Срез до миграции: доля успешных ответов держалась на 96–97%, после каждой правки зоны разрешение имени проседало до 40 секунд, а внутренние имена часть сервисов не находила вовсе. В поддержку приходило около тридцати обращений в месяц с формулировкой «сервис не открывается», и разбирали их руками — причин могло быть три: кэш, устаревшая запись или отвалившийся сертификат.
Что изменили
Зоны и записи перенесли в Yandex Cloud DNS и описали в Terraform: публичные — декларативно, приватные — привязкой к сетям, чтобы внутренние имена резолвились только внутри контура. За сутки до переключения снизили TTL до минуты, дали старым кэшам истечь и только потом сменили серверы имён у регистратора. Проверку домена для сертификатов перевели на DNS-записи, продление стало автоматическим.
Срез после: доля успешных ответов — 99,9% и выше, разрешение имени укладывается в десятки миллисекунд. Переключение прошло без простоя — окно заняло 40 минут, и всё это время сервис корректно отвечал через оба набора серверов имён. Обращения «не открывается» упали до единичных за месяц, и почти все — из внешних сетей, где кэш провайдера живёт своей жизнью.
Чем приватная DNS-зона отличается от публичной
Публичная зона отвечает на запросы из интернета: её записи отдают авторитативные серверы имён, а родительская зона делегирует на них домен. Приватная зона живёт внутри облачной сети — её видят только запросы оттуда, и делегирования наружу у неё нет. Поэтому одинаково названный домен может существовать в двух зонах сразу и не конфликтовать между собой.
Область видимости записей — главное различие. В публичной зоне любой внешний резолвер получит адрес, и скрыть часть записей не выйдет: поддомены рано или поздно попадают в открытые перечни. В приватной имя для интернета не существует — снаружи запрос вернёт отказ, а изнутри нужный адрес.
На приватной зоне строятся внутренние имена сервисов. Имя вида db.prod.internal создаётся рядом с сетью и не зависит от адресов конкретных инстансов: при замене или масштабировании меняется только запись, а конфигурации приложений остаются прежними. То же имя используется в правилах доступа между сервисами.
При разделении внешнего и внутреннего разрешения одно имя может отвечать разными адресами — снаружи на входную точку, изнутри напрямую на сервис. Так служебный трафик не ходит через внешний периметр, а выбор окружения задаётся зоной, а не правкой кода.
В Yandex Cloud DNS обе зоны описываются декларативно вместе с привязкой к сетям, поэтому состояние воспроизводимо. Сертификаты для внутренних имён выпускает приватный центр сертификации, для публичных — подтверждение владения доменом; и то и другое истекает по расписанию, поэтому обновление ставим регулярной задачей, а не ручной операцией.
Частые вопросы: время жизни записей, миграция, сертификаты
Настройка зоны — это только начало: дальше важнее, как она живёт в эксплуатации. Ниже — ответы на четыре вопроса, которые чаще всего задают перед тем, как забрать площадку в работу.
Зоны, записи, сертификаты и права описываем кодом и храним в репозитории — состояние зоны всегда можно сравнить с описанием и откатить. Это же снимает главную боль передачи: новый инженер видит, почему запись выглядит именно так.
Какое время жизни записей выбрать?
Перед плановым переключением время жизни снижают заранее, чтобы старые адреса перестали оседать в кэше резолверов, а после стабилизации возвращают к спокойному значению. Держать его низким постоянно не стоит: растёт число запросов к зоне. Для статичных записей берут часы, для записей за балансировщиком — минуты.
Как переехать на новую площадку без простоя?
Сначала импортируем текущие записи в описание, сверяем расхождения и только потом переключаем серверы имён, проверяя резолв из нескольких сетей. Старый контур держим до истечения самого длинного времени жизни записи и лишь затем снимаем. Откат — вернуть предыдущее описание зоны.
Как не пропустить продление доменов и сертификатов?
Выпуск и продление сертификатов ставим на автоматику с проверкой валидации на тестовом контуре, а не в день истечения. По доменам и зонам настраиваем оповещения за несколько недель до срока, чтобы продление не превращалось в аварийную работу в выходные.
Что входит в передачу эксплуатации?
Схема зон, описание в репозитории, регламенты выпуска сертификатов и правок записей, разграничение доступов и инструкция по откату. Проводим разбор с вашей командой и остаёмся на связи на период, пока дежурство не перейдёт к вам.
Обсудим вашу схему зон и вернёмся с планом работ
Чтобы оценка работ была не «на глаз», нам достаточно текущей картины зон: какие домены обслуживаются, где зоны публичные, а где приватные внутри Yandex Cloud. Если конфигурация уже описана кодом, пришлите репозиторий или выгрузку; если записи ведутся вручную — хватит перечня и схемы связей.
На созвоне разберём:
- какие зоны публичные, какие приватные и не дублируют ли они друг друга;
- как выдаются сертификаты и где истекают их сроки;
- где остались ручные правки и что мешает перенести их в описание инфраструктуры;
- как настроено делегирование и куда указывают NS-записи;
- какие сервисы зависят от DNS и что произойдёт при недоступности зоны;
- нужна ли защита от подмены ответов и контроль целостности;
- как разделены права доступа к зонам внутри команды.
Что прислать заранее:
- список доменов и поддоменов с назначением;
- схему сетей: где живут сервисы и кому нужны внутренние имена;
- текущие конфигурации или выгрузку зон;
- перечень сертификатов и мест, где они используются.
После этого вернёмся с оценкой и планом внедрения: очередность переноса зон, способ описания конфигурации, точки проверки и порядок отката. Опишите задачу в двух абзацах — этого хватит, чтобы назвать сроки и состав работ.
