Что такое делегирование поддомена
Делегирование поддомена — это передача управления отдельной веткой зоны на другие NS-серверы, без переноса всего домена. Например, shop.example.com может обслуживаться DNS-серверами платформы интернет-магазина, пока example.com остаётся на серверах ZevsHost. Родительская зона хранит только NS-записи, указывающие, кто отвечает за поддомен, а все A, CNAME и TXT-записи поддомена живут уже на чужих серверах.
Такая схема нужна, когда поддомен подключают к внешнему сервису: CDN, платформе рассылок, отдельному облаку или партнёрской системе, у которой есть свои требования к DNS-записям.
Как прописать делегирование в родительской зоне
Делегирование задаётся NS-записями для имени поддомена. В зоне example.com добавляют:
shop IN NS ns1.partner-dns.com.
shop IN NS ns2.partner-dns.com.Обратите внимание на точку в конце имени сервера — она означает полное доменное имя (FQDN) и обязательна в зонных файлах BIND. После добавления записей никаких A или CNAME для shop.example.com в основной зоне быть не должно: они будут игнорироваться, потому что за имя теперь отвечают внешние NS.
Партнёр должен поднять зону shop.example.com на указанных серверах и добавить туда собственные A, MX и другие записи — иначе делегирование будет указывать в пустоту.
Glue-записи: когда без них не обойтись
Если NS-серверы поддомена сами находятся внутри того же домена — например, ns1.shop.example.com — возникает циклическая зависимость: чтобы узнать IP сервера ns1, нужно спросить его же самого. Эту проблему решают glue-записи — A-записи для NS-сервера, которые публикуются прямо в родительской зоне рядом с делегированием:
shop IN NS ns1.shop.example.com.
ns1.shop IN A 203.0.113.10Если NS-серверы поддомена находятся в чужом домене (как в примере с partner-dns.com), glue-записи не нужны — резолвер и так может найти их IP через обычный DNS-запрос.
Проверка делегирования после настройки
После публикации зоны проверьте, что делегирование действительно работает:
dig shop.example.com NS +traceВ ответе должны появиться NS-серверы партнёра, а не старые серверы example.com. Подробный разбор команды dig и типовых ответов серверов — в статье про проверку DNS-зоны. Дополнительно опросите сами делегированные серверы напрямую:
dig shop.example.com A @ns1.partner-dns.comЕсли ответ приходит, зона поднята и делегирование рабочее. Если получаете REFUSED или таймаут — зона на стороне партнёра ещё не настроена.
Типичные ошибки делегирования
| Проблема | Причина |
|---|---|
| Поддомен не резолвится нигде | Забыли создать зону на делегированных серверах |
| Работает у части пользователей | Старый TTL NS-записи ещё не истёк в кэше резолверов |
| SERVFAIL при запросе A-записи | Нет glue-записи для NS внутри того же домена |
| Делегирование не подтверждается через dig +trace | Опечатка в имени NS-сервера или лишняя точка |
Чек-лист делегирования поддомена
- Уточните у партнёра точные имена NS-серверов и не используйте IP вместо имён.
- Добавьте NS-записи в родительскую зону, без сопутствующих A и CNAME для того же имени.
- Настройте glue-записи, если NS-сервер сам входит в делегируемый или родительский домен.
- Проверьте делегирование через
dig +traceс двух разных резолверов. - Согласуйте с партнёром TTL записей внутри поддомена, чтобы изменения применялись быстро.