Делегирование поддоменов: NS для sub.domain и независимое управление

Делегирование поддоменов — это механизм DNS, позволяющий передать управление частью зоны (например, sub.domain.tld) независимому набору авторитетных серверов имен. Это ключевой инструмент для крупных проектов и командной изоляции: можно раздать ответственность за подзону подрядчику или другому отделу, не меняя и не рискуя всей зоной верхнего уровня.

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

Практические сценарии, где subdelegation экономит время и снижает риски:

• Изоляция ответственности: у продакшн-зоны строгие процессы, а у экспериментальной подсистемы (например, dev.domain.tld) быстрые релизы. Подзону можно отдать команде разработки.
• Разные провайдеры DNS: основной домен обслуживается одним провайдером, а подзона с высокими требованиями к геораспределению — другим.
• Интеграции и партнёрки: SaaS-платформа требует собственные записи для кастомного поддомена. Передаём подзону на их NS.
• Разграничение доступа: внешним администраторам даётся контроль только над shop.domain.tld, а не над всем доменом.
• Сложные архитектуры: «склейка» разных стэков и команд в одной доменной иерархии, без конфликтов в управлении записями.

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

Как работает «разрез зоны» и делегирование

В DNS существует понятие «разрез зоны» (zone cut). Это точка, в которой ответственность за ответы переходит от родительской зоны к дочерней. Для sub.domain.tld разрез происходит в родительской зоне domain.tld: там размещаются NS-записи для sub, указывающие на авторитетные серверы дочерней зоны. С этого момента родитель отвечает только за делегирование (и, при необходимости, за glue-записи), а содержимое дочерней зоны управляется независимо.

Важно: в точке делегирования нельзя использовать CNAME. Делегирование — это NS-записи на уровне поддомена в родительской зоне. Любые другие записи в этой точке противоречат модели и вызывают непредсказуемое поведение.

NS и glue: когда нужны адреса в родительской зоне

Резолверу, дойдя до domain.tld, нужно узнать, куда идти дальше за ответами для sub.domain.tld. Для этого у него есть NS-записи дочерней зоны. Но чтобы обратиться к серверу, нужен IP-адрес его имени. Если имена NS лежат внутри самой делегируемой зоны (in-bailiwick), в родительской зоне потребуется добавить glue-записи (A/AAAA), чтобы разрез не превращался в курицу и яйцо.

Вариант 1: NS вне дочерней зоны (out-of-bailiwick)

Если NS — это, например, ns1.example.net. и ns2.example.net., то IP этих имен резолвятся независимо, и glue в родительской зоне не нужен. Это самый простой случай: достаточно NS-записей в родительской зоне.

Вариант 2: NS внутри дочерней зоны (in-bailiwick)

Если NS — это ns1.sub.domain.tld. и ns2.sub.domain.tld., то резолвер без glue не сможет получить их IP: чтобы узнать адрес ns1.sub.domain.tld., ему как раз нужна зона sub.domain.tld, делегированная на этот же сервер. Решение — добавить в родительской зоне A/AAAA для этих имен. Это и есть glue-записи.

TTL glue-записей в родительской зоне влияет на скорость смены IP у NS. При плановых миграциях временно снижайте TTL, затем возвращайте на более высокий уровень.

Пошаговая настройка: пример

Предполагаем, что у вас есть доступ к редактированию зоны domain.tld у текущего провайдера DNS и вы хотите делегировать sub.domain.tld на отдельные NS. Ниже для наглядности — синтаксис BIND, но те же сущности есть в любом DNS-провайдере.

Родительская зона: делегирование

Случай без glue (NS вне дочерней зоны):

$ORIGIN domain.tld.
$TTL 3600
sub            3600    IN      NS      ns1.dns-provider.net.
sub            3600    IN      NS      ns2.dns-provider.net.

Случай с glue (NS внутри дочерней зоны):

$ORIGIN domain.tld.
$TTL 3600
sub            3600    IN      NS      ns1.sub.domain.tld.
sub            3600    IN      NS      ns2.sub.domain.tld.
ns1.sub        300     IN      A       192.0.2.10
ns1.sub        300     IN      AAAA    2001:db8::10
ns2.sub        300     IN      A       192.0.2.11
ns2.sub        300     IN      AAAA    2001:db8::11

