# Делегирование поддомена на чужие NS-серверы

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

## Что такое делегирование поддомена

Делегирование поддомена — это передача управления отдельной веткой зоны на другие NS-серверы, без переноса всего домена. Например, `shop.example.com` может обслуживаться DNS-серверами платформы интернет-магазина, пока `example.com` остаётся на серверах ZevsHost. Родительская зона хранит только NS-записи, указывающие, кто отвечает за поддомен, а все A, CNAME и TXT-записи поддомена живут уже на чужих серверах.

Такая схема нужна, когда поддомен подключают к внешнему сервису: CDN, платформе рассылок, отдельному облаку или партнёрской системе, у которой есть свои требования к [DNS-записям](https://www.zevshost.net/ru/kb/kak-rabotat-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-зоны](https://www.zevshost.net/ru/kb/proverka-dns-zony-dig/). Дополнительно опросите сами делегированные серверы напрямую:

```
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 записей внутри поддомена, чтобы изменения применялись быстро.

---

Источник: https://www.zevshost.net/ru/kb/delegirovanie-poddomena/