Делегирование DNS-зон на поддомены: отдельные NS для prod/stage/dev без боли

Зачем вообще делегировать поддомены отдельными NS

Схема «одна DNS-зона на весь домен» начинает мешать, когда окружения живут по разным правилам: prod должен быть максимально стабильным и консервативным по ttl, stage — часто менять адреса/балансеры, dev — экспериментировать (вплоть до приватных сетей и стендов, которые поднимаются на часы).

Делегирование (zone delegation) позволяет отдать управление поддоменом в отдельную DNS-зону со своими authoritative NS, не трогая остальную зону. Это удобно и организационно (разные владельцы), и операционно (разные SLA/TTL/автоматизация).

Критически важно понимать: делегирование — это не «ещё одна A-запись». Вы меняете цепочку авторитетности. Родительская зона (например, example.com) сообщает миру: «за dev.example.com отвечают вот эти NS». После этого запросы к именам внутри подзоны должны уходить к authoritative серверам подзоны.

• Разделение ответственности: prod ведёт ops-команда, dev — разработчики, stage — CI/CD.

• Разные требования к отказоустойчивости: для prod два-три NS в разных сетях, для dev иногда достаточно одного (если риск приемлем).

• Разный жизненный цикл: в dev записи живут часами, в prod — месяцами.

• Интеграция с разными провайдерами: stage управляется через DNS API одного сервиса, prod — через другой.

Ключевая идея: NS в родителе + отдельная зона у делегата

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

1. В родительской зоне создаёте NS-записи для поддомена (например, stage.example.com). Это «указатель», куда идти за ответами.

2. На стороне делегата создаёте отдельную DNS-зону stage.example.com и наполняете её записями (A/AAAA/CNAME/MX/TXT и т.д.) с корректным soa.

Если сделать только NS в родителе и забыть поднять зону на указанных NS — получите SERVFAIL или таймауты. Если сделать только зону «где-то там», но не добавить NS в родителе — внешний мир до неё не «дойдёт» (цепочка делегирования не построена).

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

Практический пример: prod/stage/dev как отдельные зоны

Представим домен example.com. Хотим:

• prod.example.com — обслуживается отдельной парой NS (максимальная стабильность, ручные изменения редки).

• stage.example.com — обслуживается другой парой NS, управляется автоматизацией.

• dev.example.com — может обслуживаться одним NS и короткими TTL (если для вас это приемлемо).

В родительской зоне example.com добавляете NS-записи (логически должно получиться так):

prod.example.com.  3600  IN  NS  ns1.prod-dns.example.net.
prod.example.com.  3600  IN  NS  ns2.prod-dns.example.net.

stage.example.com. 3600  IN  NS  ns1.stage-dns.example.net.
stage.example.com. 3600  IN  NS  ns2.stage-dns.example.net.

dev.example.com.   3600  IN  NS  ns1.dev-dns.example.net.

Дальше на серверах ns1.stage-dns.example.net и ns2.stage-dns.example.net должна существовать authoritative зона stage.example.com со своим soa и набором записей.

Если вам нужно параллельно держать разные окружения с разными правилами доступности, полезно заранее зафиксировать «границы ответственности»: в родителе остаются только NS (и при необходимости DS для DNSSEC), всё остальное — в делегированной зоне.

Регистрация доменов от 99 руб.

Каждый проект заслуживает идеального доменного имени, выберите один из сотни, чтобы начать работу!

Зарегистрировать домен

SOA и TTL: как не устроить себе «всё не обновляется»

Поля ttl и параметры soa — не для красоты. Они определяют скорость распространения изменений и предсказуемость кеширования у резолверов.

TTL для NS делегирования

У NS-записей в родительской зоне тоже есть TTL. Если вы планируете миграцию (меняете NS для stage), заранее уменьшайте TTL у NS поддомена, иначе старые значения останутся в кешах резолверов и переключение будет «рваным».

• в обычной жизни: TTL 3600–14400 для NS делегирования (зависит от вашей терпимости к задержкам изменений);

