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

> Делегування піддомену передає керування окремою зоною на чужі NS-сервери без зміни записів в основній зоні домену.

## Що таке делегування піддомену

Делегування піддомену — це передавання керування окремою гілкою зони на інші NS-сервери, без перенесення всього домену. Наприклад, `shop.example.com` може обслуговуватися DNS-серверами платформи інтернет-магазину, поки `example.com` залишається на серверах ZevsHost. Батьківська зона зберігає лише NS-записи, які вказують, хто відповідає за піддомен, а всі A, CNAME і TXT-записи піддомену живуть уже на чужих серверах.

Така схема потрібна, коли піддомен підключають до зовнішнього сервісу: CDN, платформи розсилок, окремої хмари чи партнерської системи, у якої свої вимоги до [DNS-записів](https://www.zevshost.net/uk/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/uk/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/uk/kb/delegirovanie-poddomena/