Обратите внимание на TTL: NS у нас 3600 секунд, а glue — 300 секунд, чтобы IP NS можно было оперативно менять.

Дочерняя зона: содержимое и SOA

На стороне новой авторитетной зоны sub.domain.tld создаём зону с SOA, NS и прочими записями:

$ORIGIN sub.domain.tld.
$TTL 300
@       IN  SOA ns1.sub.domain.tld. dns-admin.domain.tld. (
            2025010101 ; serial
            3600       ; refresh
            900        ; retry
            1209600    ; expire
            300        ; minimum
)
        IN  NS  ns1.sub.domain.tld.
        IN  NS  ns2.sub.domain.tld.
; сервисные записи
@       IN  A   198.51.100.42
www     IN  CNAME   @
api     IN  A   198.51.100.43

Убедитесь, что имена NS в дочерней зоне совпадают с теми, что объявлены в родительской, и что сервера реально авторитетны (они обслуживают эту зону и отвечают с флагом aa). Собственный авторитетный DNS удобно держать на изолированном сервере — например, на VDS.

Проверка делегирования: dig и что смотреть

После внесения записей и ожидания TTL стоит проверить цепочку резолвинга по шагам.

Проверить NS в родительской зоне:

dig NS sub.domain.tld +norecurse @parent-auth-ns.example

Ожидаем получить именно те NS, которые мы указали. Флаг aa укажет, что ответ авторитетный. Если используете публичные резолверы для проверки — учтите возможные кэши, добавляйте +trace.

Полный трассинг:

dig +trace www.sub.domain.tld A

Здесь важно, чтобы на шаге domain.tld. пришли NS для sub, а затем уже от дочерних NS — конечная A/AAAA. Если NS внутри дочерней зоны, в ответе родителя вы увидите также glue-адреса.

Проверка авторитетности дочерней зоны:

dig SOA sub.domain.tld @ns1.sub.domain.tld

В ответе должен быть установлен флаг aa, а SOA совпадать с той зоной, которую вы подготовили.

TTL-стратегия: перед и после запуска

Чтобы переключение прошло гладко, перед установкой делегирования уменьшайте TTL:

• В родительской зоне: TTL у NS и у glue (A/AAAA для NS-имен внутри подзоны) — до 300 секунд.
• В дочерней зоне: базовый $TTL и SOA minimum также временно понижаем для быстрой коррекции записей.

Через несколько часов после успешной проверки поднимайте TTL обратно, чтобы снизить нагрузку на авторитетные сервера и улучшить кэшируемость.

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

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

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

DNSSEC: DS для дочерней зоны

Если родительская зона подписана, и вы хотите, чтобы дочерняя зона тоже была валидируема, в родительской зоне нужно разместить DS-запись дочерней зоны. Процедура:

1. Подписать зону sub.domain.tld (создать KSK и ZSK, опубликовать соответствующие DNSKEY в дочерней зоне).
2. Сгенерировать DS на основе KSK дочерней зоны.
3. Добавить DS в родительскую зону в точке делегирования sub.domain.tld.

После этого цепочка доверия будет непрерывной: корень → TLD → domain.tld → sub.domain.tld. Не забывайте об операциях ротации ключей: сначала публикуйте новые ключи и DS, затем удаляйте старые после безопасной экспозиции.

DS публикуется в родительской зоне, а не в реестре TLD (как для домена второго уровня). Это упрощает эксплуатацию: вы сами контролируете цепочку доверия для подзоны.

Обслуживание и мониторинг

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

• Мониторьте доступность NS дочерней зоны с внешних точек. Простые dig-проверки по расписанию обнаружат «lame» делегирование.
• Следите за серийным номером SOA и согласованностью вторичных серверов (если используете AXFR/IXFR). Убедитесь, что вторички актуальны.
• Логируйте ошибки авторитетных серверов дочерней зоны и аномалии трафика. Пики NXDOMAIN подскажут о неверных ссылках или атаках.
• Периодически сверяйте NS у родителя и у дочерней зоны, чтобы не было расхождений после миграций.

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

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

Подробнее

Типичные ошибки и как их избежать

