# Delegating a Subdomain to Third-Party NS Servers

> Delegating a subdomain hands control of a separate zone to third-party NS servers without touching records in the main domain zone.

## What subdomain delegation is

Delegating a subdomain hands control of a separate branch of the zone to other NS servers, without moving the whole domain. For example, `shop.example.com` can be served by the DNS servers of an online store platform while `example.com` itself stays on ZevsHost servers. The parent zone keeps only the NS records pointing to who is responsible for the subdomain, while all A, CNAME and TXT records of the subdomain live on the third-party servers.

This setup is needed when a subdomain connects to an external service: a CDN, a mailing platform, a separate cloud, or a partner system with its own requirements for [DNS records](https://www.zevshost.net/en/kb/kak-rabotat-dns/).

## How to set up delegation in the parent zone

Delegation is defined by NS records for the subdomain name. In the `example.com` zone, add:

```
shop     IN NS  ns1.partner-dns.com.
shop     IN NS  ns2.partner-dns.com.
```

Note the trailing dot after the server name — it marks a fully qualified domain name (FQDN) and is required in BIND zone files. After adding these records, there must be no A or CNAME records for `shop.example.com` left in the main zone: they would be ignored, because the external NS servers now own that name.

The partner must set up the `shop.example.com` zone on the listed servers and add their own A, MX and other records there — otherwise the delegation points nowhere.

## Glue records: when you cannot skip them

If the subdomain's NS servers themselves sit inside the same domain — for example, `ns1.shop.example.com` — a circular dependency appears: to learn the IP of ns1, you would need to ask that same server. Glue records solve this problem — A records for the NS server, published directly in the parent zone next to the delegation:

```
shop        IN NS  ns1.shop.example.com.
ns1.shop    IN A   203.0.113.10
```

If the subdomain's NS servers sit in a third-party domain (as in the `partner-dns.com` example), glue records are not needed — a resolver can find their IP through a normal DNS query anyway.

## Checking delegation after setup

After publishing the zone, check that delegation actually works:

```
dig shop.example.com NS +trace
```

The answer should show the partner's NS servers, not the old `example.com` servers. A detailed walkthrough of the dig command and typical server answers is in the article on [checking a DNS zone](https://www.zevshost.net/en/kb/proverka-dns-zony-dig/). Also query the delegated servers directly:

```
dig shop.example.com A @ns1.partner-dns.com
```

If you get an answer, the zone is up and delegation works. If you get `REFUSED` or a timeout, the zone has not been configured on the partner's side yet.

## Common delegation mistakes

| Problem | Cause |
| --- | --- |
| Subdomain does not resolve anywhere | The zone was never created on the delegated servers |
| Works for some users only | The old NS record TTL has not expired in resolver caches yet |
| SERVFAIL when querying the A record | Missing glue record for an NS server inside the same domain |
| Delegation is not confirmed by dig +trace | Typo in the NS server name or an extra dot |

## Subdomain delegation checklist

- Confirm the exact NS server names with the partner and never use IPs instead of names.
- Add NS records to the parent zone, without matching A or CNAME records for the same name.
- Set up glue records if the NS server itself belongs to the delegated or parent domain.
- Verify delegation with `dig +trace` from two different resolvers.
- Agree with the partner on the TTL of records inside the subdomain so changes apply quickly.

---

Source: https://www.zevshost.net/en/kb/delegirovanie-poddomena/