NS Records: How to Delegate a Subdomain to Another Host

A vendor has told you to "delegate" a subdomain to their nameservers instead of just pointing it at an IP or a CNAME target. Maybe it's a headless storefront, a docs platform, or an app that needs to manage its own MX and TXT records under that subdomain. You add something in cPanel's Zone Editor, it doesn't behave the way you expected, and now you're not sure if it's propagation lag or a config mistake. Here's what NS delegation actually does and how to set it up without breaking the rest of your zone.

What NS Delegation Actually Does

Every domain has an authoritative DNS zone — the place that answers "what does this name point to?" Normally that's one zone, one provider, for the whole domain. NS delegation splits a single subdomain off into its own separate zone, hosted somewhere else entirely.

When you add an NS record for app under yourdomain.com, you're telling every resolver on the internet: "Don't answer for app.yourdomain.com yourself — go ask this other set of nameservers instead, they own it now." From that point on, your original DNS provider has no say over what app.yourdomain.com resolves to. The child zone can have its own A, CNAME, MX, TXT, and SRV records, completely independent of the parent domain's zone.

This is different from a CNAME. A CNAME just aliases one hostname to another — the parent zone is still in charge, and the third party can only ever hand you a single target to point at. NS delegation hands over the whole subdomain's DNS to someone else, which is why platforms that need to run their own mail, verification records, or wildcard subdomains under a subdomain (think *.app.yourdomain.com) ask for it instead.

Symptom: Delegation "Isn't Working"

The usual complaints look like one of these:

• You added NS records for the subdomain, but dig or a browser still shows the old A record or nothing at all.
• The vendor says they don't see any traffic reaching their platform for that subdomain.
• cPanel's Zone Editor won't let you save the NS record, or it saves but a leftover A/CNAME for the same name is still answering first.
• Everything looked fine for a day, then subdomain email or a subpage under it suddenly stopped resolving.

Cause 1: A Record Left Behind for the Same Name

This is the single most common mistake. DNS doesn't let a name have an NS record cleanly alongside other record types for the exact same host — if your zone still has an old A record or CNAME for app, some resolvers will keep answering with that instead of following the delegation, especially cached resolvers that picked up the old record before you made the change. Delegation only works cleanly when the parent zone has nothing else for that exact hostname except the NS records.

Cause 2: Delegating at the Wrong Level

People sometimes try to delegate www.app.yourdomain.com when the vendor actually asked for app.yourdomain.com, or vice versa. NS delegation is host-specific — delegating app does not automatically cover www.app or api.app unless the child zone itself creates those records (which it can, since it now owns everything under that name).

Cause 3: No Glue Records When the Child Nameservers Live Under the Same Domain

If the nameservers you're delegating to are something like ns1.thevendor.com, you don't need glue records — your registrar just resolves that hostname normally through its own zone. But if a vendor (rare, but it happens with self-hosted setups) asks you to point at nameservers that are themselves under your own domain, e.g. ns1.app.yourdomain.com, you've created a circular lookup: to resolve the nameserver, a resolver needs the nameserver. That requires a glue record at the registrar level, not just an NS record in the zone. If your vendor's nameservers are on their own domain, this doesn't apply to you.

Cause 4: Propagation and TTL Caching

NS records typically carry a longer default TTL than A or CNAME records because delegation isn't meant to change often. If the zone previously had a short-TTL A record for that name, resolvers that cached it recently will keep serving it until that TTL expires — this can look like the delegation "randomly" not working for some visitors while working for others.

The Fix: Setting Up Delegation in cPanel's Zone Editor

1. Log in to cPanel and open Zone Editor under the Domains section.
2. Find your domain and click Manage.
3. First, delete any existing A, AAAA, or CNAME record for the exact subdomain you're delegating. This is the step people skip, and it's the one that causes the "half-working" symptom above.
4. Click Add Record and choose NS Record from the type dropdown.
5. In the Name field, enter just the subdomain part — app, not app.yourdomain.com.
6. In the Nameserver field, add each nameserver the vendor gave you as a separate NS record. Most delegations need at least two for redundancy:

Type: NS
Name: app
Nameserver: ns1.thevendor.com

Type: NS
Name: app
Nameserver: ns2.thevendor.com

7. Save, then confirm no other record exists for app in this zone. Zone Editor will normally block you from having a conflicting A record and NS record on the same name, but it's worth a manual check if you edited records out of order.

Verify the delegation actually took effect by querying the parent zone directly for the NS records, then querying the child zone for whatever record you expect:

dig NS app.yourdomain.com
dig A app.yourdomain.com

The first command should return the vendor's nameservers. The second should return whatever the vendor's zone is configured to answer — not anything from your original zone. If the second command still shows your old server's IP, either the old A record is still sitting in your zone, or you're hitting a cached resolver — try again from a different network or use a public resolver like 8.8.8.8 to sidestep local caching.

Prevention

• Clean up before you delegate. Delete conflicting records for that exact hostname before adding the NS records, not after.
• Keep a note of what's delegated and why. Six months later, nobody remembers that app.yourdomain.com is intentionally pointing somewhere else — a stray "fix" from a well-meaning admin can silently re-take ownership of the name in your zone.
• Ask the vendor for at least two nameservers. A single nameserver is a single point of failure for that entire subdomain.
• Lower the TTL a day before you delegate if the subdomain currently has a short-lived A record, so old answers age out of caches faster once you switch.

NS Delegation vs. CNAME vs. Glue Records

If you're not sure which one a vendor actually needs, ask them directly — "do you need a CNAME target, or do you need us to delegate the subdomain to your nameservers?" Most support teams that specialize in this will answer instantly, and it saves you from setting up delegation when a simple CNAME would have worked.