• перед миграцией: за 24–48 часов уменьшить TTL до 300–600;

• после стабилизации: вернуть назад.

SOA внутри подзоны

Каждая делегированная зона самостоятельна. У неё должен быть свой SOA и корректный serial. Если у вас master/slave (или primary/secondary), то serial — это триггер обновлений (IXFR/AXFR), и его дисциплина важнее, чем «красивое значение».

SOA родительской зоны не управляет кешированием записей в подзоне. Маленький TTL в example.com не ускорит обновление A-записи в stage.example.com, если в самой stage-зоне TTL большой.

Практика: заведите отдельные дефолтные TTL для зон prod/stage/dev и не пытайтесь «унифицировать всё» в ущерб здравому смыслу.

Glue records: когда они нужны, а когда нет

Glue — это A/AAAA-записи для NS, которые лежат в той же зоне, которую вы делегируете (или ниже). Без glue может получиться циклическая зависимость: чтобы узнать IP NS, нужно спросить DNS у этих же NS.

Если ваши NS для поддомена находятся внутри этого поддомена (например, ns1.dev.example.com обслуживает dev.example.com), вам почти наверняка нужен glue в родительской зоне.

Два типовых сценария:

• NS вне делегируемой зоны: ns1.dev-dns.example.net. Glue обычно не нужен, потому что имя NS резолвится в независимой зоне.

• NS внутри делегируемой зоны: ns1.dev.example.com. Glue нужен в родительской зоне example.com (а на уровне домена второго уровня glue в итоге публикуется в зоне TLD/реестра и кэшируется по пути).

Split-horizon и prod/stage/dev: где чаще всего стреляют в ногу

Split-horizon DNS — это когда один и тот же домен/поддомен отвечает по-разному в зависимости от того, откуда спрашивают (внутри сети или снаружи). Иногда это осознанный дизайн (например, внутренние IP для dev), но при делегировании легко получить «случайный split-horizon», который выглядит как хаос.

Типовая проблема №1: внутренний резолвер переопределяет делегирование

В компании могут быть свои резолверы, которые хостят зону example.com целиком (как authoritative или как локальную «стаб-зону»), включая dev.example.com. Тогда внешнее делегирование, которое вы добавили в публичном DNS, внутри сети будет игнорироваться.

Что делать: либо делегировать и внутри (то есть на внутренних authoritative тоже выставить NS на подзону), либо явно договориться, что внутренняя DNS не «держит» родительскую зону целиком и ходит во внешний мир за делегированными кусками.

Типовая проблема №2: записи подзоны остались в родителе

Например, вы делегировали stage.example.com, но в родительской зоне осталась запись api.stage.example.com «по привычке». При корректном делегировании запросы за *.stage.example.com должны уходить в подзону, но при ошибках конфигурации, DNSSEC-несостыковках или некорректной работе кешей это превращается в трудноотлавливаемые симптомы.

Практический подход: после делегирования удаляйте из родительской зоны все записи, относящиеся к подзоне, кроме NS (и, при необходимости, DS). Граница ответственности должна быть жёсткой.

Как проверять делегирование: dig +trace как обязательный ритуал

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

Проверьте, что родитель реально отдаёт NS для поддомена:

dig NS stage.example.com

Посмотрите трассу делегирования (кто на кого ссылается):

dig +trace NS stage.example.com

Дальше спросите конкретный NS из делегирования и убедитесь, что он авторитетен и отдаёт SOA:

dig @ns1.stage-dns.example.net SOA stage.example.com

Если вы не видите NOERROR и секции AUTHORITY с SOA, проблема на стороне делегированной зоны (или у конкретного NS).

Полезно также проверить каждый NS по отдельности и сравнить ответы (особенно если зона реплицируется):

dig @ns1.stage-dns.example.net A api.stage.example.com
dig @ns2.stage-dns.example.net A api.stage.example.com

Проектирование зон под окружения: минимальный набор правил

1) Не делегируйте без причины

Каждая новая зона — это новые точки отказа, отдельный мониторинг, отдельные процессы обновления и отдельные баги в автоматизации. Делегирование оправдано, когда действительно нужно разделение ответственности/рисков или разные провайдеры/контуры управления.

