Delegate a Subdomain to a Different DNS Provider With NS Records

You run everything else on SkyServer, but one subdomain needs to live somewhere else — maybe app.yourdomain.com points at a SaaS platform, or shop.yourdomain.com needs to sit on a different cloud provider's DNS for their CDN and edge rules to work. You don't want to move the whole domain, just hand off control of that one subdomain. That's exactly what NS record delegation does, and it trips up a lot of people the first time because it behaves differently from every other DNS record type.

Symptom: The Subdomain Won't Resolve, or Resolves Inconsistently

You add a CNAME or A record for app.yourdomain.com pointing at the new provider's servers, and it half-works. Some visitors get the new site, others get a timeout or the old SkyServer default page. Or the new provider tells you flatly: "we can't issue you an SSL certificate / set up our platform because we don't control this subdomain's DNS." Support asks you to "delegate the subdomain with NS records" and you're not sure what that actually means versus just adding a CNAME.

Cause: Delegation Is a Different Layer Than a CNAME

A CNAME or A record answers a query directly from your existing zone — SkyServer's nameservers still own the subdomain and just say "go look here." NS delegation is different: you're telling the parent zone (your main domain's zone, hosted in cPanel's Zone Editor or WHM) to stop answering for that subdomain entirely and instead point queries at a completely separate set of nameservers, which then become fully authoritative for everything under that subdomain.

This matters because some platforms — Vercel, AWS Route 53 hosted zones, Cloudflare for a subdomain, certain CDN or SaaS providers — need to manage every record under that subdomain themselves: A records, TXT records for verification, CAA records, sometimes even their own sub-subdomains. A single CNAME can't do that. Only a delegation can.

CNAME vs. NS Delegation, Side by Side

Fix: Setting Up the Delegation Correctly

Here's the process end to end, using app.yourdomain.com as the example subdomain being delegated to a fictional provider's nameservers ns1.provider.com and ns2.provider.com.

Step 1: Get the Nameserver Hostnames From the Other Provider

Log into whatever platform you're delegating to and find their "custom domain" or "DNS setup" section. They'll give you a list of nameserver hostnames — almost always 2, sometimes 4. Copy these exactly; a typo here is the single most common cause of a delegation that silently fails.

Step 2: Add the NS Records in cPanel's Zone Editor

1. Log into cPanel and open Zone Editor under the Domains section.
2. Select the parent domain (yourdomain.com), click Manage, then Add Record and choose NS Record.
3. In the "Name" field enter the subdomain being delegated — app.yourdomain.com.
4. In the "Nameserver" field enter the first hostname, e.g. ns1.provider.com, and save.
5. Repeat for each additional nameserver the provider gave you, using the same subdomain name each time. You'll end up with two or more NS records that share the same "app.yourdomain.com" name but point to different nameservers.

If you're on WHM/root access instead of a single cPanel account, the same records go into the domain's zone file via WHM > DNS Functions > Edit Zone — the record type and structure are identical.

Step 3: Remove Any Conflicting Records

Delete any existing A, AAAA, or CNAME record for that exact subdomain name before or right after adding the NS records. A leftover A record for app alongside the new NS delegation creates a conflict — some resolvers will honor the A record, others the delegation, and you'll see the same "inconsistent resolution" symptom that likely brought you here in the first place.

Step 4: Build Out the Records on the Other Side

Once delegation is live, SkyServer's DNS is out of the picture for that subdomain entirely. Any A, CNAME, TXT, or MX record you need under app.yourdomain.com — including SSL validation records — now has to be created inside the other provider's DNS panel, not in cPanel. This is the step people most often forget: they delegate, then wonder why adding a TXT record in cPanel's Zone Editor "does nothing." It does nothing because that zone editor no longer has authority over the subdomain.

Step 5: Verify the Delegation

Give it 15–30 minutes to propagate (delegations usually move faster than full nameserver changes since only NS records for one label are involved), then check with:

dig NS app.yourdomain.com

You should see the new provider's nameservers in the answer. If you still see SkyServer's nameservers, or a mix, double check the NS records in Zone Editor for typos and confirm you didn't leave an old A record for the same name.

You can also trace the full resolution path to confirm the handoff is happening at the right point:

dig +trace app.yourdomain.com

Prevention: Avoid the Common Traps

• Don't delegate the whole domain by mistake. Only enter records for the specific subdomain label — never add an NS record with the name field left as the bare root domain, or you'll delegate everything.
• Clean up old records first. Before delegating, check Zone Editor for any existing A/CNAME/TXT/MX entries under that exact subdomain and remove them.
• Keep a record of what you delegated and why. Six months later, "why does app.yourdomain.com not show up in cPanel's Zone Editor" is a common confused support ticket — a one-line note in your internal docs saves the investigation.
• If mail ever needs to work on that subdomain, remember MX records for it also have to live in the new provider's zone, not cPanel's — a detail people trip over when they later add a mailbox like support@app.yourdomain.com.
• Test before pointing anything critical at it. Delegate, verify with dig, and only then update application configs, marketing links, or DNS-based SSL validation that depends on the subdomain resolving correctly.

Delegation is a permanent-feeling change compared to a CNAME, but it's just as reversible — delete the NS records from Zone Editor and add back whatever A/CNAME records you need, and the subdomain returns to being managed on SkyServer like any other. If you're not sure whether your situation needs a CNAME or a full delegation, our support team can look at what the other provider is asking for and tell you which one actually applies.

Frequently Asked Questions

Can I delegate a subdomain and still keep the root domain's DNS on SkyServer?

Yes. NS delegation only affects the exact subdomain label you create the records for. yourdomain.com and every other subdomain keep resolving through SkyServer's nameservers as normal.

Why can't I see my delegated subdomain's records in cPanel anymore?

That's expected. Once delegated, SkyServer's Zone Editor is no longer authoritative for that subdomain — all further record changes (A, CNAME, TXT, MX) have to be made in the other provider's DNS panel.

How is this different from just adding a CNAME record?

A CNAME answers queries directly and can only point to one target. Delegation hands off the entire subdomain's authority to another set of nameservers, letting that provider manage multiple record types under it independently.

Will delegating a subdomain break SSL for the rest of my site?

No, SSL certificates are issued per-hostname. AutoSSL for your main domain and other subdomains is unaffected — the delegated subdomain just needs its SSL handled by whichever provider now controls its DNS.

How long does an NS delegation take to propagate?

Usually faster than a full nameserver change since it's scoped to one subdomain label — often 15–30 minutes, though it can take up to a few hours depending on caching resolvers and the parent zone's TTL.