• Отсутствуют glue при NS внутри подзоны. Симптом: резолверы не могут получить IP NS. Решение: добавить A/AAAA в родительскую зону и снизить TTL на время запуска.
• Несоответствие NS у родителя и у дочерней зоны. Это приводит к предупреждениям и «lame» делегированию. Держите конфигурации синхронными.
• CNAME в точке делегирования. Нельзя. В точке sub должны быть только NS (и DS, если используется DNSSEC).
• Слишком высокий TTL в стартовый период. Любая ошибка будет кэшироваться долго. На этапе изменений снижайте TTL заранее.
• Закрытые авторитетные NS. Фильтрация по IP, блокировка EDNS-расширений или большие ответы без фрагментации могут ломать резолвинг. Проверяйте ответы с разных сетей.
• DNSSEC без публикации DS у родителя. Зона подписана, но цепочка обрывается — валидация провалится. Публикуйте DS в родительской зоне.
• AXFR/IXFR недоступны вторичному NS. Если используете вторички, убедитесь, что allow-transfer и сетевые правила настроены корректно.
• Конфликты записей на границе «разреза». Наличие других записей в родительской зоне на том же имени, где стоят NS, нарушает модель. Держите делегирование «чистым».

Миграция NS у поддомена без простоя

Когда нужно сменить провайдера или инфраструктуру для подзоны, действуйте по плану:

1. На новой стороне подготовьте полную копию зоны sub.domain.tld, включив SOA, NS и все ресурсные записи. Тестируйте локально.
2. Снизьте TTL у NS и у glue в родительской зоне, а также базовый TTL дочерней зоны — за 24 часа до переключения.
3. Если NS внутри подзоны — заранее добавьте новые glue-адреса с маленьким TTL, чтобы их прокэшировали.
4. Обновите NS в родительской зоне на новые имена. Подождите несколько TTL и проверьте dig +trace из разных регионов.
5. Поддерживайте старые NS в актуальном состоянии в течение периода дренирования кэшей (обычно 24–48 часов), затем выключайте.
6. Верните TTL на операционные значения.

Если параллельно переносите домен между регистраторами, учтите нюансы сроков и DNS у реестра. Подробно тема разобрана в материале «Перенос домена по EPP-коду и влияние на DNS» — смотрите раздел перенос домена по EPP.

Особенности кэширования и негативные ответы

Кэши резолверов учитывают TTL отдельных записей: NS, glue (A/AAAA для NS-имен), а также негативное кэширование по SOA minimum (RFC 2308). Это означает, что ошибки и пустые ответы тоже «живут» в кэше, замедляя восстановление после исправлений. Планируйте снижение SOA minimum в дочерней зоне на время активных изменений.

Взаимодействие с балансировкой и геораспределением

• Убедитесь, что все NS стабильно авторитетны и корректно синхронизированы.
• Не делайте NS-имена CNAME — только прямые имена с A/AAAA (или stable alias на уровне провайдера, если он эмулирует A/AAAA на своей стороне).
• Поддерживайте минимально необходимый набор NS: обычно 2–4, лишние NS без пользы усложняют диагностику.

Если делегируете подзону под выдачу wildcard-сертификатов через DNS-01, пригодится пошаговая автоматизация DNS-01 для wildcard SSL.

Разделение на уровне доступа и процессов

Главный плюс subdelegation — операционная изоляция. Команда, которая управляет sub.domain.tld, не имеет возможности сломать domain.tld, и наоборот. Отдельное журналирование, отдельные роли доступа и независимые окна обслуживания снижают риск масштабных инцидентов. Если у вас несколько вендоров DNS, заранее согласуйте формат экспорта зон и поведение при отказе (secondary DNS, notifies, форматы IXFR).

Частые вопросы

Можно ли делегировать «глубокий» поддомен, вроде a.b.sub.domain.tld? Да, делегировать можно любой узел, на котором нет других записей, кроме NS (и DS, если используется DNSSEC). Глубина не ограничена.

Нужно ли регистратору TLD сообщать об этом? Нет. Делегирование подзоны полностью контролируется родительской зоной domain.tld. Исключение — сам домен второго уровня и его NS/DS управляются через реестр.

Что такое «lame delegation»? Это когда у родителя заявлены NS для подзоны, но эти NS не отвечают авторитетно. Причины: не загружена зона, закрыт порт 53, несогласованные имена или ошибки конфигурации. Лечится синхронизацией и мониторингом.

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

Влияют ли wildcard-записи в родительской зоне на подзону? Нет. После разреза зоны wildcard родителя не применяется к дочерней зоне; дочерняя зона — самостоятельный административный домен.

Итоги

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