2) Стабильность prod начинается с DNS-операционки

Для prod избегайте слишком маленьких TTL «на всякий случай». Маленький TTL увеличивает нагрузку на authoritative NS и резолверы, а при инциденте (включая перегрузки) вы быстрее упрётесь в лимиты.

Часто рабочая схема такая: 300–600 только для записей, которые реально могут меняться (фейловер/балансеры), и 3600–14400 для стабильных.

3) stage/dev — место для коротких TTL и автоматизации, но без самообмана

Для stage и dev короткие TTL помогают CI/CD поднимать preview-окружения и переключать CNAME «на лету». Но слишком короткие TTL усложняют расследования (в логах резолверов и у провайдера) и могут маскировать ошибки, которые в prod проявятся иначе.

4) Версионируйте зоны как код

Для делегированных зон особенно важно хранить конфигурацию в репозитории и иметь историю изменений: кто и когда поменял NS, ttl, записи сервисов. Даже если вы используете панель, стремитесь к декларативной модели (шаблоны, экспорт, API).

Если часть окружений живёт на отдельной инфраструктуре (например, выделенные NS на собственной виртуализации), то для изоляции и управляемости часто удобнее держать DNS-сервисы на VDS и разнести NS по разным площадкам.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Сценарий миграции NS для поддомена: безопасный план

Если нужно поменять DNS-провайдера для stage.example.com (или перенести подзону на другие NS), действуйте как при обычной DNS-миграции, но учитывайте, что меняются именно NS делегирования.

1. Снизьте TTL NS-записей для поддомена в родительской зоне (например, до 300) заранее.

2. Поднимите новую authoritative зону на новых NS, полностью скопируйте записи, проверьте SOA и serial.

3. Сравните ответы старых и новых NS на ключевые имена (A/AAAA/CNAME/TXT) прямыми запросами через dig @.

4. Переключите NS-записи поддомена в родительской зоне на новые.

5. Держите старые NS в рабочем состоянии минимум время, равное старому TTL делегирования и TTL критичных записей, чтобы не поймать «дыры» у клиентов со старым кешем.

6. После стабилизации верните TTL к обычным значениям.

Если на домене включён DNSSEC, добавьте к плану отдельный этап с DS/ключами и обязательно проверьте, что новая зона подписана корректно, иначе получите массовый SERVFAIL. Для смежных тем по доменам может пригодиться материал про перенос домена и смену DNS.

Частые ошибки и симптомы

«То работает, то нет»

Обычно это смесь старых и новых NS из-за кеша (TTL), либо один из NS недоступен/не авторитетен. Проверяйте доступность каждого NS и одинаковость зон (особенно при master/slave).

SERVFAIL при trace

Часто встречается, когда в родительской зоне NS указывают на серверы, где зона не создана, или когда DNSSEC/DS настроен неконсистентно. Начинайте диагностику с проверки SOA на каждом NS.

NS есть, но A/AAAA не резолвится

Вероятно, запись добавили в родительскую зону «по привычке». После делегирования родительская зона не отвечает за имена внутри подзоны: нужные записи должны быть в делегированной зоне.

Итог: делегирование под prod/stage/dev как управляемая сложность

Делегирование поддоменов через NS — мощный инструмент для инфраструктуры с несколькими окружениями. Ключ к успеху — помнить, что вы меняете и родительскую зону, и делегированную, и обязаны контролировать ttl и soa.

Чтобы не утонуть в «фантомных» проблемах, всегда проверяйте реальную цепочку делегирования через dig +trace и прямые запросы к каждому authoritative NS. Держите границы зон строгими, документируйте ответственность за prod/stage/dev и избегайте случайного split-horizon. Тогда DNS перестанет быть «магией» и станет предсказуемым слоем инфраструктуры.

Если домен — критичный актив, дополнительно посмотрите про защиту доменного имени: это хорошо дополняет дисциплину вокруг NS, делегирования и процессов изменений.