Как делегировать поддомен на отдельные NS и проверить границу зоны

Чтобы делегировать поддомен на отдельные DNS-серверы, сначала создайте и проверьте дочернюю зону у нового DNS-провайдера, а затем добавьте NS-записи для поддомена в родительской зоне. Схема работает, когда родитель указывает на нужные NS, каждый из них авторитетно отвечает за дочернюю зону, а полный DNS-путь приводит к ожидаемой записи.

Ключевая мысль: NS внутри самой дочерней зоны недостаточно. Граница зоны возникает на стороне родителя. Если shop.example.com должен обслуживаться отдельно от example.com, именно зона example.com передаёт управление именем shop другому набору NS.

Что меняется при делегировании поддомена

Делегирование — не замена A- или CNAME-записи. Оно создаёт отдельную DNS-зону и передаёт ей ответственность за имя поддомена и всё, что находится ниже него.

После появления границы записи вида www.shop.example.com, оставленные только в родительской зоне, больше не участвуют в обычном разрешении. Их нужно заранее создать в дочерней зоне. На границе родитель хранит делегирующие NS, а дочерняя зона — собственные SOA и NS плюс записи сервисов.

Отдельная зона полезна, когда поддоменом управляет другая команда, нужен иной DNS-провайдер или сервис переносится независимо. Если требуется направить одно имя на другой хост, обычно достаточно A, AAAA или CNAME.

Что подготовить до изменения NS

Возьмём условный shop.example.com. Зафиксируйте все рабочие имена ниже него, ожидаемый набор новых NS, текущие TTL, использование DNSSEC и старую схему для отката.

Сначала создайте дочернюю зону у нового DNS-провайдера. Перенесите нужные A, AAAA, CNAME, MX, TXT и другие записи. Не рассчитывайте, что данные ниже будущей границы продолжат читаться из родительской зоны.

Порядок делегирования

1. Проверьте дочернюю зону напрямую

Новые NS должны обслуживать зону ещё до изменения родителя. Запросите SOA и NS у каждого сервера без рекурсии:

dig @ns1.dns-provider.example shop.example.com SOA +norecurse
dig @ns1.dns-provider.example shop.example.com NS +norecurse
dig @ns2.dns-provider.example shop.example.com SOA +norecurse
dig @ns2.dns-provider.example shop.example.com NS +norecurse

Ищите флаг aa, ожидаемый SOA и одинаковый рабочий набор NS. Затем напрямую запросите несколько критичных имён, например адрес сайта и API. Если один сервер отвечает иначе или не считает себя авторитетным, переключать родителя рано.

2. Добавьте NS в родительской зоне

В зоне example.com создайте делегирование для имени shop:

shop.example.com.  IN  NS  ns1.dns-provider.example.
shop.example.com.  IN  NS  ns2.dns-provider.example.

NS нужно добавить именно у оператора родительской зоны. Для поддомена обычно не требуется менять серверы всего домена у регистратора.

3. Отдельно учтите glue и DNSSEC

Если сервер называется ns1.shop.example.com, его адрес расположен внутри делегируемой зоны. Тогда родителю нужны glue-записи A и/или AAAA, иначе возникает круг: чтобы узнать адрес NS, резолверу уже нужен этот NS. Подробная проверка есть в материале про glue-записи и собственные NS.

Для внешних имён вроде ns1.dns-provider.example такой круг обычно не возникает: их адреса разрешаются через другую DNS-цепочку.

Если дочерняя зона подписана DNSSEC, DS публикуется в родительской зоне. Добавляйте его только после проверки DNSKEY и подписей на дочерних NS. Неверный или устаревший DS способен вызвать SERVFAIL у валидирующих резолверов.

Как проверить границу зоны после изменения

Обычный dig NS shop.example.com через локальный резолвер может показать кэш, поэтому проверяйте родительскую и дочернюю стороны отдельно.

Запросите родительский NS

Сначала узнайте авторитетные серверы родителя:

dig example.com NS

Затем обратитесь к одному из них напрямую:

dig @ns-parent.example shop.example.com NS +norecurse

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

Запросите каждый дочерний NS

Повторите прямые запросы SOA, NS и критичных записей у каждого сервера. Важно не просто получить IP, а увидеть авторитетный ответ именно за shop.example.com.

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

Пройдите всю цепочку

dig +trace www.shop.example.com A

В трассировке найдите делегирование shop.example.com, новые NS и финальный ответ дочерней зоны. Затем сравните результат через несколько независимых рекурсивных резолверов или сетей. Кратковременная разница может быть следствием кэша, а постоянное расхождение требует сверить NS у родителя и ребёнка.

Как читать типичные симптомы

| Симптом | Что проверить | |---|---| | Прямой запрос к новому NS работает, обычный — нет | Есть ли NS для поддомена у родителя | | Родитель отдаёт нужные NS, один отвечает без aa | Загружена ли зона на этом сервере | | NS внутри дочерней зоны и не находится | Есть ли корректный glue у родителя | | У серверов разные NS или записи | Синхронизацию зоны и конфигурацию | | После включения DNSSEC появился SERVFAIL | Соответствуют ли DS и DNSKEY | | Имя ниже поддомена пропало | Перенесена ли запись в дочернюю зону |

TTL влияет на время жизни кэша, но не исправляет отсутствующее делегирование, неверный glue, неавторитетный сервер или ошибочную цепочку DNSSEC.

Как переключить с возможностью отката

Рабочая последовательность проста: подготовьте дочернюю зону на всех NS, проверьте её напрямую, добавьте делегирование у родителя, выполните +trace и сравните ответы из независимых сетей.

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

Что контролировать после переключения

Разовая DNS-проверка подтверждает состояние только в конкретный момент. После изменения полезно контролировать и критичный URL: корректное делегирование ещё не гарантирует, что сайт или API отвечает по HTTP.

Web-Puls помогает регулярно проверять доступность сайта и быстрее узнавать, если после DNS-изменений он перестал открываться. Если ответы родителя и дочерних NS расходятся, появляется SERVFAIL или поддомен работает лишь из части сетей, отправьте заявку на профессиональную поддержку: укажите домен, время и часовой пояс изменения, старые и новые NS и очищенный вывод dig, но не передавайте пароли, ключи и закрытые адреса.